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 license. 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
curl -s "$PUPPETDB/pdb/query/v4/facts" > puppet-facts.json
jq -s add puppet-nodes.json puppet-facts.json > puppet.json
switchtender import puppet puppet.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. The facts in the same document give each host the facts that identify it, with its address also set as ansible_host. They go in one document because only the nodes query says which nodes are deactivated.
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 four 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 no agent 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. Azure authenticates from the attached managed identity with no stored key, AWS takes an access key from the credential or the standard AWS environment variables, 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, and an approval step holds the pipeline for a person before the steps after it run. A policy decides which runs are held, and an agent's run is held unless a written policy exempts it. When the approval has to bind an exact Terraform plan, run the apply on its own: it plans first, and the approval binds the saved plan, so it cannot be approved as one thing and executed as another. By default an admin may approve a run they launched. Requiring a different person is a Team rule.
An install keeps running as it is. There is no license server and no phone-home, a paid license keeps verifying offline through its term, and your data and receipts stay yours, checked by an open verifier that does not depend on us. Every release of the public core converts to Apache 2.0 two years after it ships, and at once if KordLoom ceases business.