Ansible managed nodes and executors, read by the unit.

The Ansible managed nodes pricing axis counts every endpoint that the platform runs automation against, regardless of how often the endpoint is touched in a given month and regardless of which job ran. The axis is intuitive to procurement because it reads like a per seat licence on a SaaS product. It is also the axis that the Red Hat field team prefers to quote at renewal in 2026, because it produces the larger number on the typical estate that has grown faster than the formal automation roadmap planned for1.

The executor pricing axis counts the running engines that execute the playbooks rather than the endpoints those playbooks touch. An executor is the process that pulls work from a controller and runs it; the count is bounded by the number of execution environments that the platform is configured to spin up concurrently, not by the number of endpoints in the inventory. The axis fits estates that run a small fleet of executors against a very large endpoint count, which is the common pattern in financial services, public sector, and any account that has migrated from a hand rolled Ansible Core deployment.

The two axes count different things. They are not different ways of measuring the same thing. An estate that runs eight executors against forty thousand endpoints reads on the executor axis as eight units and on the managed node axis as forty thousand units. The Red Hat list price band makes those two numbers come out to roughly the same total under one particular set of assumptions, but the assumptions break the moment the executor count and the endpoint count drift in opposite directions, which they routinely do across a renewal cycle.

A managed node is any endpoint that the Ansible inventory has reached with a play during the licence year. The counting rule is on the inventory rather than on the playbook. An endpoint that appears once in the inventory and is never touched counts as one managed node for the year. An endpoint that is touched ten thousand times in the year also counts as one managed node. The rule is generous in places and unforgiving in others.

The unforgiving places sit on three patterns. The first is the dynamic inventory that pulls from a cloud account or a CMDB and returns every running instance, including instances that the platform never actually configures2. The second is the discovery scan that registers endpoints for visibility without ever running a configuration play against them. The third is the decommissioned endpoint that remains in the inventory long after the host has been retired. All three inflate the managed node count without inflating the value delivered.

The generous places sit on the converse. An endpoint that runs a thousand plays a year, with deep configuration, full state management, and continuous drift correction, counts as the same one node as an endpoint that runs a single check play once a quarter. On estates where automation is genuinely heavy on a small set of endpoints, the managed node axis is the cheaper of the two.

An executor is a runtime engine, frequently delivered as an execution environment container, that the controller dispatches work to. The count is on the runtime configuration of the platform, not on the endpoint inventory. A buyer running eight executors against forty thousand endpoints counts eight units on this axis. The same buyer running eight executors against four hundred thousand endpoints counts eight units on this axis. The axis decouples the licence math from the size of the estate.

The decoupling has two consequences. The first is that an estate which adds endpoints at high velocity is materially cheaper to license on the executor axis than on the managed node axis, on the same renewal scope. The second is that an estate which adds parallel automation pipelines, each requiring its own executor for isolation or scheduling, is materially more expensive on the executor axis than on the managed node axis. The break even point moves with the velocity of endpoint growth and the topology of automation pipelines, not with the absolute size of the estate.

The executor count itself is also negotiable in a way that the managed node count is not. Reducing the executor count is a configuration change to the platform, not a deployment change to the estate. The buyer who reads the executor axis closely can sometimes consolidate two or three logical pipelines onto a single executor without changing the automation outcomes, and the cost saving falls straight into the renewal scope. The same consolidation read against the managed node axis produces no saving at all3.

The Red Hat field team in 2026 quotes the renewal on the axis that produces the larger number on the buyer's particular estate, then frames the quote as if both axes were interchangeable accounting units for the same underlying scope. The framing rarely survives a clean reading of the deployment. A buyer who runs heavy automation on a modest number of executors against a sprawling endpoint estate is being asked to pay the managed node rate on a deployment that the executor axis would price at a fraction.

The two axes meet around a particular ratio of executors to endpoints. Across signed renewals in the trailing twelve months, the practice has observed the break even ratio sit between three thousand and seven thousand endpoints per executor, with the exact ratio depending on the per unit discount band the field team has applied to each axis. Below the break even ratio, the managed node axis is cheaper; above it, the executor axis is cheaper. Estates above the ratio are quoted on the managed node axis with material frequency, and estates below the ratio are quoted on the executor axis with similar frequency. The pattern is consistent with vendor commercial behaviour rather than with buyer side optimisation4.

The axes also break differently. The managed node axis breaks on inventory hygiene, which is recoverable through a reconciliation exercise. The executor axis breaks on platform configuration, which is recoverable through a topology review. Both reconciliations are work the buyer can do without the vendor's cooperation, and both produce evidence that the renewal quote should be recalibrated against the smaller number. The broader counting context sits in the managed node counting mechanics note and the controller and execution environment reading.

A defended posture on the Ansible renewal carries four lines. Each is independent of the others, and each has produced a measurable improvement on signed contracts in the practice's observation across the trailing twelve months. None requires the buyer to escalate beyond the standing field team. Each requires the buyer to read the deployment before reading the quote.

First, the inventory is reconciled before the renewal quote is opened, and the reconciled count is written into the request for renewal terms. A reconciled inventory pulls dynamic cloud entries, discovery scan entries, and decommissioned hosts out of the count, and the reconciled figure carries weight in the negotiation that the unreconciled figure does not. A reconciled count put forward in writing before the vendor opens the renewal frame is the single largest lever on an Ansible renewal in 2026.

Second, the deployment is read against the break even ratio. If the estate sits above three thousand endpoints per executor on a clean count, the executor axis is requested for the renewal and the managed node axis is treated as a fallback. If the estate sits below the ratio, the managed node axis is requested and the executor axis is treated as a fallback. The framing of which axis applies is a buyer side decision before it is a vendor side decision.

Third, the order form is written to specify the axis in plain language, with the counting rule defined in a paragraph rather than referred to in a definitions appendix. A counting rule defined in a paragraph is enforceable; a counting rule referred to in an appendix that the order form does not reproduce frequently is not. The order form should also state the inventory snapshot date, so that the count cannot be moved by a vendor side recount mid term.

Fourth, the renewal is read against the broader renewal negotiation posture rather than as a standalone exercise. Ansible renewals frequently sit alongside RHEL and OpenShift renewals on the same calendar, and the leverage available on a bundled read is materially larger than the leverage available on a serial read5. The practice level reading of the Ansible platform sits in the Ansible Automation Platform practice hub, and the contact line for an opening read on a fresh renewal sits at contact.

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.