Deploying AWX or Ansible Automation Platform for Your Team

Why run Ansible from a platform

Running playbooks from a laptop works until it does not. Credentials live on individual machines. Nobody knows which version of the playbook was run last Tuesday. A new engineer needs SSH keys, vault passwords and a working Python environment before they can restart a service. A manager wants to know who patched production and when, and the answer is a Slack search.

A control platform turns those problems into settings. Jobs run in a consistent environment, with stored credentials the operator never sees, under role-based permissions, with every run logged. This page covers how we deploy AWX or Ansible Automation Platform as part of our Ansible service.

AWX or Automation Platform

This is the first decision, and it is a business one more than a technical one.

We are not tied to either. If your auditors expect a vendor-supported product, we say so and help you scope it. If you have an engineering team comfortable with Kubernetes and want to avoid licence costs, AWX is a sensible choice, provided you accept that you own its upgrades.

What good looks like

• Nobody runs production playbooks from a laptop.
• Credentials are stored once, encrypted, and used without being revealed.
• Permissions follow roles: developers can run deploy jobs for their own team, auditors can read job history, only a few people can edit production templates.
• Risky jobs need an approval step.
• The platform configuration is code, so a lost instance can be rebuilt.

How it works in practice

Architecture

AWX runs on Kubernetes through the AWX Operator. The operator creates the web, task and supporting pods, and manages upgrades through a custom resource. A minimal example:

apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx
  namespace: awx
spec:
  service_type: ClusterIP
  ingress_type: ingress
  hostname: awx.example.internal
  postgres_configuration_secret: awx-postgres-configuration

Using an external managed PostgreSQL database makes backups and recovery simpler than relying on an in-cluster database. If you already run clusters, our Kubernetes consulting team can host AWX alongside your workloads, or we can give it a small dedicated cluster so that a platform incident does not take your automation down with it. See Kubernetes operators for how the operator pattern works.

Execution environments

Jobs run inside container images called execution environments. They bundle ansible-core, collections and Python libraries. We define them with ansible-builder:

version: 3
images:
  base_image:
    name: quay.io/ansible/ansible-runner:latest
dependencies:
  galaxy: requirements.yml
  python: requirements.txt

In real builds we pin the base image tag rather than using latest, so the environment is repeatable. The same image can be used locally with ansible-navigator, which removes the “works on my machine” class of failures.

Modelling people and permissions

The structure is organisations, teams, projects (Git sources), inventories, credentials and job templates. We map them to your reality: a platform team that owns baselines, application teams that own their deploy templates, and read-only access for security. Authentication is connected to your identity provider through LDAP, SAML or OIDC, so joiners and leavers are handled in one place. Credentials integrate with Vault or cloud secret stores.

Job templates, surveys and workflows

A job template pairs a playbook, inventory, credentials and options. Surveys add a form, so an on-call engineer can choose a service and version from a dropdown instead of editing YAML. Workflows chain templates, for example run checks, take a snapshot, deploy, run smoke tests, with an approval node before production. Schedules handle recurring work such as patching within windows.

Configuration as code

Clicking everything together in the UI recreates ClickOps for your automation platform. We instead define organisations, templates and credentials (without secret values) using the awx.awx collection, applied from a pipeline. The platform can then be rebuilt, and changes to templates go through review. This matches the principles behind infrastructure as code.

Decisions and trade-offs

Where to host. In-cluster is convenient; a separate cluster isolates failure. VMs running a supported Automation Platform installation are also valid.

Single platform or one per environment. One instance with strict RBAC is simpler. Separate instances for production give stronger isolation and are favoured in regulated settings, at the price of duplicate operations.

When not to deploy it. Small teams that only run playbooks from a CI pipeline gain little. A pipeline with a locked-down runner and stored secrets already provides audit and repeatability, and has less to operate.

Common failure modes

• Treating AWX as pet infrastructure. No backups, no tested restore. We schedule and rehearse both.
• Unpinned upgrades. A new AWX release changes behaviour. We pin versions and upgrade staging first.
• Over-broad admin rights. Everyone is a system administrator. We assign least privilege.
• Large inventories overwhelming the task pods. We size resources, use instance groups and adjust forks sensibly.
• Secrets leaked in job output. Mitigated with no_log and review of verbosity settings.

Delivery and handover

We deliver the running platform, configuration as code in your repository, a tested backup and restore runbook, an upgrade procedure, and a walkthrough for administrators and for job users. Playbooks come from your role library, and pull request checks come from the lint pipeline.

How to tell it is working

• Production changes appear in job history with a person, a time and a Git commit.
• A new team member runs an approved job within an hour of joining, without handling a secret.
• A staging restore of the platform database succeeds when you test it.
• Upgrades are routine and boring.

To compare AWX with a supported platform for your situation, book a consultation.

References

• Ansible AWX Documentation, Ansible AWX community documentation
• Ansible AWX Operator Documentation, Ansible project documentation