IAG 5 feature comparison

IAG 5 introduces architectural improvements and new capabilities while removing some IAG 4 features. This document outlines key changes when upgrading from IAG 4.

New features

Git-native code storage

IAG 5 provides first-class Git support for storing and retrieving custom code with robust version control.

Flexible deployment architectures

IAG 5 supports multiple deployment architectures to meet different scalability and availability requirements:

All-in-one deployments: Single gateway servers handle both management and execution
Distributed execution: Gateway servers manage coordination while dedicated runner nodes handle service execution
High availability configurations: Multiple gateway servers in active/standby mode with automatic failover
Multiple cluster architecture: Independent clusters for geographic distribution or network segmentation

For more information, see Choose a deployment architecture.

Environment builder

IAG 5 automatically builds and maintains Python, Ansible, and OpenTofu environments based on your requirements files.

Key differences for users

Git-based workflow: All automation content managed through Git repositories
No graphical user interface: All configuration uses command-line interface with context-sensitive help (—help)
No vault integration: No support for Hashicorp Vault or Cyberark integrations as of IAG 5.1
Configuration Manager applications: Not currently supported for IAG 5

Feature comparison

Feature	IAG 4	IAG 5	Change type
Ansible content & dependencies	Playbooks, collections, modules, and roles must exist on the server filesystem before IAG 4 can access them. Collections and roles must exist on the filesystem at design time.	Services retrieve playbook files from Git repositories at runtime. IAG 5 obtains required collections and roles by consulting `requirements.yml` files stored in Git repositories. This allows you to auto-deploy your latest Ansible dependencies at runtime.	Enhancement
Python scripts & dependencies	Python scripts must exist on the filesystem before IAG 4 can execute them. You must manually install Python dependencies in the script’s environment on the server.	Services retrieve script content from Git repositories at runtime. IAG 5 obtains required Python libraries from `requirements.txt` or `pyproject.toml` files stored in Git alongside the scripts. This allows you to auto-deploy your latest Python dependencies at runtime.	Enhancement
Scaling	Difficult to scale due to architectural limitations.	Supports multiple deployment architectures, including distributed execution with runner nodes.	Enhancement
Decorators	Associates decorators with individual scripts or playbooks using a limited JSON schema subset that only accepts strings.	Decorators can work with multiple gateway services and support the full JSON schema specification.	Enhancement
Service discovery	Manual service discovery.	Automatic discovery and registration of available gateway services.	New Feature
Database support	Limited to built-in storage.	External database support (etcd, Amazon DynamoDB) to enable clustered deployments.	New Feature
Execution history	Dedicated store to display Python script and Ansible playbook execution history.	Gateway service execution history available through application log files.	Change
Platform integration	Leverages a combination of Automation Gateway Manager and IAG Adapter for Platform connectivity.	Leverages Gateway Manager for Platform connectivity.	Change
Device inventory	Multiple inventory options: internal inventory stored in sqlite database, Ansible DSL files, and Ansible dynamic inventory plugins for Nautobot, NetBox, SolarWinds, ServiceNow, and ZPE Cloud.	IAG 5.3 introduces support for Inventory Manager, a platform application that centralizes management of automation targets across the Itential platform. Inventory Manager replaces the internal SQLite inventory from IAG 4 with a more scalable, platform-integrated approach. IAG 5 continues to support external inventory sources the same way as IAG 4. For services not using Inventory Manager, define inventory on a per-service basis using the `--inventory` parameter with `iagctl create service ansible-playbook` commands.	Breaking Change (mitigated in IAG 5.3)

Migration from IAG 4

Migration best practices

Assign migration team: Designate a primary individual to oversee the migration with additional support staff
Inventory current assets: Document all scripts, playbooks, and other items that need migration
Plan Git repository structure: Define git repository layout to organize and manage your gateway services

Migration steps

Migrate content to Git: Move Ansible playbooks, Python scripts, and OpenTofu plans to Git repositories
Build development environment: Set up IAG 5 in local mode for development and testing
Configure IAG 5 resources: Set up repositories, services, decorators, secrets, and users
Deploy staging and production: Evaluate appropriate IAG 5 deployment models and build instances

Migration timeline

Plan to remain on IAG 4 only as long as necessary for migration. IAG 5 represents the next generation of Itential’s automation gateway technology with enhanced architecture and simplified deployment. IAG 5 supports concurrent operation with existing IAG installations. You can evaluate IAG 5 capabilities while maintaining current operations.

Future gateway features will be developed for IAG 5 and later versions as older versions transition to maintenance mode.