What a platform adds over the command line · Ansible

Six weeks after a change, somebody asks the question that decides whether this part is worth reading:

Three hundred servers had their sshd_config rewritten on the 14th of March. Who ran that, against which hosts, from which commit, and what did it change?

If the answer is “let me ask around”, the estate has the problem an automation platform solves. If the answer is a URL, it already does not.

Everything else a platform offers — scheduling, workflows, an API, a web interface — is real, and none of it is the argument. The argument is that a run history outlives the person who ran the job.

What a command-line run leaves behind

This is worth establishing precisely rather than assuming, because most teams believe they have more of a record than they do.

By default, ansible-playbook writes nothing to disk. The configuration setting that would change that describes itself unambiguously:

Read-only / Safethe controller keeps no record unless you ask it to— Verified on ansible-core 2.21.3. ansible-config list, filtered to the logging setting.

$ ansible-config list | grep -A 5 '^DEFAULT_LOG_PATH:'

DEFAULT_LOG_PATH:
default: null
description:
- File to which Ansible will log on the controller.
- When not set the logging is disabled.

“When not set the logging is disabled” is the whole of it. On a stock controller, a run that changed three hundred servers exists in exactly two places: the operator’s terminal scrollback, and the servers themselves.

So you set log_path, which is the right thing to do and which every serious controller should have. Here is what you then have:

Configuration changea logged run - the full log file, nothing omitted— Verified on ansible-core 2.21.3. Read-only debug tasks standing in for a package update and a service restart, run under ANSIBLE_LOG_PATH with --limit and an extra variable.

$ ANSIBLE_LOG_PATH=./run.log ansible-playbook -i inventory.ini patch.yml \
--limit web01.example.com -e '{"package_state":"latest"}'
cat run.log

2026-08-11 22:23:37,295 p=162009 u=ebrandi n=ansible INFO| PLAY [Patch the web tier] ******
2026-08-11 22:23:37,298 p=162009 u=ebrandi n=ansible INFO| TASK [Update all packages] *****
2026-08-11 22:23:37,308 p=162009 u=ebrandi n=ansible INFO| ok: [web01.example.com] => {
  "msg": "stand-in for a package update on web01.example.com"
}
2026-08-11 22:23:37,309 p=162009 u=ebrandi n=ansible INFO| TASK [Restart the service] *****
2026-08-11 22:23:37,317 p=162009 u=ebrandi n=ansible INFO| ok: [web01.example.com] => {
  "msg": "stand-in for a service restart on web01.example.com"
}
2026-08-11 22:23:37,318 p=162009 u=ebrandi n=ansible INFO| PLAY RECAP *********************
2026-08-11 22:23:37,318 p=162009 u=ebrandi n=ansible INFO| web01.example.com          : ok=2    changed=0    unreachable=0    failed=0

You get a timestamp, a process ID, and a username. That is genuinely useful and it is more than most teams have.

Now read it for what it does not contain.

That is the shape of the problem. Not “we have no logs” — most teams have some — but “our logs cannot reconstruct the decision”.

The six things a platform adds

A platform in this sense is AWX or Red Hat Ansible Automation Platform’s automation controller component. Both wrap ansible-playbook rather than replacing it: the same collections, the same modules, the same YAML.

What it adds	The problem it solves	Roughly, the CLI equivalent
Run history	Who changed what, when, with which arguments, against which hosts	`log_path` plus a discipline nobody keeps
Central execution	Every run happens in one environment, not on fourteen laptops with fourteen collection versions	A shared controller and a pinned virtualenv
Credential storage	Secrets live somewhere other than on the machines of the people who use them	A vault password file, readable by whoever can run the playbook
Inventories as objects	One authoritative host list with a change history, rather than an `-i` argument someone typed	A checked-in inventory directory
Job templates	A saved, reviewed, named invocation instead of a command line reconstructed from memory	A wrapper script in the repository
RBAC	Who may edit, who may run, against what, with which credentials — enforced rather than documented	`sudo` policy, separate controllers, per-environment vault identities

Every row has a CLI equivalent, which is why this course does not depend on either product. Read the right-hand column as the thing you should build anyway. A platform’s real contribution is that its version is enforced rather than agreed.

What it does not add

This is the section that keeps the rest of the course honest.

A platform does not make an unsafe playbook safe. A play with hosts: all and no serial is exactly as dangerous inside a job template as it is at a shell prompt. It now has a button, a schedule, and an audit trail proving you did it.

A platform does not test your automation. Check mode, lint, Molecule and staging remain yours. A job template can run --check; it will not decide that it should have.

A platform does not fix your inventory. If the group webservers contains a database, the platform faithfully reproduces that error with better logging.

A platform does not remove the need to understand ansible-playbook. The web form is a command-line builder. Every field maps to an argument you already know, and when a job fails the output you read is the output this course has been teaching you to read since Part XI.

AWX and Ansible Automation Platform, stated accurately

These names are used loosely in the wild and the distinction matters when you are choosing.

AWX is the open-source upstream project. It provides a web UI, a REST API and a task engine on top of Ansible. Development happens here first and releases are frequent. It is community-supported: no Red Hat subscription, no support contract, no lifecycle guarantees.

Red Hat Ansible Automation Platform is the commercial product. Automation controller is the component within it that corresponds to AWX. It is produced by taking selected AWX releases and hardening them for long-term supportability, and it comes with Red Hat support.

The relationship is the familiar upstream/downstream one: AWX is to automation controller roughly what Fedora is to RHEL.

A platform is a scheduler, a database and a queue around ansible-playbook

It helps to know how thin the wrapper is.

When a job template runs, the platform:

Updates its checkout of your git repository (the project) to the requested branch or commit.
Materialises the inventory object into a file or an inventory plugin configuration.
Decrypts the credentials attached to the template and injects them into the run environment — as a temporary SSH key file, environment variables, or a vault password file.
Builds an ansible-playbook command line from the template fields: playbook path, limit, tags, verbosity, forks, extra variables.
Executes it inside a container image called an execution environment, which pins the Ansible version, the collections and the Python dependencies.
Streams the output through a callback plugin into a database, one row per event, rather than to a terminal.
Records the exit status, the invocation, the commit hash, the user and the timestamps against the job record.

Step 7 is the product. Steps 1 to 6 are things you can do with a shell script, a virtualenv and a cron entry, and many good teams have.

The two steps that are genuinely awkward to reproduce yourself are 3 — because a shell script that decrypts a credential has to be readable by the person running it, which defeats the point — and 6, because structured per-event storage is what makes a history searchable rather than a pile of text files.

What happens if you adopt a platform and keep running plays from the shell as well?

This is the normal state for the first year, and it is not automatically wrong. Break-glass access to a controller shell is something you want to keep.

It is wrong when it becomes the default path, and it becomes the default path for a predictable reason: the job template is missing an option somebody needs, so they ssh to a box and run it directly, and that works, so they do it again.

Two consequences follow.

The history develops holes that are invisible. The platform shows you forty runs last month. It cannot show you the eleven that bypassed it. An audit trail with unknown gaps is more dangerous than no audit trail, because people trust it.

The two paths drift. The shell path uses whatever collections are on that host; the platform path uses the execution environment. When they behave differently, the debugging is genuinely nasty, because the playbook is identical and the difference is three layers down.

The fix is not a policy telling people not to. It is treating every shell-path run as a defect report against the job template — the same reflex as treating a guardrail override as a defect report against the guardrail. Somebody needed something the template did not offer. Find out what, and add it.

Deciding whether you need one

The honest test is not headcount or server count. It is these four questions:

Can you reconstruct who ran what, six weeks later, without asking a person? If not, you have the problem.
Does more than one person run automation against production? If not, most of a platform is overhead you do not need yet.
Do the people who run automation need to hold the credentials it uses? If the answer should be no and is currently yes, that is the security argument, and it is covered in lesson 4.
Does anything need to run when nobody is at a keyboard? Cron on the controller answers this adequately for a long time. Lesson 5 covers where it stops being adequate.

A three-person team with one controller, a checked-in inventory, a vault password file with sane permissions and log_path enabled is in a defensible position and does not need to buy or deploy anything.

A twenty-person estate where four teams run automation against a shared production fleet and everyone has the vault password has a real problem, and it is not primarily a tooling problem — it is a blast-radius problem wearing tooling clothes. Which is the subject of lesson 3.

Knowledge check

Why this matters

The reason to understand platforms even if you never deploy one is that they are a written-down answer to a question your estate is answering implicitly.

Somebody, right now, can run automation against your production fleet. Some set of people can edit what that automation does. Some set of people hold the credentials it uses. Some record exists of what it did. Those four facts are true whether or not you have chosen them, and a platform is simply a system that makes you choose them explicitly and then enforces the choice.

Reading the platform object model is therefore useful in the same way that reading a well-designed permissions system is useful: it names the distinctions your setup is already making badly. A job template is a saved, reviewed command line, and you can save and review command lines without buying anything. A credential your operators cannot read is a security property, and there are lesser versions of it available on a plain controller.

The thing you cannot get for free is the history — and the history is what you will be asked for.