Every Chef migration option is another server to run. Except one.
Chef Infra Server reaches end of life in November 2026, which makes this a decision with a date on it. Chef 360 and Cinc are both reasonable answers, and the migration page compares all four options properly, including the two that are not us.
Claims about other products verified . Each one is sourced on this page.
| Capability | Opafra | Chef 360 | Cinc |
|---|---|---|---|
| A server you have to operate | None | Self-managed, or their SaaS | Yes, you run it |
| An agent on every node | No | Yes | Yes |
| Model | Plans you run and schedule | Continuous convergence | Continuous convergence |
| Existing cookbooks run as-is | No | Yes | Yes |
| Licence cost | Published, flat | Quoted | Free |
| Commercial support | Yes | Yes | No |
| Approval gates before a change | Yes | No | No |
| AI plan composer | Yes | No | No |
Sources: Chef lifecycle policy · Cinc project · Last verified September 2026
The replacement adds agents. It does not remove them.
It is worth being precise about what Chef 360 is, because the name suggests a newer version of something you already run and it is not that. Progress describes the move as a platform migration rather than an upgrade, and their own documentation explains why.
Enrolling a node into Chef 360 installs the Node Management agent, and in the full configuration Chef Habitat alongside it as a supervisor. Jobs arrive through Chef Courier, which has its own agent listening on a channel, authenticating work sent from a delivery service that sits behind a message queue. Capabilities are installed onto nodes as "skills", each with its own lifecycle.
Every piece of that may be justified by what it buys. The point for this page is narrower: if the reason you are looking at alternatives is that maintaining chef-client across the fleet had become a job in itself, the official migration path hands you more agents, not fewer, plus a supervisor and a message queue to understand.
That is not an argument that Chef 360 is bad. It is an argument that you should check whether it solves the problem you actually have, because the marketing around an end-of-life migration rarely distinguishes between "your server is going away" and "the thing that annoyed you is being fixed".
Full enrollment installs the Node Management agent and Chef Habitat on each node, with the agent running as a Habitat-supervised service. Partial enrollment runs it as a native service where Habitat is unsupported.
Most Chef estates that move, move to Ansible. That is worth saying out loud.
We are not the obvious destination for a team leaving Chef and we are not going to pretend we are. Ansible is, by a wide margin, and any honest page about Chef alternatives has to start there. Vendor-detection datasets put Ansible around 32% of the configuration-management category against Chef near 7%; treat the precise figures as directional rather than audited, but the direction is not in doubt.
The reason is architectural rather than fashionable. Ansible is agentless, which removes exactly the layer that makes a Chef estate expensive to keep healthy, and the Ruby DSL that makes Chef powerful is also what makes it hard to staff in a team that is not already fluent in it.
So if you are moving to Ansible playbooks, that is a sound decision and our AWX and AAP comparison is the more useful page for you, because the next question is what runs those playbooks with approvals and an audit trail.
Where we are worth a look is narrower and we would rather name it than blur it. It is when the problem that survives the migration is governance: changes reaching production without a dry run, without an approval anybody recorded, and without a log an auditor will accept. Rewriting cookbooks as playbooks does not solve that on its own. It just changes the language the ungoverned change is written in.
Convergence is a real model, and we are not it.
Chef describes desired state and keeps the machine there. A node that drifts is pulled back on the next converge, without anybody asking it to. That is a genuinely different idea from ours and it is the right idea for a large estate that must stay identical whether or not anyone is watching.
Opafra runs plans. A plan is a sequence of typed steps against named hosts, and it runs when a person or a schedule says so. Between runs, we assert nothing. If a config file is edited by hand at 3am, Chef will quietly fix it and we will not notice until the next run tells you what changed.
So the question is not which is better. It is which problem you actually have. If yours is drift across thousands of nodes, stay on the convergence model and pick Cinc or Chef 360. If yours is that changes reach production without a dry run, an approval or a record of who authorized them, that is the problem we were built for, and convergence does not solve it.
Most estates we see have both problems and weight them differently. The useful exercise is to ask how many of your last ten incidents came from drift, and how many came from a change nobody reviewed.
What an agent on every node actually costs.
Chef Infra Client runs on every managed node and talks to a server you operate. That is the architecture, and it buys you the convergence model above. It also has a standing bill that is easy to leave out of a comparison.
- The server is yours to run. Postgres, backups, upgrades, TLS, and a restore you have tested. When it is down, nothing converges.
- The agent is on the critical path. A bad cookbook reaches every node on its own schedule, which is the property that makes convergence powerful and incidents fast.
- Bootstrapping is a step. A new host is not managed until the client is installed and its key is accepted.
Opafra connects over SSH with credentials you already manage and leaves nothing behind. There is no server of ours in your network, no agent to patch, and a host that answers SSH is already reachable. The trade is the one above: we are not watching between runs.
When Chef or Cinc is the right choice
- You genuinely converge thousands of nodes continuously against desired state. That is config management, and we are not a config-management product.
- You have heavy custom resources and Ruby logic. That is a real rewrite whichever option you pick, including Ansible. Our assessment quantifies it rather than waving it away.
- You want a drop-in with zero rework. That is Cinc, and we would rather tell you than waste your November.
- Your compliance story is built on InSpec and audit-driven convergence.
- Chef Infra Server receives no patches after October 2026 and reaches end of life in November 2026. Progress Chef lifecycle policy
- Cinc is a community-maintained, Chef-compatible distribution built from the same source. Cinc project
Last verified September 2026