Execution environments, read in layers.

Ansible execution environments are a deep dive worth taking because the operational shape of the platform has reorganised around them, while the licensing surface has barely moved. An execution environment is the containerised runtime in which a playbook actually executes. It is a container image, built from a base image, layered with Ansible itself, with the certified or community collections the playbook requires, and with the Python and system dependencies those collections demand. It runs on an execution node, which is a RHEL host capable of running the container runtime. The platform meters the managed node, the system at the far end of the job. The execution environment is the runtime, not the metered metric.1

This produces a counterintuitive but stable rule. An enterprise that operates ten different execution environments, one per business domain, with different collection sets and different Python versions, pays nothing more on the Ansible Automation Platform line than an enterprise that operates a single execution environment. The cost of operating ten execution environments is the storage in the private hub, the build time on the build pipeline, and the RHEL on the execution nodes. None of those is the platform line.

The deeper deep dive question is therefore not what an execution environment costs in platform terms but what an execution environment costs in operational terms, and the answer to that question changes the buyer side posture at renewal. For the broader platform context, see the Ansible Automation Platform practice hub. For the cost benchmarking that informs the figures here, see the benchmarking service hub.

Each execution environment is a stack of four layers. Each layer is independently versioned, independently audited, and independently a source of unexpected scope creep. Reading the four layers separately is the first move in understanding what the runtime is actually costing the estate.

The base image is the lowest layer. It is the Red Hat Universal Base Image, sometimes UBI 8, sometimes UBI 9, sometimes UBI minimal, with the Ansible Core packaged on top. UBI carries its own redistribution rules; for those, see the UBI licensing rules note. The base image is not a separately metered cost on the Ansible side. It is a storage cost and a maintenance cost.

The collection layer sits above the base. Certified collections from the Red Hat content channel, community collections from Ansible Galaxy, and any private collections built inside the enterprise compose this layer. Certified collections are included with Ansible Automation Platform. Community collections are not subscription bound but are also not Red Hat supported. Private collections live entirely inside the enterprise. For the boundary between certified and community, see the certified versus community collections note.

The Python dependency layer is the largest and the most volatile. Network automation collections pull in network device libraries, security automation collections pull in vulnerability scanner clients, cloud automation collections pull in provider SDKs. The dependency tree of a single execution environment may exceed two hundred Python packages and several gigabytes of installed footprint.

The configuration layer on top is the smallest and the most consequential. The execution environment definition file names the collections and dependencies; the build configuration names the build pipeline; the deployment to the hub names the registry coordinates. The configuration layer is what changes between versions. Everything beneath it changes only when the configuration layer requests it.

The build pipeline that produces execution environments is the operational cost that buyers most often understate at renewal. Each execution environment requires a build pipeline that retrieves the base image, installs the collections, resolves the Python dependency tree, runs the container build, signs the artefact, and pushes it to the private automation hub. The pipeline may be Tekton, Jenkins, GitHub Actions, GitLab CI, or any other container build runner the enterprise already operates.2

The cost of this pipeline is a combination of build runner compute, storage of intermediate artefacts and final images, network egress on dependency retrieval, and the engineering hours on maintaining the build configurations as upstream dependencies move. None of these costs is a Red Hat line item by default. Where the build runner is OpenShift Pipelines, the entitlement falls under the OpenShift agreement and is not an Ansible cost. For the OpenShift Pipelines licensing posture, see the pipelines licensing note.

The deeper consequence of an underbudgeted build pipeline is that execution environments age. An execution environment that was built in February is running February's dependency tree. By August, the upstream libraries have moved, security advisories have published, and the runtime is operating against a stale base. The cost of refreshing each execution environment quarterly is engineering hours measured in days per environment; the cost of not refreshing is operational risk that surfaces as audit posture during compliance reviews.

Enterprises that adopt execution environments tend to operate three of them in the first year, ten by the second year, and thirty by the third. The proliferation is not a licensing problem. It is an operational problem with a licensing shadow. Each additional execution environment carries no platform cost and three operational costs: build, storage, and refresh.

The proliferation also confuses the audit posture. Where an audit team asks the enterprise to enumerate the Ansible footprint, the question is normally about the managed node count. A buyer that leads with the execution environment count, on the assumption that more runtimes equals more platform usage, volunteers a metric that the contract does not actually meter. The buyer side reading is to keep the two questions separate. The platform meter is the managed node. The execution environment count is an operational metric and an internal one.

Three reshape patterns recur on execution environment proliferation. The first is to consolidate environments by job class rather than by team. One environment for network automation, one for security automation, one for cloud, one for infrastructure, and one for general purpose, instead of one environment per team. The second is to introduce a base execution environment that other environments inherit, so the Python dependency layer is centralised rather than duplicated. The third is to retire execution environments that have not been used in the trailing six months, which is normally between a fifth and a third of the inventory.

An audit on Ansible rarely begins with execution environments. It begins with the managed node count. The execution environment topic enters the conversation when Red Hat asks for a description of the deployment architecture, normally as part of the data request that follows the initial finding. The buyer side response to that data request should describe the runtime architecture in terms the contract recognises. It should not volunteer a count of execution environments as if that count were a metered metric. It is not.3

What the runtime architecture should describe is, first, that execution environments are container images and not nodes; second, that they run on execution nodes which carry RHEL subscriptions; third, that they pull content from the private automation hub which is included with the platform. The description is technical and short. It does not contain a financial estimate of the runtime footprint, because there is no financial line tied to the runtime count.

For the broader audit defense posture on Ansible, see the audit defense engagement profile and the day by day timeline at the audit defense timeline note. The execution environment topic is normally a one paragraph item in the broader response, not a chapter.

At renewal, the execution environment topic appears in the seller side narrative as evidence of platform adoption depth, which in turn becomes the qualitative case for tier upgrade. The buyer side reading is that depth of adoption is real and that the right pricing surface for it is the managed node count, not the runtime count.

The renewal moves on execution environments are three. First, consolidate the inventory before the seller side enumerates it. Second, surface the build pipeline as an operational cost and budget for it explicitly so it does not surprise mid term. Third, where validated content bundles are being introduced, separate the validated content subscription decision from the broader platform decision. For the validated content sibling discussion, see the validated content licensing note. For the cross network use case that drives much of the dependency layer growth, see the network automation economics note. For the broader hub layer that holds the execution environments, see the private automation hub licensing note.

Where the renewal sits inside the next quarter, the buyer side move is to engage the advisory desk for a focused execution environment reconciliation alongside the managed node reconciliation. The two run in parallel and inform a single renewal posture.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.