AWX

Last reviewed Aug 26, 2026 · 778 words

AWX needs a Kubernetes cluster before it needs anything else. Since the move to the AWX Operator, the only supported way to install it is onto Kubernetes, so the honest minimum is a single-node cluster, 4 GB of RAM for AWX's own pods, and a willingness to debug pod scheduling when all you wanted was a button that runs a playbook. For a homelab with 6 playbooks and one person running them, that is the wrong trade. For a team that needs to hand playbook runs to people who must never see the SSH key, it is still the only open-source tool that does the entire job.

What the weight buys you

AWX is the upstream of Red Hat Ansible Automation Platform, so the feature list is enterprise-shaped: job templates that wrap a playbook with its inventory, credentials and extra vars; schedules with cron-style recurrence; surveys that turn a template into a form a non-Ansible person can fill in; workflows that chain templates with success and failure branches; and role-based access control across organisations, teams and users. Credentials are stored encrypted and never displayed again, which is the single feature that justifies AWX over a shared Git repo of playbooks. Everything in the UI is also in the REST API under /api/v2/, so Terraform, a chat bot or a cron job can launch the same templates. Jobs run inside execution environments, which are container images carrying Ansible plus the collections a playbook needs, so two teams on incompatible collection versions stop breaking each other.

The install is Kubernetes first, AWX second

The operator is applied with kustomize, then a single custom resource describes the instance:

apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx
spec:
  service_type: nodeport

The operator then creates the web, task, PostgreSQL and Redis pods and generates an admin password into a secret called awx-admin-password. On a lab machine, k3s in a single VM is the path of least resistance; minikube also works and is what the project's own quick-start assumes. Pin the operator to a release tag rather than tracking the default branch, because operator upgrades are what break AWX installs, not AWX itself. The bundled PostgreSQL pod is fine for a lab; for anything that matters, point the resource at an external PostgreSQL you already back up.

4 GB is the floor, not the plan

The 4 GB figure covers the AWX pods idling. Every job launches an execution-environment pod, so 5 concurrent playbook runs against a 200-host inventory will want 8 GB or more, and fact caching against a large inventory pushes PostgreSQL along with it. In my experience an idle instance sits near 2 to 3 GB of resident memory and climbs from there. Budget a VM with 8 GB and 4 cores and you stop thinking about it.

Semaphore UI does 80% of this on 100 MB

Semaphore UI is a single Go binary with SQLite, a key store, task templates, schedules and per-project users, and it runs Ansible playbooks from a Git repo with none of the Kubernetes tax. What it lacks is exactly the enterprise layer: fine-grained RBAC, surveys, workflow branching, and the API surface that tooling built for Tower expects. Rundeck is the other neighbour, better if your jobs are scripts and runbooks rather than Ansible specifically. For most people reading a self-hosting directory, Semaphore is the right answer and AWX is the answer to a question they don't have yet.

The project changed shape in 2024

Red Hat restructured how AWX is developed during 2024, and the release cadence became irregular while the codebase was reorganised. That does not make it abandoned, with over 15,000 GitHub stars and the commercial product still built on it, but check the releases page and the operator's compatibility table before committing to a version, and expect fewer point releases than the 2021 to 2023 pace. Plan upgrades deliberately; never let a Kubernetes cluster auto-pull an operator image.

What I'd do

One person, a homelab, fewer than 20 hosts: Semaphore UI on the same box as everything else, done in an afternoon. Three or more people, hosts that other teams own, or an auditor who wants to know who ran what: AWX on a dedicated k3s VM with 8 GB, an external PostgreSQL, operator version pinned, and a monthly reminder to check the release notes. In both cases keep the playbooks in Gitea or Forgejo and treat the UI as a launcher, never as the source of truth.