AWX, AAP & the retired Tower name

This is a recognition lesson. Nobody expects you to install or administer these platforms on day one. You need to decode them in meetings — even when the name belongs to a product that officially no longer exists.

Everything you’ve run since lesson 7 started at a terminal: ansible-playbook, an inventory, your keyboard. That doesn’t scale to a team. No shared schedules, no audit trail, no way to hand a junior a run button without also handing them shell access. So organisations put a web platform in front of Ansible. It goes by three names, and only two are current products.

The three names

AWX is the free, open-source upstream — Apache 2.0 licensed, community-supported, deployed via the AWX Operator on Kubernetes. It moves fast and gets features first, with the trade-offs that implies: no vendor support, no long-term stability promises.

Ansible Tower was the old commercial product. The name is retired: the last version was 3.8, and the product line as named is discontinued. It survives only in people’s vocabulary.

AAP — Ansible Automation Platform — is Red Hat’s supported enterprise product, sold by subscription (Standard and Premium tiers, priced by node count). When Red Hat rebuilt the product line, Tower became “automation controller” inside AAP. AAP 2.5 unified the whole thing behind a platform gateway with one UI. Beyond the controller, AAP bundles Private Automation Hub, Event-Driven Ansible, Automation Mesh, Ansible Lightspeed and certified content — recognise those names, don’t memorise them.

The decoder rule: a colleague who says “Tower” almost never means an actual Tower 3.8 install. They mean “the web thing our org runs” — today, probably AAP. Translate silently and move on.

What both platforms give you

Strip away licensing and the two products share the same core vocabulary. The word you’ll hear most is job template : a saved run definition. Playbook, inventory, credentials, options — configured once, stored as an object, then launched by click, schedule, or API call. “There’s a job template for that” means the run is pre-wired and you don’t need a terminal.

Around job templates sit the rest. Workflows chain templates together with success/failure branching. Surveys prompt the launcher with a form and feed the answers in as variables. A credentials store holds SSH keys and vault passwords encrypted. RBAC decides who can run what. Schedules replace cron. And inventory sync is lesson 11’s “the controller syncs inventory from the source” — the platform refreshing its host list from vCenter, AD or a cloud API.

All of it is reachable over REST, with the same paths on both products:

# every platform object lives under /api/v2/
curl -s https://controller.example.com/api/v2/job_templates/ \
  -H "Authorization: Bearer $TOKEN"

That API is why “Tower” still appears in playbooks and pipelines that otherwise look current. Automation written against /api/v2/ outlived the product rename without changing a line.

If your new team runs AAP heavily, you’ll use this vocabulary daily. If they’re pure Jenkins-plus-CLI, you’ll still hear these words from vendors and job ads. One piece completes the picture: these platforms don’t run playbooks on a control node the way you do. They run them inside container images — that runtime model is lesson 40.