AWX without the Kubernetes. AAP without the per-node bill.
Ansible is a good tool and this page is not going to pretend otherwise. What follows is where the three products genuinely differ, with a source and a date against every claim we make about someone else.
Claims about other products verified . Each one is sourced on this page.
Every Ansible option prices per node. Ours does not.
~$1,170
per month, before the first node
$35-50K
per year, typical quoted range
Flat
per organization, unlimited nodes
AWX itself is free, and the honest version of that comparison is further down: free software plus a Kubernetes cluster plus the person who operates it is not the same as free.
What each one costs before it does anything.
Free software is not the same as no cost. This is each product's own install guide, reduced to the things you have to stand up before the first command runs.
- 1A running Kubernetes cluster, or minikube for testing, or OpenShift
- 2kubectl with Kustomize support
- 3Deploy the AWX Operator into the cluster
- 4Apply an AWX instance manifest and wait for it to reconcile
- 5Operate Postgres, the web and task pods, and the execution environments after that
AWX itself is free. The cluster underneath it, and whoever keeps that cluster running, is the part that is not.
AWX Operator install guide- 1Sign in
- 2Add one line to authorized_keys on a host
- 3Run something
Nothing runs on your servers, so there is nothing to patch, monitor or roll back. Removing Opafra is deleting that line.
| Capability | Opafra | AWX | AAP |
|---|---|---|---|
| Pricing model | Per organization, unlimited nodes | Free, plus the cluster and whoever runs it | Per managed node, quote or AWS list |
| What the AI produces | A dry-runnable, approval-gated plan | No | Generated playbooks, and answers about the platform |
| Guided builder with typed parameters | Yes | Not documented | Not documented |
| Dry run and approval as one flow | Yes | Check mode, separate | Check mode, separate |
| Environments as a first-class lifecycle | Yes | Inventories and naming | Inventories and naming |
| Time-limited access grants | Yes | Not documented | Via ServiceNow integration |
| Run-to-run diff | Yes | Not documented | Not documented |
| Environment derived from the targets | Yes | Not documented | Not documented |
| Multi-tenant workspaces | Yes | Organizations, self-hosted | Organizations |
| Dynamic discovery and git sync | Yes | Yes | Yes |
| Scheduler with overlap protection | Yes | Concurrent by default | Concurrent by default |
| Runs without Kubernetes | Yes | No | Containerized install on RHEL |
Sources: AWX releases, AAP on AWS service definition, Automation Orchestrator announcement, AAP 2.6 documentation. Last verified September 2026
Free, and the release history is a fact you should check.
AWX is the upstream of Ansible Automation Platform and it is free. For a team that wants a web UI, a job history and RBAC over playbooks it already has, that is a strong offer and it is why AWX is everywhere.
One thing to check before you build a year of operations on it: at the time of writing the most recent tagged release is 24.6.1 from July 2024. Red Hat has said publicly that this is a refactoring of how core components connect rather than an abandonment, and has been explicit that they are not changing the Ansible project or its licensing. We are not going to tell you AWX is dead, because Red Hat says it is not and they would know.
What we will say is that a release gap of that length is a fact worth weighing, and that the way to weigh it is to look at the releases page yourself on the day you decide. That is why the link is there rather than a claim.
The other cost is the one AWX shares with every self-hosted control plane: it runs on Kubernetes, and somebody operates that. Free software plus a cluster plus the person who keeps the cluster healthy is a different number from free.
The most recent tagged release is 24.6.1, published 2 July 2024. Check the link rather than taking our word for it, and note the date you are reading this.
Supported, certified, and priced by the node.
Ansible Automation Platform is the commercial product: Red Hat support, certified content collections, Private Automation Hub, analytics, Event-Driven Ansible and Automation Mesh for reaching networks a single control plane cannot. If you are already a Red Hat shop with a subscription, much of this is genuinely the path of least resistance and we would not argue otherwise.
The question worth asking is what it costs as the fleet grows. AAP is licensed per managed node, and that shape has a predictable consequence: teams start leaving hosts out of the tool to keep the number down. The hosts that most need governing are usually the ragged edges of the estate, and those are exactly the ones a per-node bill argues against registering.
We price per organization by user band, with unlimited hosts on every plan. That is not a better business model in the abstract, it is a different one, and it exists because we think an automation tool that you are incentivised not to point at half your fleet is not doing its job.
If your estate is a few thousand nodes and the subscription is already signed, AAP is probably the right answer and this page has not argued otherwise. If you are twenty to five hundred hosts and looking at a quote that scales with every host you add, the arithmetic is worth doing.
Both products have AI. Ask what it hands you.
AAP ships two, and both are real products. The automation coding assistant (formerly Ansible Lightspeed) generates playbooks, and the automation intelligent assistant answers questions about the platform. What comes out is YAML you then commit, test, review and run yourself.
Opafra's composer is the front door rather than a helper beside it. You describe the change; what comes back is a plan you can read, refine in conversation, dry-run against the real targets, and send through an approval gate. The artefact is the thing that runs, not a draft of it.
An answer, and YAML you still have to make correct, safe and reviewable on your own.
A plan with typed steps and named targets, a dry run showing what would change, an approval recorded against that exact revision, and an audit entry when it runs.
Both products have approvals. Ask what happens to the plan nobody remembered to gate.
In AWX, approval is a node you place inside a Workflow Job Template. It works, and it works exactly where somebody put it. The job template written next quarter, by someone who never read the policy, ships without a gate until a reviewer notices.
AAP now has more. Automation Orchestrator, generally available as an add-on to AAP 2.7 since 21 August 2026, gives its workflows RBAC, approval gates and audit, whatever triggers them. Its documentation covers approvals and workflow versions as separate features, and we found nothing in it that binds an approval to one version.
In Opafra the gate belongs to the environment. Mark production as requiring approval once, and every run whose targets land in it waits for a person. That includes plans authored later, plans written by people who have never seen the setting, and a plan that names a production host directly rather than the environment, because the environment is derived from the resolved targets rather than chosen in the run dialog.
The approval records who decided, when, and against which plan revision. If the plan is edited after the request, the approval is void when the run starts and a new one is needed for the revision that will actually run.
Coverage is whatever the authors remembered. Auditing it means reading every workflow.
Coverage is a property of the estate. There is one place to check, and no phrasing of a plan opts out of it.
When AWX or AAP is the right choice
- Your estate is majority Windows. We are SSH-first and our Windows story is thin. This is a straightforward disqualification, not a hedge.
- You run thousands of nodes with an established platform team. We build for 20 to 500 hosts; at that scale AAP's track record is the safer bet.
- You depend on specific certified collections. There are thousands of them and we do not match that catalog.
- You need deep event-driven automation. Our scheduler covers recurring and triggered work; EDA is not the fight we are picking this year.
- A Red Hat support contract matters more to you than the difference in price. That is a legitimate way to buy software.
- Since AAP 2.4 (September 2023), a containerized installation runs AAP on Red Hat Enterprise Linux with Podman, with no Kubernetes or OpenShift. AWX itself is installed with its Kubernetes operator. Red Hat: AAP 2.5 containerized installation
- AAP separates tenants with organizations, each with its own users, teams, inventories and credentials under role-based access. Red Hat: AAP 2.5 access management
- Red Hat documents just-in-time elevated access through a ServiceNow change request that triggers AAP job templates to grant and later remove privilege. Red Hat Developer, 30 July 2026
- AWX last shipped 24.6.1 in July 2024. Development is paused for a refactor and no 2026 release is planned. AWX releases
- Automation Orchestrator is generally available as an add-on to AAP 2.7, announced 21 August 2026. Its workflows inherit RBAC, approval gates and audit. Red Hat blog, 21 August 2026
- AAP Service on AWS bills per managed node plus an idle control plane of 16 vCPU at $0.10 per vCPU-hour: $1.60 an hour, about $1,170 a month before the first node. Above 50 nodes a multi-region active/passive pair is mandatory. AAP Service on AWS service definition
- Red Hat names two AI products for AAP: the automation coding assistant (formerly Ansible Lightspeed), which generates playbooks, and a separate automation intelligent assistant that answers questions about the platform. Red Hat: Ansible Lightspeed
- AAP 2.6 (June 2026) added AI-assisted inventory generation and unified RBAC. Red Hat AAP 2.6 release notes
- AAP self-managed is quote-only. Public estimates put it near $175 to $250 per node per year. vendor quotes, not a list price
Last verified September 2026
What people ask before switching
Is AWX actually still maintained?
Can I keep my Ansible playbooks?
How is the approval gate different from AWX workflow approval?
production as requiring approval and every run that touches a host in it is gated, including plans written later by people who never read the policy, and including a plan that names a production host directly instead of the environment.Does check mode not already do what your dry run does?
command, shell and raw are skipped rather than predicted. Our dry run reports which of the two you are looking at for every step, per host: a simulated verdict where a read-only check exists, and the exact resolved command text where it does not.What happens to my nodes if we stop paying?
authorized_keys, which you remove. This is the practical half of agentless, and it is worth weighing against any tool that installs software across your fleet.Do you support Windows?
Keep the automation. Drop the cluster and the per-node line item.
Tell us what you run and on how many hosts. We reply by email, and you can set our price against what AAP quotes for the same node count.