> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.itential.com/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.itential.com/_mcp/server. # Gateway 5 feature comparison Gateway 5 introduces architectural improvements and new capabilities while removing some Gateway 4 features. This document outlines key changes when upgrading from Gateway 4. ## New features ### Git-native code storage Gateway 5 provides first-class Git support for storing and retrieving custom code with robust version control. ### Flexible deployment architectures Gateway 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](/itential-gateway/choose-deployment-architecture). ### Environment builder Gateway 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 Gateway 5.1 * **Configuration Manager applications**: Not currently supported for Gateway 5 ## Feature comparison | Feature | Gateway 4 | Gateway 5 | Change type | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | | Ansible content & dependencies | Playbooks, collections, modules, and roles must exist on the server filesystem before Gateway 4 can access them. Collections and roles must exist on the filesystem at design time. | Services retrieve playbook files from Git repositories at runtime. Gateway 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 Gateway 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. Gateway 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 Gateway Manager and Automation Gateway 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. | Gateway 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 Gateway 4 with a more scalable, platform-integrated approach. Gateway 5 continues to support external inventory sources the same way as Gateway 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 Gateway 5.3) | ## Migration from Gateway 4 ### Migration best practices 1. **Assign migration team**: Designate a primary individual to oversee the migration with additional support staff 2. **Inventory current assets**: Document all scripts, playbooks, and other items that need migration 3. **Plan Git repository structure**: Define git repository layout to organize and manage your gateway services ### Migration steps 1. **Migrate content to Git**: Move Ansible playbooks, Python scripts, and OpenTofu plans to Git repositories 2. **Build development environment**: Set up Gateway 5 in local mode for development and testing 3. **Configure Gateway 5 resources**: Set up repositories, services, decorators, secrets, and users 4. **Deploy staging and production**: Evaluate appropriate Gateway 5 deployment models and build instances ### Migration timeline Plan to remain on Gateway 4 only as long as necessary for migration. Gateway 5 represents the next generation of Itential's gateway technology with enhanced architecture and simplified deployment. Gateway 5 supports concurrent operation with existing Gateway installations. You can evaluate Gateway 5 capabilities while maintaining current operations. Future gateway features will be developed for Gateway 5 and later versions as older versions transition to maintenance mode.