Itential Gateway

Itential Gateway overview

Itential Gateway (formerly Itential Automation Gateway - IAG) is the governed execution engine of Itential Platform—the layer where automation actually runs. When a workflow calls a script, a playbook, an integration, or inline code, Gateway is what runs it. It executes close to the infrastructure it touches, under the control of the teams that own it, with governance and auditability built in.

Gateway and the Platform workflow engine are complementary. The workflow engine orchestrates what happens and when: sequencing steps, managing state, and coordinating logic. Gateway is responsible for how that execution happens against real infrastructure. Every team gets a governed, auditable execution environment they own—scoped to their tooling, their secrets manager, and their access policies.

For a deeper look at how execution works, see Execution engine.

How Gateway works

Gateway connects to Itential Platform through Gateway Manager, which registers your gateway cluster and advertises its services to Platform. When a workflow calls a gateway service, Platform routes the task to the appropriate gateway cluster, which executes it locally and returns the result.

Gateway stores only state information—it doesn’t hold copies of your automation content. Your scripts, playbooks, and plans stay in your Git repositories under your control. At execution time, Gateway retrieves the content it needs directly from Git, builds an isolated runtime environment with the required dependencies, runs the automation, and discards the environment when it’s done.

This model means you manage your automations the same way you manage any other code: in version control, with your existing development workflows.

What Gateway executes

Gateway clusters support three types of execution:

  • Gateway services — packaged automations (Python scripts, Ansible playbooks, OpenTofu plans) sourced from Git and registered as named services. Other teams can discover and run them through Platform without knowing anything about the underlying script or tooling.
  • Inline code — Python code written directly on the workflow canvas and executed on a configured gateway cluster without a Git repository or service registration.
  • Integration requests — outbound HTTP calls from integrations routed through a gateway runner node, enabling network-proximate execution and explicit proxy support.

All three execution types run through the same runner infrastructure, under the same audit logging and access controls. For more information, see Execution engine.

Key features

Governed execution

Every execution that runs through a gateway cluster is traceable. Gateway logs which node handled the request, which credentials were used, and what ran and when. Role-based access control (RBAC) and group-based access control (GBAC) are enforced through Gateway Manager’s service groups, and secret values are decrypted only at runtime—never exposed in logs, API responses, or on disk.

Git-native content management

Gateway retrieves automation content from your Git repositories at runtime—no pre-installation on servers required. It supports GitHub, GitLab, Bitbucket, and any standard Git provider. Dependencies defined in requirements files (requirements.txt, pyproject.toml, requirements.yml) are read automatically and deployed at runtime alongside your code.

Managed runtime environments

For each execution, Gateway builds a clean, isolated environment containing exactly the dependencies your automation requires. Administrators don’t need to manually install or maintain dependencies on gateway servers. For more information, see Execution engine.

Workflow integration

Gateway integrates directly with Itential Platform workflows through two task types. Use the runService task to invoke a registered gateway service from the canvas. Use the runCode task to write and run inline Python code directly on the canvas, without a Git repository or service registration. In both cases, Gateway acts as the governed execution engine: code runs on a configured gateway cluster under the same runner infrastructure, audit logging, and access controls.

Horizontal scalability

Gateway supports five deployment models ranging from a single all-in-one server to multi-cluster configurations spanning geographic regions or network segments. You can add runner nodes to any cluster to increase execution capacity—adding a runner requires only placing the Gateway binary on a Linux server and pointing it at the cluster.

For a full comparison of deployment models, see Choose a deployment architecture.

Administration via iagctl

All Gateway administration is handled through iagctl, a command-line tool for creating and managing resources, checking cluster status, and performing operational tasks. Every command includes built-in help via --help, and all outputs can be returned as machine-readable JSON for use in CI/CD pipelines and automation scripts.

For more information, see the Command reference.

Orchestration

Gateway Manager establishes secure connections between your gateway clusters and Itential Platform. It discovers all gateway services associated with your cluster and advertises them to Platform, enabling Platform to orchestrate those services as tasks in automation workflows.

For more information, see Gateway Manager.

Supported tools

Gateway supports the following automation tools:

  • Ansible
  • Python
  • OpenTofu

Requirements

Itential Gateway 5 requires Itential Platform 6.0.4+ or 2023.2.17+ (via Gateway Manager).