Ansible automation, previewed before it runs

Where a playbook runs

A host can run playbooks only if its owner installed the agent with --allow-automation. The console cannot grant it, and a host without it is never sent a run. It is offered on Linux hosts only.

On a BasePit host

Against itself

The agent runs ansible-playbook against its own machine, as root. The host is placed in one Ansible group per tag and per host group, so hosts: web means the hosts tagged web.

Through a runner

Machines without the agent

One opted-in host is the runner for a group of machines. It runs Ansible as a dedicated user, basepit-ansible, never root, with an inventory BasePit writes from the group's fields.

Machines without the agent	Reached by	Login
Linux and Unix servers	SSH	A private key, kept on the runner or sealed in BasePit. Never a password.
Network devices	`ansible.netcommon.network_cli`, with the group's `network_os`	A key or a password
Windows	WinRM over HTTPS (port 5986), NTLM or basic	A sealed password

One run can cover hosts (each running for itself) and groups of machines (each through its runner), and its page merges them into one recap per machine. A machine's SSH host key is recorded at first contact; if it later changes, that machine fails with Ansible's own words.

What BasePit brings: ansible-core in a self-contained Python, with the libraries for network devices and Windows, and the ansible.posix, community.general, ansible.netcommon, ansible.utils and ansible.windows collections. A host fetches it the first time it runs a playbook, and checks it against two checksums. Ansible's modules run with the target's own python3.

Where playbooks come from

Pasted or uploaded, as one file or a folder.
From a Git source, following its branch. A playbook with Ansible Vault files can keep one sealed vault password.
From the catalogue: tested playbooks you run from a form, with no YAML.
Written with AI (below).

A playbook may name Galaxy roles and collections in requirements.yml. They are installed on the machine that runs Ansible, into a cache, before the playbook runs.

Preview, then run

A run by hand goes: the playbook and its revision → the machines → the values → Preview → Run.

The preview is Ansible's check mode with diff (--check --diff) on every machine. Each machine shows would change, already right or could not reach, with the diffs Ansible gives.
The preview is honest about its limits: a task its author marked check_mode: false runs for real even in check mode, and a task that cannot be previewed says so. The page says this.
Run runs exactly what the preview ran: the same revision on the same machines. If either changed since, Run is refused with "The playbook or its machines changed since the preview. Preview again."
One run per playbook at a time, with at most one more waiting. One run per machine at a time across all playbooks, because package managers lock.
Stop ends Ansible and all its workers. Machines not finished read stopped.
A run ends after one hour, unless the playbook allows up to six.

Runs that start themselves

Trigger	What happens
A schedule	A cron line in a time zone. A time missed is recorded, never caught up.
A host joins	When a host with a given tag or host group joins and is approved, the playbook runs once on that host. A host without `--allow-automation` is recorded as skipped.
A new commit	A playbook following its Git branch runs on the new commit.

Automatic runs skip the preview, so check a playbook by hand before you give it a trigger.

Logins and values

A key kept on the runner stays in the runner user's own ~/.ssh/. BasePit never reads it: you put it there.
A login sealed in BasePit is typed once and sealed under your organisation's key. It is opened only for a run of its own group on its own runner, written into that run's private directory as a 0600 file, and removed when the run ends, however it ends.
Values a playbook asks for can be plain or sealed. A sealed value reaches Ansible only through a 0600 file in the run's directory.
Every sealed value is cleared from every line of output, as written and as base64, on the machine before output leaves it, and again by BasePit. This does not depend on the playbook using no_log.

Playbooks with AI

Three helpers sit inside Automation. Nothing an AI writes ever runs by itself.

Helper	What it does
Write a playbook with AI	Say what should happen on which machines. Read the draft, ask for changes in a short conversation, and save it as an ordinary playbook. It is previewed before it runs, like any other.
Why did it fail?	On a failed run, the AI says in plain words why, and offers a corrected version.
Review with AI	Before a run, the AI says what a playbook will change and what to look at first.

Nothing secret is sent to a model, and no question or answer is kept beyond its draft.
Use BasePit's AI, which spends a monthly free allowance first and then a credit or two per answer, or your organisation's own key for a provider of your choice, which costs nothing in BasePit. Or turn AI off.
A playbook written with AI is marked as such.

Access, history and alerts

Admins preview, run, stop and change playbooks, groups, logins and triggers. Operators read playbooks, runs and their output.
Access rules apply: a run needs manage rights on every host it touches.
Each run keeps, per machine, ok, changed, failed, skipped and unreachable counts, the failed task and Ansible's message, and up to 2 MB of output. Runs are kept for 90 days.
Activity records who ran what, and every change to a playbook, a group or a login (never a value).
One alert type: a run ended with a failed or unreachable machine. It resolves on the playbook's next clean run.
A machine without the agent counts as a host while it is listed. Runs themselves cost nothing. Pricing.

Limits

Linux hosts on glibc, amd64 and arm64. Alpine (musl) and macOS cannot run playbooks, and a worker never does.
On a BasePit host each machine runs alone, so a play cannot read another host's facts, delegate_to another machine, or use run_once or serial across hosts. Run such a playbook through a runner instead.
SSH logins are keys only: there is no SSH password support. Windows uses NTLM or basic over HTTPS; Kerberos is not supported.
BasePit writes its own ansible.cfg for each run; a playbook's own ansible.cfg is not read, and the run's page says so.

Real Ansible. Previewed before it touches anything.