Concepts
Pinman and configuration management
Ansible (and its cousins — Puppet, Chef, SaltStack, Windows DSC, Group Policy, Intune) answer a question Pinman also answers: how do I make this machine match the configuration I want? This guide maps that overlap — and shows the much larger half of Pinman that has no Ansible equivalent at all.
The one-line version#
Ansible pushes a desired state onto machines and forgets. Pinman applies a desired state, and remembers what was there before, watches it drift, and can put it back.
Ansible is a forward-only engine: you describe the end state in a playbook, it converges the machine to match, and it keeps no record of what the machine looked like a moment earlier. Pinman does that "apply intent" step too — it calls it a profile — but it sits on top of a live, versioned model of the machine's actual state, so it can also answer "what's there now?", "what changed?", and "undo that."
Where the analogy works#
If these Ansible ideas feel natural, the Pinman equivalents will too.
| In Ansible you… | In Pinman you… | Notes |
|---|---|---|
| write a playbook (YAML desired state) | author a profile (YAML/parameterized intent) | Both declare what should be true, not the click-by-click steps. |
| run a playbook to converge a host | apply a profile | Both push a coordinated change across many tools at once. |
| rely on idempotent modules | rely on surgical apply | Re-applying changes only what's off-target; matching settings are left alone. |
--check (dry run) | Preview a profile (before/after) | See the diff before committing. No backup required to preview. |
| inventory of hosts | a small LAN of machines, each running Pinman | Different shape (see below) but both manage more than one box. |
| roles / variables | parameterized profiles | Reuse one definition with different inputs ("Production" vs "Demo"). |
So the "declare intent, apply it everywhere at once, don't touch what's already right" rhythm is shared. That part of Pinman is a config-management tool.
Where Pinman is a different kind of tool#
These are the differences that matter in practice — and the reason Pinman isn't "just Ansible for the desktop."
1. Pinman remembers; Ansible doesn't#
This is the biggest one. Ansible has no memory of prior state. It knows the desired state (your playbook) and it can read current facts at run time — but it never recorded what the machine looked like yesterday, so it can't show you a history or roll back to it. "Undo" in Ansible means writing a second playbook that describes the old state, by hand.
Pinman captures actual state on a timeline — checkpoints (a frozen point that records what's there and what changed) and savepoints (a checkpoint that also backs up the real file bytes, so you can fully restore). Rollback is selecting a saved point, not authoring a reverse script.
2. Pinman observes continuously; Ansible runs when invoked#
Ansible is a batch tool: it does nothing until you run it, converges the host, and exits. Between runs it has no opinion and no visibility.
Pinman runs locally on each machine as a persistent service maintaining a live
"digital twin" — a searchable model of the files, registry, and device settings
that matter. It's always observing, so drift (where live state has wandered
from intended state) is a screen you glance at, not a --check run you remember
to schedule.
3. Pinman tracks state down to individual settings — as data you can browse#
Ansible can write a registry value or a line in a config file via a module — but it treats that as an imperative task and forgets the result. There's no browsable, versioned tree of "every setting Pinman watches, with its own before/after and change badge."
Pinman's whole foundation is that tracked state model: this key in cabinet.ini,
this registry value, this display resolution — each a first-class tracked item
with history. Applying a profile is one thing you can do to that model; capturing,
comparing, and restoring are the others.
4. Different scope: one machine you operate, not a fleet you provision#
Ansible's home turf is fleets — push one playbook from a control node to tens, hundreds, or thousands of mostly-identical Linux servers, often as part of provisioning fresh infrastructure. It's agentless and push-based by design.
Pinman is about deeply managing one machine (or a few you personally operate on a LAN), each with its own unique, personalized configuration — not a herd of identical cattle. The agent lives on the machine; the browser UI connects to it. Different goal, different shape.
5. Built for an operator, not only a DevOps engineer#
Ansible assumes someone who writes YAML, manages inventories, and lives in a terminal or CI pipeline. Pinman has that layer too (CLI, REST, YAML profiles) but wraps it in role-specific UIs — a non-technical operator can switch modes from a phone; a technician can go deep. The same operation is reachable as a button or a command.
Beyond applying intent — the rest of the platform#
Ansible is one engine (apply desired state) that an ecosystem grows around (AWX/Tower for a dashboard, Vault for secrets, Galaxy for roles). Pinman ships the surrounding capabilities as built-in parts of one tool aimed at running and recovering a real machine.
-
Dashboard. A live "is my system healthy and in its intended state?" screen — readiness, drift summaries, recent changes. Ansible's closest analog is AWX/Tower, a separate product, and it reports job runs, not continuous machine health.
-
Capture & restore. Checkpoints, savepoints, and surgical restore of selected items. Ansible has no snapshot/restore concept at all — backup is someone else's tool.
-
Diagnostics. Pinman can collect system data and report status — whether things are actually working, not just whether they match a playbook. Ansible tells you a task succeeded; it doesn't health-check the result.
-
Software-aware tracking. Files and settings are tied to the application that owns them — "you changed the emulator's fullscreen setting," not "a registry value changed." Ansible tasks are anonymous; they don't model which app a setting serves.
-
Bundles / packages. A bundle groups everything belonging to one thing (a game, an app) — its files and its scattered settings — into one unit you can view, capture, or carry; a package is the portable form. Ansible's nearest idea is a role, which packages tasks, not a versioned slice of live state.
-
AI / MCP interface. Everything is exposed over CLI, REST, and MCP so an AI agent can inspect state, take a checkpoint, apply a change, and verify it inside a bounded, auditable, rollback-ready workflow. Ansible is scriptable, but it has no notion of supervised, reversible write-authority for an agent over live state.
Where Ansible (and friends) are still the right tool#
The honesty section. Pinman is not trying to replace config management for IT fleets.
- Provisioning at scale. Standing up tens, hundreds, or thousands of servers from bare metal or cloud images — Ansible/Terraform/Puppet own this. Pinman manages machines that already exist and that you operate individually.
- Cross-platform server config. Linux-first, SSH-driven, package/service/user management across a heterogeneous fleet. That's Ansible's core competence; Pinman is Windows-desktop-first today.
- CI/CD and orchestration pipelines. Multi-host, multi-stage deployment choreography. Pinman has no pipeline engine.
- Enterprise policy at org scale. Pushing locked-down policy to thousands of domain-joined PCs is Group Policy / Intune / SCCM territory — top-down enforcement, not per-machine state versioning and recovery.
Rule of thumb: Ansible makes many machines match one intended state. Pinman gives one machine a memory, a live state model, and a safe way to move between intended states — and back.
A note on the "similar programs"#
The same split applies to the rest of the family:
| Tool | What it's for | What it lacks vs Pinman |
|---|---|---|
| Ansible | Agentless push of desired state to a fleet | No state history, capture, restore, or continuous drift model |
| Puppet / Chef | Agent-based desired-state convergence at scale | Same — convergence engine, not a versioned state store you browse and roll back |
| Windows DSC | Declarative desired state for Windows | Forward-only; no built-in capture/restore timeline or operator UI |
| Group Policy / Intune / SCCM | Top-down enterprise policy enforcement | Org-scale enforcement, not per-machine versioning, drift exploration, or surgical rollback |
| Terraform | Declarative infrastructure provisioning (cloud resources) | Manages infra objects, not in-OS settings, files, and device state; no restore of live config |
All of them are convergence engines: they drive a system toward a declared state. None of them is a state model with a memory. Pinman's profile feature is a convergence engine — but it's one feature bolted onto a versioned, observable, recoverable model of the actual machine. That model is the part none of these tools have.
The 30-second summary#
| Ansible | Pinman | |
|---|---|---|
| Core job | Push a desired state onto machines | Version, observe, and steer one machine's real state |
| Declares intent? | Yes — playbooks | Yes — profiles |
| Remembers prior state? | No | Yes — checkpoints / savepoints |
| Rollback | Write a reverse playbook by hand | Restore from a saved point |
| Drift detection | Only at run time (--check) | Continuous, against a live digital twin |
| Browse current state? | Facts only, not versioned | A searchable, versioned state tree |
| Runs | On invocation, push from a control node | Always-on, local service per machine |
| Scope | Fleets of (similar) hosts | One machine — or a few you operate — each unique |
| Audience | DevOps / IT writing YAML | Operators and technicians; UI + CLI + API + MCP |
| Health / diagnostics | "Task succeeded" | "Is it actually working?" |