Run, target and trace real Ansible automation through a collaborative interface built around your existing repositories and infrastructure.
TASK [Install nginx] *********** changed: [web01] ok: [web02]
The agentless Ansible model stays intact. Nothing is installed on the hosts you already manage.
Local Projects and Git Projects point at the repository you already maintain — layout unchanged.
Existing inventory files, groups and variables are read as they are.
Playbooks run through ansible-runner, with the same flags you use on the command line.
PLAY [Deploy application] **************** TASK [Gathering Facts] ******************* ok: [web01] ok: [web02] TASK [Install nginx] ********************* changed: [web01] ok: [web02] PLAY RECAP ******************************* web01 : ok=4 changed=1 failed=0 web02 : ok=4 changed=0 failed=0
A target expression is resolved against the inventory before anything runs, so the set of machines a run will touch is reviewed rather than assumed.
Groups, individual hosts and full --limit expressions, including intersections and exclusions, resolve the same way they do on the command line.
Recurring operations keep a named target instead of a re-typed expression.
The resolved host list, and which of those hosts are currently reachable, are shown before the run starts.
Availability here means Ansible connectivity — whether the host can be reached over its configured connection — not application health.
Reachability is checked per host and shown beside the group it belongs to, so an unavailable machine is visible before it appears in a run.
History is written as the run happens and kept in PostgreSQL afterwards: what was executed, against which hosts, from which revision, by whom.
Project, Git revision, target expression and resolved hosts are stored as they were at launch, so a run stays readable after the repository and inventory move on.
Point Playplane at a repository already present on the host. Inventory path and playbooks are read from the project as configured.
Sync is explicit. Playplane fetches when you ask it to, records the revision it synced, and executes against that known revision. It does not write to your repository.
Users, teams and per-project roles, with session authentication and every run attributed to the person who started it.
Read inventory, playbooks and run history.
Run and cancel automation on permitted projects.
Manage projects, users, teams and access.
Users reach Playplane over HTTPS in a browser. Playplane reaches infrastructure the way Ansible already does — no Playplane agent runs on managed machines.
Everything a run does passes through ansible-runner and the connection methods your hosts already accept. Playplane adds no new path into the infrastructure.
PostgreSQL holds runs, events, users and audit records. It persists what happened; it is not part of reaching a host.
Playplane runs where the endpoints are reachable — beside an existing Ansible environment rather than in place of it.
Same Playplane. The stack — Playplane, PostgreSQL and ansible-runner in containers — runs on a workstation or on a shared server. Data does not move between them on its own; what carries over is everything you learned.
$ git clone <repository> $ docker compose up -d
Several engineers work against one control plane instead of separate local instances.
Runs stay available independently of any one engineer's workstation.
Viewer, Operator and Admin roles are managed in one place, with runs attributed to users.
Playplane runs where the automation endpoints are reachable. Credential handling stays server-side as the architecture develops.
Playplane is being built as an open-source, self-hostable project. License published with the repository.