Ansible AWX is the open-source upstream project for Red Hat's Ansible Automation Controller (formerly Ansible Tower). It provides a web-based user interface, REST API, and task engine for managing Ansible playbooks, inventories, credentials, and schedules across your organization.

What Is Ansible AWX?

Ansible AWX is a free, open-source web application that adds a browser-based dashboard and REST API on top of Ansible, so you can run playbooks, manage inventories and credentials, and schedule jobs without touching the command line. It gives you everything you need to run Ansible at scale through a browser:

  • Web UI dashboard — visual overview of job status, inventory health, and recent activity
  • REST API — programmatic access to every AWX feature for CI/CD integration
  • Role-based access control (RBAC) — granular permissions for teams and users
  • Job scheduling — run playbooks on a schedule (cron-like)
  • Credential management — securely store SSH keys, cloud credentials, vault passwords
  • Inventory management — static and dynamic inventories from cloud providers
  • Notifications — email, Slack, webhook alerts on job success/failure
  • Workflow templates — chain multiple playbooks into multi-step workflows

AWX vs Ansible Tower vs Automation Controller

The naming has evolved over the years:

ProductStatusSupportLicense
AWXActive upstream projectCommunity onlyApache 2.0
Ansible TowerRetired name (pre-2021)Was Red Hat supportedSubscription
Automation ControllerCurrent product nameRed Hat supportedSubscription
Ansible Automation PlatformFull platform (includes Controller)Red Hat supportedSubscription

AWX is to Automation Controller what Fedora is to Red Hat Enterprise Linux — the upstream, community-driven project where new features land first.

When to Use AWX vs Automation Controller

Use AWX when:

  • Learning Ansible automation at scale
  • Lab/development environments
  • Small teams without Red Hat subscription
  • You want the latest features (releases every ~2 weeks)
  • Budget constraints prevent commercial licensing

Use Automation Controller when:

  • Production enterprise environments
  • You need Red Hat support and SLA
  • Compliance requires vendor-backed software
  • Stability matters more than latest features
  • You're already on Ansible Automation Platform

Key AWX Features

Job Templates

Job templates define what playbook to run, on which inventory, with which credentials:

Job Template: "Deploy Web App"
├── Playbook: deploy-webapp.yml
├── Inventory: Production Servers
├── Credentials: SSH Key + Vault Password
├── Extra Variables: version=2.1.0
└── Limit: webservers

Workflow Templates

Chain multiple job templates with conditional logic:

Start → Deploy DB Migration
           ├── Success → Deploy App Servers
           │                ├── Success → Run Smoke Tests
           │                └── Failure → Rollback App
           └── Failure → Notify Team (Slack)

Dynamic Inventory

AWX can pull inventory from cloud providers automatically:

  • AWS EC2 — discover instances by tags, regions, VPCs
  • Azure — resource groups, virtual machines
  • Google Cloud — compute instances, GKE clusters
  • VMware vSphere — virtual machines, folders
  • Red Hat Satellite — managed hosts
  • Custom scripts — any source via inventory plugins

Credential Management

AWX stores credentials encrypted in the database:

Credential TypeUse Case
MachineSSH keys, passwords for managed hosts
Source ControlGit repo access (GitHub, GitLab)
VaultAnsible Vault passwords
CloudAWS, Azure, GCP API keys
Container RegistryDocker Hub, Quay.io
CustomAny credential type you define

RBAC (Role-Based Access Control)

Define who can do what:

  • Admin — full control over everything
  • Auditor — read-only access to all resources
  • Execute — run job templates but not edit them
  • Use — use credentials/inventories but not modify them
  • Read — view resources only

Installing AWX

Since AWX 18.0, the recommended installation method is the AWX Operator on Kubernetes:

# Install the AWX Operator
kubectl apply -f https://raw.githubusercontent.com/ansible/awx-operator/main/deploy/awx-operator.yaml

# Create the AWX instance
cat <<EOF | kubectl apply -f -
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx
spec:
  service_type: nodeport
EOF

# Watch the deployment
kubectl get pods -w

Prerequisites

  • Kubernetes cluster (minikube, k3s, EKS, AKS, GKE)
  • kubectl configured
  • At least 4GB RAM and 2 CPUs for AWX
  • Persistent storage for the PostgreSQL database

Docker Compose (Development Only)

For quick testing (not production):

git clone https://github.com/ansible/awx.git
cd awx
make docker-compose-build
make docker-compose

First Login

After installation, access AWX at https://your-awx-host/ (default: https://awx.example.com).

Default credentials:

  • Username: admin
  • Password: retrieved from Kubernetes secret:
kubectl get secret awx-admin-password -o jsonpath="{.data.password}" | base64 --decode

AWX Architecture

┌──────────────────────────────────────────┐
│                 AWX Web UI               │
│            (React frontend)              │
├──────────────────────────────────────────┤
│               AWX API                    │
│          (Django REST Framework)         │
├──────────────────────────────────────────┤
│             Task Engine                  │
│    (Celery workers + Redis queue)        │
├──────────────────────────────────────────┤
│           PostgreSQL Database            │
│     (inventories, credentials, jobs)     │
└──────────────────────────────────────────┘

Components:

  • Web container — serves the UI and REST API (Django)
  • Task container — runs Ansible playbooks (Celery workers)
  • Redis — message broker between web and task containers
  • PostgreSQL — stores all AWX data

Using the AWX REST API

Every AWX feature is accessible via REST API:

# List job templates
curl -u admin:password https://awx.example.com/api/v2/job_templates/

# Launch a job
curl -u admin:password -X POST \
  https://awx.example.com/api/v2/job_templates/7/launch/ \
  -H "Content-Type: application/json" \
  -d '{"extra_vars": {"version": "2.1.0"}}'

# Check job status
curl -u admin:password https://awx.example.com/api/v2/jobs/42/

Using the awx CLI

pip install awxkit

# Configure
export TOWER_HOST=https://awx.example.com
export TOWER_USERNAME=admin
export TOWER_PASSWORD=password

# List templates
awx job_templates list

# Launch a job
awx job_templates launch 7 --extra_vars '{"version": "2.1.0"}'

Common AWX Workflows

CI/CD Integration

Git Push → GitHub Actions → AWX API → Run Playbook → Deploy

Self-Service IT

ServiceNow Request → Webhook → AWX Workflow → Provision Server → Notify User

Scheduled Compliance

AWX Schedule (daily 2AM) → Run CIS Benchmark Playbook → Email Report

Troubleshooting AWX

Jobs Stuck in "Pending"

# Check task container logs
kubectl logs deployment/awx-task -c awx-task

# Verify Redis is running
kubectl get pods | grep redis

# Check Celery worker status
kubectl exec -it deployment/awx-task -- awx-manage celery_status

Database Connection Issues

# Check PostgreSQL pod
kubectl get pods | grep postgres

# Verify database connectivity
kubectl exec -it deployment/awx-web -- awx-manage dbshell

Out of Memory

AWX requires significant resources. Increase limits:

spec:
  web_resource_requirements:
    requests:
      memory: 2Gi
    limits:
      memory: 4Gi
  task_resource_requirements:
    requests:
      memory: 2Gi
    limits:
      memory: 4Gi

Conclusion

Ansible AWX brings enterprise-grade automation management to the open-source community. It transforms Ansible from a command-line tool into a collaborative platform with a web UI, REST API, RBAC, scheduling, and workflow orchestration. Whether you use AWX directly or the commercially supported Automation Controller, understanding AWX is essential for scaling Ansible beyond single-user ad-hoc commands to organization-wide automation.