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
~2 months
from today
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 | Quoted | Free | Free, or AAP per node | Published, flat |
| Keeps the convergence model | Yes | Yes | No | No |
| Approval gates and audit built in | No | No | No | 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 cheapest 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."
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 is a community-maintained, Chef-compatible distribution built from the same source, with no commercial support behind it. Cinc project
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.