Chef Infra Server ends in November 2026. Your automation does not have to.
There are four real options and only one of them is us. This page lays out all four, including the two that keep you on Chef, because you should make this decision on the facts rather than on whoever wrote the page you landed on.
Claims about other products verified . Each one is sourced on this page.
Oct 2026
Chef Infra Server stops receiving fixes
Nov 2026
No support, no security patches
~3 weeks
until patches stop
Two dates, and the earlier one is the one that matters.
Most write-ups give one date: November 2026. There are two, and the earlier one should set your plan. Progress stops contributing code, features and security fixes to the open-source Infra Server at the end of October 2026. End of life follows on 30 November.
The month between them is not a grace period. It is a month in which a disclosed CVE in Infra Server has no upstream fix coming, on a service that holds your node data and your data bags and is reachable by every node you manage. If your risk register treats unpatched infrastructure as a finding, the date you are working to is October, not November.
That is why doing nothing is on this page as a real option and a bad one for most estates. It is not the same decision as staying on the Chef model, which is perfectly reasonable and has two supported routes.
"No new Chef code, features or security fixes, will be contributed into the open-source version of Infra Server after the end of October 2026."
What each one actually costs you.
If your estate has heavy custom resources and Ruby logic, staying on the Chef model is the smaller job and you should probably do it. If you were already tired of operating chef-server, that is worth saying out loud during this decision, because three of these four options hand you another one.
| Capability | Chef 360 | Cinc | Ansible rewrite | Opafra |
|---|---|---|---|---|
| Rework required | Least | Least | Full rewrite into YAML | Rewrite into plans and modules |
| A server you operate afterwards | Yes, unless you take their SaaS | Yes | Yes, AWX or AAP | No |
| An agent on every node | Yes | Yes | No | No |
| Commercial support | Yes | No | With AAP | Yes |
| Licence cost | Per node, from $59 a year | Free | Free, or AAP per node | Flat per organization, unlimited hosts |
| Keeps the convergence model | Yes | Yes | No | No |
| Approval gates and audit built in | Not documented | Not documented | With AWX or AAP | Yes |
Sources: Chef lifecycle policy, Cinc project. Last verified September 2026
Most of what you know transfers.
The vocabulary changes and the execution model changes from continuous convergence to plans you run and schedule. The structure of your automation, though, mostly survives the move.
What does not survive: custom resources with substantial Ruby, and anything that depends on convergence happening continuously without anyone asking for it.
Cinc committed to the fork, in writing, with a date.
If your estate converges thousands of nodes continuously against desired state, you are a configuration-management shop and you should stay one. We are not a configuration-management product and this page will not pretend otherwise. The question is which Chef you stay on.
Cinc settled its half of that in June 2026. The project committed publicly to maintaining Cinc Server as an independent fork: 15.x rebuilds continue through November 2026, then 16.0.0 lands as a drop-in continuation with no planned breaking changes. They are equally explicit about the scope, and that honesty is worth repeating rather than paraphrasing away. The fork is maintenance mode, no major features planned, and what continues is security updates, platform support and dependency upgrades.
That is a smaller promise than a vendor roadmap and a more credible one. For a team whose Chef estate works and whose complaint is licensing rather than architecture, it is very likely the least expensive correct answer. The trade is that you keep operating a server, you keep an agent on every node, and your commercial support story is a community project.
Chef 360 is the other supported route, and it is a platform migration rather than a version upgrade. Progress says as much themselves, and teams commonly run both environments side by side through the transition. Budget it as a migration, because that is what it is, and take pricing from Progress rather than assuming it resembles what you pay today.
"When 16.0.0 lands, it will be a drop-in continuation of the 15.x line. There are no planned breaking changes at the fork point."
The replacement publishes its price, so use it.
Progress publishes Chef 360 pricing, which is more than most of the options on this page can say for themselves. Business is $59 per node per year and Enterprise is $189. Both are per node, both bill annually, and the Business tier includes the job orchestration and compliance audit that most estates leaving Infra Server are using it for.
That makes the decision arithmetic rather than instinct. Two hundred nodes on Business is $11,800 a year; on Enterprise it is $37,800. Five hundred nodes is $29,500 or $94,500. Put your own node count against those two numbers before reading further, because the rest of this page is about whether the migration effort on the other options is worth the difference.
Two things the per-node shape does that a reader should notice. It scales with every host you add, so the fleet you would most like to bring under management is the fleet that costs the most to register. And it does not reset the question this page opened on: Chef 360 adds agents rather than removing them, so the per-node fee buys you a per-node operational surface alongside it.
We price per organization by user band, with unlimited hosts on every plan. That is the same argument we make against Ansible Automation Platform, and the pricing page sets out how it works. It is not automatically the right answer; a Chef estate that genuinely needs continuous convergence gets more from Chef 360 than from us at any price. But it is a different shape, and shape is most of what a five-year total comes to.
Business at $59 per node per year, Enterprise at $189, Enterprise Plus by quote. Business includes node management, job orchestration, compliance audit, unlimited user seats and 30-day data retention.
Red Hat says data bags do not convert. Believe them.
Ansible is where most Chef estates go, and Red Hat has written the migration guide themselves. It is worth reading for what it concedes, because the concessions are where your estimate will be wrong.
The structural mapping is real and largely mechanical: cookbooks become roles, recipes become tasks, attributes become variables. If your estate is mostly package, template, service and file resources, that part converts close to line for line and there is tooling that does the first pass.
Then Red Hat says, in their own guide, that Ansible has no direct equivalent to data bags, and that the answer is to distribute what they held across encrypted files, Ansible Vault or an external store. That is a decision about your secrets architecture, not a file conversion, and it is the same decision this page named earlier. Their guide also warns against translating your Ruby into Python or shell “this is generally a bad idea” in their words, and says to find an existing module instead. Which is right, and which means every custom resource with real logic in it is a rewrite, not a translation. Their guide is silent on InSpec.
So the Ansible route is a good one with a specific bill: data bags and secrets become an architecture question, Ruby-heavy resources become rewrites, and compliance testing is unaddressed. None of that is a reason not to go. It is a reason to count those three before setting a date, because they are what turns a six-week estimate into a six-month one.
Where we differ from that route is not the mapping, which is similar. It is what you are left running. Ansible playbooks are files; what runs them with a dry run, an approval and a record is a second decision, and AWX or AAP is the usual answer to it. We are that second layer with the plan format built in, which is why the honest comparison for a team going to Ansible is our AWX and AAP page, not this one.
"Ansible Automation Platform lacks a direct equivalent to the centralized server-based data bag concept in Chef due to its decentralized and agentless architecture."
What actually breaks when Ruby becomes something else.
Every option that leaves the Chef model is a rewrite, Ansible included. Anyone telling you otherwise is selling you the easy half. The mapping is well-trodden and largely mechanical: cookbooks become roles, recipes become task files, ERB templates become Jinja2, attributes become variables. If your cookbooks are mostly package, template, service and file resources, that part converts close to line for line.
Four things do not convert mechanically, and they are where migration estimates go wrong:
- Custom resources with real Ruby in them. One that wraps a few built-ins is fine. One that computes state in Ruby, shells out, or carries a library of helpers is a rewrite in another language, not a translation.
- Data bags, encrypted ones especially. These are not only data, they are a secrets pattern. Moving them means deciding where secrets live afterwards, which is a question about your security posture rather than a file format.
- InSpec profiles. Your compliance story may be built on InSpec running as part of convergence. That is a real capability and it does not come along for free.
- Ohai-derived logic. Anything branching on node attributes Ohai collected has to branch on something else, and that something else has to collect the same facts.
None of this argues against moving. It argues for knowing the number before you commit to a date, which is what the assessment is for. In most estates the cookbooks that are genuinely active are a fraction of what is checked into the repository, and the real rewrite is far smaller than the repository makes it look.
Run both until you trust the new one.
Nothing about this requires a cutover weekend. Chef keeps converging while you rebuild the plans that matter, and you switch off chef-client per group when the runs agree.
Get a free migration assessment- not completedImport the inventoryYour nodes become servers and environments. Nothing runs yet.
- not completedRebuild the cookbooks that earn itUsually a fraction of what is checked in. The assessment tells you which ones are actually active.
- not completedRun in parallelDry-run against real hosts while chef-client is still converging, and compare.
- not completedCut over per groupRemove chef-client from one group at a time. There is nothing else to uninstall.
- Chef Infra Server receives no patches after October 2026 and reaches end of life in November 2026. Progress Chef lifecycle policy
- Cinc committed on 13 June 2026 to maintain Cinc Server as an independent fork: 15.x rebuilds through November, then 16.0.0 as a drop-in continuation with no planned breaking changes, in maintenance mode. Cinc: forking for the long haul
- Chef 360 is priced per node per year: Business at $59, Enterprise at $189, Enterprise Plus by quote. Chef pricing page
Last verified September 2026
Find out how big the job really is.
We will look at your cookbooks and tell you what maps cleanly, what needs rewriting, and whether you would be better off on Cinc.