AWX and Ansible Automation Platform

AWX — and its Red Hat product form, Ansible Automation Platform — is the controller: a web UI and API that runs your playbooks as job templates, with credentials, role-based access, scheduling, surveys, and an audit log layered on top of ansible-core. It is where the work stops happening on a terminal and starts happening as a governed, recorded action behind a button.

This is where Larkspur's deploys move off engineers' laptops. There is a "Deploy Larkspur" job template, a survey that picks the environment, team-scoped permissions over who can launch versus who can edit, and a record of who ran what and when. Push-button automation, but governed instead of ad-hoc — the same playbooks you already wrote, now run from a place that remembers and controls who ran them.

Job Templates

A job template is a saved, parameterized run that binds four things into one launchable unit: a playbook in a project (a git repo), an inventory, a set of credentials, and an execution environment. "Deploy Larkspur" is a job template, and launching it is clicking a button — not remembering an ansible-playbook -i prod.ini site.yml --vault-id ... command line and getting every flag right under pressure. The binding is the value: the playbook, the hosts, the secrets, and the toolchain are decided once and reviewed, not retyped each run.

Surveys

A survey is a form attached to a job template that prompts for inputs and feeds them in as variables. Larkspur's survey asks "which environment?" with a choice of staging or prod, so the one template targets either inventory without anyone editing a command line or risking the wrong -i. This is why one template plus a survey beats two templates — a staging copy and a prod copy drift apart, and a fix that lands in one but not the other is exactly the kind of gap that surfaces at 2am.

Credentials and RBAC

Credentials — SSH keys, vault passwords, cloud tokens — are stored encrypted in the controller and injected at run time, never shown to the user launching the job. Role-based access scopes who can launch, edit, or admin each template separately. Put those together and the on-call engineer can run the prod deploy without ever holding the prod SSH key: they have launch permission on the template, the controller supplies the credential, and the secret never leaves the vault to sit in a human's ~/.ssh. The moment a person holds a credential to run a deploy by hand, that control is gone.

Scheduling and the API

Job templates run on a schedule — a nightly compliance converge, a recurring drift correction — or are triggered through the controller's REST API. The API is how CI pipelines and webhooks launch governed runs: instead of a pipeline running raw ansible-playbook with secrets exported as environment variables, it makes an API call that launches the job template, and the privileged run happens in the controller with its credentials and audit. The next topic builds the whole pipeline on exactly this handoff.

The Audit Trail

Every job records who launched it, with what survey answers, against which inventory, and the full output. "Who deployed prod at 2am and what did it change" becomes a query against the controller, not a Slack archaeology session reconstructing events from half-remembered messages. The audit trail is not a side feature — it is half the reason to run a controller at all, because the difference between automation and governed automation is whether every run is attributable after the fact.