Start with what this is not. SwitchTender is not a configuration management engine. It has no resource model, it does not converge state, and your manifests do not convert. Nothing here will read a manifest and produce a working equivalent. What SwitchTender takes is the fleet: every node PuppetDB knows about, grouped by environment, carrying the facts that identify it, governed and audited from the day it lands.
Perforce moved Puppet Core under a proprietary licence. The community answer was OpenVox, a fork that exists precisely because the open line stopped being open. That fork is real and it is the right home for a lot of estates.
It also does not solve the other half of the problem. Whichever engine converges your state, something still has to decide who may change production, hold the change until somebody agrees to it, and leave a record an auditor can check. Puppet never did that part, and neither does the fork.
curl -s "$PUPPETDB/pdb/query/v4/nodes" > puppet-nodes.json
switchtender import puppet puppet-nodes.jsonNodes group by environment. Deactivated and expired nodes are left out and counted, because Puppet itself stopped managing them and a play targeting everything would otherwise reach for machines nothing owns. Export a facts query alongside the nodes and each host carries the facts that identify it, with ipaddress also set as ansible_host.
No PuppetDB? The plain certname list that puppet node list prints imports too, because which artifact you have depends on what you can still reach.
Because the fleet transfers honestly and it transfers today, whatever you eventually pick as the engine. Once those nodes are in SwitchTender, everything run against them goes through one path: request, policy, approval, with a signed receipt that verifies offline without us. A migration is the window where an estate gets touched the most and recorded the least. This closes that window without waiting for the rest of the decision.
The three asked most often when somebody is comparing this against what they already run.
No. It reaches the machines it manages over SSH, the same way Ansible does, and installs nothing on them. There is no per-host daemon to deploy, patch, or account for. You run the one server binary. Worker processes for extra throughput are a Team feature, and they are pool members rather than agents belonging to a host.
All three, resolved at launch rather than copied into this database. Vault dynamic secrets go further: a short-lived credential is minted for each run and revoked when the run ends. AWS and Azure both authenticate from an instance role or managed identity with no stored key, and anything else resolves through a command whose output is the secret.
Yes, and it is what pipelines are for here. Steps mix tools freely on a dependency graph with parallel branches, built on a drag-and-drop canvas. The approval is not a convention somebody can skip: a policy decides which runs are held, the core enforces the hold, and the approval binds to the exact plan reviewed, so a run cannot be approved as one thing and executed as another.