Itential Gateway 5

The Operating Model Problem

From Pipelines to Agents: A Decade of Operating Model Shifts

Over the last decade, the way teams deliver software and infrastructure change has been rebuilt from the ground up:

Execution layers have not kept up. Most teams still manually stage scripts onto servers, hand-build Python and Ansible environments, and treat scaling out as an architecture project. The execution layer inserts itself into how developers work instead of staying out of the way. And now AI agents are taking action on infrastructure, which raises the bar again: autonomous change demands an execution plane that is governed, auditable, and consistent by design.

Itential Gateway 5 was designed for this reality, around a single tenet: the gateway should integrate into any SDLC environment without asking developers to change how they do their job. Your teams own their execution environments, every action is logged and traceable, and RBAC, audit trails, and secrets management are built in by default, not layered on after the fact.

You keep your tools, your repos, and your pipelines. Gateway 5 runs them, governed.

The Execution Layer

What Is Itential Gateway 5?

Itential Gateway 5 is the distributed execution engine of the Itential Platform. It is software you deploy in your own environment, close to the infrastructure it acts on, that runs your automation content: Ansible playbooks, Python scripts, and OpenTofu plans.

It exists because orchestration and execution live in different places. The Itential Platform, often cloud-hosted, decides what should happen and when: it sequences steps, manages state, coordinates logic, and enforces governance. But the work itself, the playbook that touches a router, the script that calls an internal API, the plan that provisions cloud resources, has to run inside your network, next to your devices and systems, with your credentials. Gateway 5 is where that work runs.

Every execution follows the same lifecycle: Gateway 5 pulls the automation code from your Git repository, builds a clean ephemeral runtime with the exact dependencies the code declares, injects the required secrets at runtime, executes, writes the audit trail, and destroys the environment. Run the same playbook against 500 devices simultaneously and each execution is fully isolated; a failure in one never affects another.

Once onboarded, every automation becomes a callable, governed service across the platform. FlowAgents add it to their tool library. Workflows invoke it as a step. CI/CD pipelines and ITSM tools hit it as a REST endpoint. Engineers can still run it from the iagctl CLI. Same engine, same governance, every run.

One automation, every consumer.

By Design, Not by Default

The Four Patterns

Everything in Gateway 5 follows from four deliberate design decisions.

01 // Content Lives in Git

Gateway 5 stores only operational state, which is what it needs to understand the current condition of the gateway deployment. It stores nothing about your automations. Every script, playbook, and OpenTofu plan lives in your Git repositories, under your control, and is retrieved at execution time. Requirements files stored alongside the code build clean environments automatically. Add capacity by pointing a new runner at the cluster: nothing to synchronize.

The definition of a service and its execution are fully decoupled. You define a service once and control exactly how it runs, including runtime parameters for Ansible playbooks and other tooling, in a way that is consistent with how your team already operates.

Git is the source of truth. The gateway is a governed execution plane you scale at will.

02 // GitOps Is the Architecture

GitOps is not a best practice bolted on afterward. It is how Gateway 5 is built. Your pipelines run the gateway, not the other way around.

• Configuration is code: DSL files describe every resource: services, repositories, decorators, and secrets. Promotion from dev to stage to prod is a merge, not a rebuild.
• Governed by default: every action is logged and traceable. Teams own their environments, and governance is built in rather than added on.

03 // No Web UI, On Purpose

Gateway 5 has no web UI, and that is a deliberate design decision. A gateway UI is an attack surface, a separate deployment to maintain, and an invitation to manage servers by hand. Gateway 5 is built for pure lights-out operation: nobody logs into a gateway server in production, and nobody runs commands by hand. The iagctl CLI exists for administration and troubleshooting, but day-to-day operation belongs to your pipelines. Service visibility lives in Gateway Manager, inside the Itential Platform.

The best execution layer is the one nobody has to think about.

04 // mTLS, Not VPN Tunnels

Gateway 5 connects to the Itential Platform with application-to-application trust, or more precisely, workflow-to-service. The gateway dials out to the Platform over WebSocket secured with mutual TLS (mTLS).

• Outbound only: no inbound firewall rules and no site-to-site VPN tunnels
• App-to-app trust: both sides authenticate with certificates, and either side can control or terminate the connection
• No IT project: traffic flows through standard firewalls. No tickets, no waiting.
• Flexible certificates: managed per gateway cluster (self-signed, CA-issued, or wildcard)

Workflow-to-service security. Not network-to-network exposure.

Supporting Design Principles

• Local execution and data sovereignty: scripts and playbooks run locally on the gateway server, close to the infrastructure they touch. Automation traffic and infrastructure data stay inside your environment.
• Ephemeral runtime environments: Gateway 5 creates an isolated, transitory environment for each execution, built from the exact dependencies the code declares and destroyed after completion. Every run starts from a known, consistent state, and the “works on my machine” problem is minimized.
• Service-based structure: automation tools are exposed as immutable services with standardized inputs. The automation developer and the operator are decoupled: developers own the code, operators run governed services.

Built to Scale With You

Architecture & Deployment Models

Gateway 5 is implemented in Go for runtime performance and concurrency, and is distributed as a single binary (RPM, Deb, Darwin) and as a container image. It supports five deployment models, so architecture can evolve from simpler to more complex as requirements grow:

Key decision factors when selecting a model: availability requirements, scale expectations, infrastructure constraints, and team operational capabilities.

External database note: clustered and HA deployment models require an external database: etcd v3.5 (3-node or 5-node HA) or Amazon DynamoDB for cloud-native and AWS deployments. The all-in-one single-node model requires no external database.

What Gateway 5 Does

Key Capabilities

Git-Native Content Management

• Git provider agnostic: GitHub, GitLab, Bitbucket, or any standard Git provider
• All Ansible playbooks, Python scripts, and OpenTofu plans live in customer Git repositories
• At execution time, Gateway 5 retrieves content directly from Git; no file copying to servers
• Dependencies (requirements.yml, requirements.txt, pyproject.toml) are stored alongside code and deployed automatically at runtime

Ephemeral Environments Per Execution

• Every execution gets its own dynamically created runtime with the correct dependencies, built instantly and destroyed after completion; no shared state between executions
• Concurrent execution without conflict: run the same playbook against 500 devices simultaneously, each fully isolated
• Environments are cached and rebuilt only when requirements change
• Environment ownership shifts to the developer who owns the code; gateway administrators never hand-build or maintain Python and Ansible environments

Dependencies live with the code. The gateway does the rest.

Horizontal Scalability

• Runner nodes can be added to any cluster to increase execution capacity
• Adding a runner: place the Gateway 5 binary on a Linux server, configure it, and start the process
• Nothing to synchronize across nodes, because content is retrieved from Git at runtime

Service Variants

A single playbook or script can be exposed as multiple distinct services: one with check mode enabled, another with increased verbosity, a third pointing at a different inventory. Gateway 5 decouples the asset from how it is executed. Define a service once, then control runtime parameters, inventory, and execution flags independently per variant.

Security & Governance

• RBAC / GBAC: role-based and group-based access control integrated with Gateway Manager’s organizational policies
• Secrets injected at runtime, never exposed: secrets are retrieved at execution start, injected into the ephemeral runtime, and discarded when it is destroyed. They never appear in scripts, playbooks, Git, execution logs, or Job Viewer output.
• Native encrypted secret store: secrets stored as encrypted key/value pairs, decrypted only at runtime
• Audit logging: service execution and resource access logged, with configurable verbosity. Auditors get attribution; engineers don’t get blast radius.
• Outbound-only connectivity: WebSocket plus mTLS to the Platform; no VPN required

Governance built in, not bolted on.

CLI: iagctl

• All administration via iagctl; no GUI on the gateway itself
• Context-sensitive help at every command level via the built-in help flag
• JSON output via the raw keyword, for embedding Gateway 5 in CI/CD pipelines and automation
• DSL files define resource metadata and enable environment replication (dev to staging to prod)

The Integration Point

Gateway Manager

Gateway Manager is the Itential Platform application that connects Gateway 5 clusters to the Platform. It is the single integration point that makes Gateway 5 services available inside workflows. Minimum Platform version: Itential Platform 6.0.4 or later.

Service Discovery & Workflow Integration

• Gateway Manager automatically discovers Gateway 5 services from connected clusters
• Services appear in the workflow task palette without restarts or manual registration
• Each service exposes inputs and outputs as JSON Schema, so parameter requirements are explicit for workflow builders

Service Lifecycle Protection

If a Gateway 5 service is removed or renamed, Gateway Manager flags the impact on affected workflows, moves those workflows to draft status, and pauses related jobs. Silent failures are prevented, and operators get visibility into exactly what changed.

Change happens. Silent breakage doesn’t.

Service Groups & Access Control

• Administrators create groups of related services and assign user groups to them
• Builders only see services in their assigned Service Groups, with full RBAC/GBAC throughout
• Different teams get isolated views without exposure to the full service catalog

One Layer for Every Automation

Inventory Manager

Inventory Manager is the centralized inventory application for Gateway 5 (Gateway 5.3 and later, Itential Platform 6.3 and later). It provides a platform-managed, decoupled inventory layer for every automation target the gateway acts on.

The Problem It Solves

In most enterprises, inventory is fragmented across tools and teams. Each automation stack maintains its own list of targets, access control is inconsistent, accuracy degrades at scale, and teams accumulate external tooling debt just to federate inventory from disparate sources. Inventory Manager replaces that per-tool inventory sprawl with one platform-managed layer.

A federation layer, not a source of record: Inventory Manager federates data from the external systems you already trust (NetBox, ServiceNow, CMDBs, Git). Each time an inventory is populated, existing data is replaced with the current state from the external source. Your systems of record stay the source of truth.

Key Capabilities

• Centralized management: all automation targets managed from one location. Design targets: 100,000+ nodes per inventory, 1,000+ inventories per platform instance.
• Multiple inventories: separate inventories per team, device type, environment, or customer, each with independent RBAC
• Two update modes: Atomic Replacement (clear-first, ensures an exact match to the source) or Additive Update (adds and updates without removing unlisted nodes)
• No external runtime dependency: inventory is stored inside the Platform database, so automation does not require real-time access to external systems at execution time
• Credential security: node credentials stored as references to secrets managers, never as plaintext values
• Device Broker compatibility: fully compatible with the Itential Platform’s Device Broker, so Configuration Manager (golden config, compliance plans) and Command Templates work without workflow rewrites

One inventory layer. Every automation target. Your sources of truth intact.

The AI Integration Layer

FlowMCP Gateway

Model Context Protocol (MCP) is the open standard AI systems use to discover and call tools. FlowMCP Gateway is part of Itential Gateway: it extends the gateway’s governed execution layer into the MCP ecosystem. It is not a separate product sitting alongside the gateway. It is how the gateway participates in the world of AI agents and MCP tools, with every request passing through the same controls, data handling rules, and execution guardrails as every other gateway action.

How It Works

• Automations call external AI: automations and FlowAgents invoke external MCP tools and vendor agents (NetBox MCP, Selector MCP, and others) through FlowMCP Gateway for data and intelligence enrichment during execution. External tools become callable, but never unbounded.
• External AI calls your automations: FlowMCP Gateway is the enterprise AI connectivity layer for inbound access, with virtual MCP servers scoped per AI system, team, or persona, RBAC on every tool, and complete audit logging at every AI-to-platform handoff. Each connected AI system sees only what it is allowed to see.

The principle in both directions is the same: AI requests intent, and the gateway determines what actually runs. No AI system gets direct access to infrastructure or credentials. Deterministic execution replaces probabilistic action.

Bring your own AI. Govern every action.

Itential MCP Server vs. FlowMCP Gateway

Itential offers two ways to connect AI systems over MCP, and the difference is scale and governance.

• Itential MCP Server (open source): connects a single AI system or LLM (Claude, ChatGPT, Gemini, or a custom model) to the platform, so it can discover and call platform workflows as structured, governed tools. If you are connecting one model in a lab environment, the open-source server is the place to start.
• FlowMCP Gateway (enterprise): centralized governance across multiple MCP instances: virtual MCP servers with per-persona tool access, one control plane for every MCP instance across the enterprise, and complete audit logging at every handoff. If you are managing multiple AI systems, multiple agent personas, and multiple teams using MCP in production, that is FlowMCP Gateway.

One Gateway, One Execution Layer

Because FlowMCP Gateway lives inside Itential Gateway, there is no second execution path to secure, audit, or operate. Scripts, playbooks, workflows, agent actions, and MCP tool calls all run through the same governed integration fabric: the same RBAC, the same schema validation, the same audit trail, the same governed execution model.

Built for the AI Era

Gateway 5 is not a component on the side of the Itential Platform. It is the execution layer that agent-driven operations run on:

• FlowAgents execute through Gateway 5: every automation is registered in the FlowAgent tool library with structured inputs and outputs. Agents include them in their allowlisted skill set, call them with reasoned inputs, and observe the structured result, under the same governance as every human-initiated action. Agents reason. Automations execute.
• Platform capabilities route through Gateway 5: new platform execution capabilities, including integrations execution, Jinja2 templates, and parsers, all run on the gateway.

This matters because autonomous change is coming to infrastructure operations whether teams are ready or not. An AI agent that can act on production needs an execution plane where every action is authorized, logged, and reproducible. Gateway 5 is that plane: the same Git-native content, the same isolated environments, the same audit trail, whether the caller is an engineer, a workflow, or an agent.

AI adds reasoning. Itential adds the guardrails.