Question
How are AWX, Red Hat Ansible Tower and the Automation Controller related?
Answer
AWX is the free open-source upstream project. Red Hat builds its commercial Automation Controller on top of it, and the Automation Controller is the product that used to be called Ansible Tower.
All three are the same kind of tool: a central web front end for Ansible, with a REST API, job management, inventories, credentials and role-based access control. They differ in who builds, supports and pays for them:
| AWX | Automation Controller (formerly Ansible Tower) | |
|---|---|---|
| Type | Community upstream project | Commercial Red Hat product, part of the Ansible Automation Platform |
| Cost | No licence or subscription | Paid subscription |
| Support | You run, maintain and fix it yourself, with community help | Red Hat support, tested releases |
| Role | Innovation base: new features land here first | Stable, supported downstream of AWX |
"Upstream" means the place where the code is developed first; the commercial product takes snapshots of it, hardens them and adds support. It is the same relationship as Fedora and Red Hat Enterprise Linux. The name AWX has no official expansion; it is often read as "Ansible Web eXecutable".
Tip: Tower is the old name, Controller is the new name, AWX is the free version of both.
Go deeper:
ansible/awx on GitHub — the upstream project: web UI, REST API and task engine built on top of Ansible.
Ansible AWX documentation — installation and administration of the community version.
Note saved — thanks!
Question
What are the main functions of AWX (and of the Automation Controller built on it)?
Answer
A web UI to run and watch playbooks, role-based access control, job scheduling and workflows, a REST API for integration, Git synchronisation of playbooks, and container-native execution on Kubernetes.
Plain Ansible is a command-line tool: one person runs ansible-playbook from a terminal. That stops scaling once a team shares automation. AWX adds the layer a team needs around it:
- Web UI: start playbooks, browse inventories and follow job runs and their output centrally, instead of in someone's terminal history.
- RBAC (role-based access control): fine-grained rights per team and user, often connected to LDAP, so a helpdesk member may run "restart web service" against production without getting the SSH keys.
- Job scheduling and workflows: run automation on a timer, and chain jobs into workflows with conditional steps and approval steps ("only deploy after a person clicks approve").
- REST API: lets monitoring or ITSM (IT service management) tools trigger jobs, for example a ticket system that starts a remediation playbook.
- Version-control integration: playbooks are synchronised straight from Git repositories such as GitHub or GitLab, so what runs is what was reviewed.
- Architecture: runs container-native on Kubernetes, as a single node or in a high-availability topology.
Go deeper:
- Ansible AWX documentation — the user guide covers projects, inventories, credentials, job templates and workflows.
- ansible/awx on GitHub — source, release notes and the AWX Operator for Kubernetes.
Note saved — thanks!