Red Hat Ansible Automation Platform is the full enterprise Ansible stack: Automation Controller, private Automation Hub, Automation Mesh, Event-Driven Ansible, and a support contract. It is also priced per managed node and stands up on OpenShift or RHEL with Postgres before the first playbook runs, and Ansible is the only tool it runs. SwitchTender is one Go binary. Download it, run it, and you have job templates, schedules, RBAC, surveys, workflows, and approvals, with directory sign-in on Pro, plus a live host-by-task matrix and seven tools instead of one. Your Controller export imports in one command.
Here because a renewal quote just landed, the node count grew faster than the budget, or a contract is up and somebody asked what else is out there? That is the usual reason people arrive on this page, and it is the right moment to look.
AAP is the enterprise standard, and it's priced and deployed like one. Three things send teams looking for something lighter.
AAP is a subscription that meters by managed node, so the cost climbs with the fleet you automate. SwitchTender is source-available under BSL 1.1 and self-hosts free. Paid tiers are priced by a fleet band you report at renewal, and nothing in the binary counts nodes or seats.
A supported AAP install means OpenShift or a fleet of RHEL hosts, Postgres, and the platform's own operators, then keeping all of it patched. SwitchTender is one process and one database. Upgrading is replacing a binary.
AAP automates Ansible. Real fleets also run Terraform, scripts, and one-off tooling. SwitchTender runs Ansible, Terraform, OpenTofu, Bash, PowerShell, Python, and Go through one engine, one UI, and one audit trail. Ansible check mode and a Terraform or OpenTofu plan preview a change before it runs. A Bash, PowerShell, Python, or Go dry run only checks the script without running it, so it previews nothing.
AAP is the mature, certified, fully supported enterprise Ansible platform. Red Hat backs it with an SLA and a phone number, ships certified content and Event-Driven Ansible, and has a decade of production deployment behind it. If what you're buying is Red Hat's support, certified content, and a name your auditors already trust, buy AAP. This page is for teams who want the capability without the subscription and the platform.
The enterprise checklist, side by side. The full three-way table including AWX and Semaphore is on the comparison page.
| Capability | SwitchTender | Ansible Automation Platform |
|---|---|---|
| Approval bound to the content that runs: inventory, image, commit, plan | a digest recomputed before execution | Workflow node and orchestrator step record a decision, not a digest; project signing and OPA policy check files, image, branch, and inventory at launch, separately from the approval |
| Hard ceiling on AI agents: cannot approve its own run or touch identity or secrets | agents are principals capped below admin | Task agents with tool access set to All, Selected, or None, credentials by reference; approval step needs approval:decide; whether an agent can hold it is not documented |
| Evidence a third party verifies offline, without trusting the server | signed hash chain, Apache-2.0 verifier | No; Red Hat directs user activity logs to external providers for non-repudiation |
| Deploy | One binary, SQLite or Postgres creating a new Postgres schema is Team, opening an existing one is never gated | OpenShift or RHEL + Postgres |
| Model | Source-available, self-host free | Per managed-node subscription |
| Commercial support and SLA | Email support from Pro, SLA at Enterprise | |
| Tools | Ansible, Terraform, OpenTofu, Bash, PowerShell, Python, Go | Ansible only |
| Live host-by-task matrix | ||
| Job templates, surveys, schedules, workflows | ||
| RBAC, teams, organizations | ||
| LDAP, SAML, OIDC sign-in | Pro, $500/yr | |
| Private collections hub | Galaxy or Automation Hub, token | |
| Execution environments | All seven tools, Docker or Podman | Ansible only, Podman |
| Reach isolated networks | Outbound worker relay (Team) | Automation Mesh, multi-hop |
| Event-Driven Ansible | ||
| High availability | Active-active on Postgres creating the schema is Team, opening an existing one is never gated | Via the platform |
| Duration-balanced job splitting | Round-robin slicing | |
| Flaky-host detection and duration trends | Fleet reporting in Automation Analytics | |
| Tamper-evident, signed audit | ||
| Drift detection and reconcile, Ansible and Terraform | detection free, one-click reconcile Team | Check-mode jobs, no drift report or reconcile |
| Advisory AI triage and fleet answers | Lightspeed helps write content, not triage runs | |
| Drop-in Go plugins: tools, secrets, AI, notifiers | ||
| Import from other tools | One command | AWX format only, through awxkit |
Checked against Red Hat's own documentation on 2026-08-10, for Ansible Automation Platform 2.7. A comparison decays the day it is written, so check a row against the current release before you rely on it. Full table and sources.
AAP is a decade of enterprise Ansible with Red Hat behind it: a support desk with an SLA, certified content you can point an auditor at, Event-Driven Ansible, a multi-hop Automation Mesh for reaching segmented networks, and analytics through Insights. What SwitchTender does not have is Red Hat's certified content or AAP's decade in production. What it does have is a plugin path: any team can add a tool, a secret engine, an AI provider, or a notification channel as a drop-in Go plugin binary, no fork and no rebuild of the server. Pick AAP when the deciding factor is Red Hat support and certified content. Pick SwitchTender when it's the product, the footprint, and the bill.
Automation Controller is AWX's data model, so its export imports into SwitchTender the same way AWX's does. Projects, inventories (smart and constructed included), templates, workflows with their approval steps, surveys, schedules, notification templates, and the organizations those belong to come across, with a dry run first so you see the plan before anything is written. A workflow the importer cannot carry over as it stands is named in the plan and left out: one with a node that runs another workflow or a sync, a path taken on failure, nodes from more than one project, or an always path and a success path on the same node. A template that took provisioning callbacks also answers a POST to /api/v2/job_templates/{id}/callback/ once the import knows its id, so a boot script that calls that path keeps working when the hostname points here. awx export strips ids, so save GET /api/v2/job_templates/ as JSON and pass it with --awx-template-ids to keep those addresses. A script that calls the controller at any other path needs its URL edited.
switchtender import awx controller-export.json --db switchtender.db# Keep both values: the server must start with this same pair.
export SWITCHTENDER_ENCRYPTION_KEY=$(openssl rand -hex 32)
export SWITCHTENDER_ENCRYPTION_SALT=$(openssl rand -hex 16)
switchtender import awx controller-export.json --db switchtender.db --applyThe switching guide maps every Controller concept to its SwitchTender equivalent, and the migration reference covers the details. Weighing the community edition instead? The AWX alternative page and the Ascender alternative page make those cases.
The four asked most often when somebody is comparing this against what they already run.
No. It reaches the machines it manages over SSH, the same way Ansible does, and installs no agent on them. There is no per-host daemon to deploy, patch, or account for. You run the one server binary. Worker processes for extra throughput are a Team feature, and they are pool members rather than agents belonging to a host.
All three, resolved at launch rather than copied into this database. Vault dynamic secrets go further: a short-lived credential is minted for each run and revoked when the run ends. Azure authenticates from the attached managed identity with no stored key, AWS takes an access key from the credential or the standard AWS environment variables, and anything else resolves through a command whose output is the secret.
Yes, and it is what pipelines are for here. Steps mix tools freely on a dependency graph with parallel branches, built on a drag-and-drop canvas, and an approval step holds the pipeline for a person before the steps after it run. A policy decides which runs are held, and an agent's run is held unless a written policy exempts it. When the approval has to bind an exact Terraform plan, run the apply on its own: it plans first, and the approval binds the saved plan, so it cannot be approved as one thing and executed as another. By default an admin may approve a run they launched. Requiring a different person is a Team rule.
An install keeps running as it is. There is no license server and no phone-home, a paid license keeps verifying offline through its term, and your data and receipts stay yours, checked by an open verifier that does not depend on us. Every release converts to Apache 2.0 two years after it ships, and at once if KordLoom ceases business.