Chef did not make a clean transition into the immutable world. Chef Client was great for persistent infrastructure, but the options got dicier once we started talking about pre-provisioned infrastructure like image building:
1. Chef Solo (how I last used it when attempting this), which felt intentionally hobbled. All you needed was one poorly-behaved cookbook that called `search` and the bets were off.
2. Chef Zero, which was unnecessarily complicated for being Chef Solo that wasn't intentionally hobbled, so much so that I kept using Solo for awhile after its deprecation.
3. Chef Client, against a Chef Server that was run either for your other persistent infrastructure, or just to have a place to put the cookbooks. Heaven forbid you weren't cleaning up all of those dynamically-created nodes, though...
I still think Chef's Ruby DSL is much more natural than the YAML manifests used by Ansible, and the ability to integrate at the source level with custom Ruby code is a killer feature as soon as any complexity enters the mix. But I almost certainly would not be using Chef in a greenfield deployment these days.
In my experience, it was the need for orchestration that killed it but we are probably using different definitions of "immutable", where in Chef context I think of it as the infrastructure.
For me the killer feature of ansible for me was the ability to gate based on remote state, which really was incompatible with the foundational engineering choices that were almost ideal for its original target.
When you were upgrading rabbitmq, postgres, etc... the view from other cluster nodes was critical, not the local view.
Both chef and puppets tried to graft on what they called orchestration, but was really just batch jobs.
Immutable infrastructure was fairly easy IMHO with chef if your architectural quantum was a machine, but not for situations where that quantum was a cluster, especially with data that needed to persist like with Cassandra etc...
I've been using it a bit, and I like it. However, it is a lot more like programming in Python (rather than defining configuration) when you do anything outside the normal rails.
That's not a bad thing, but it is a different thing.
Still testing it more, and my needs are different than everyone else's, but so far I wouldn't say to anyone who already uses Chef, Ansible, Salt, etc. they could switch to Pyinfra, because the 'core' tool for automation is similar, but the ecosystem is altogether different.
I am moving some of my personal projects over to Pyinfra though, but for now mostly to flesh out my own understanding of it—my main stuff is all still Ansible.
I haven't encountered any Chef code in almost ten years. For the stragglers not yet primarily on Kubernetes and Terraform, I see Ansible and some extra Terraform. Maybe I see some Salt here and there.
These are just my anecdotes, for sure, but (also anecdotal) I rarely hear of other "ops" type people using Chef, and most of the ones I know never got more than just their feet wet with Chef (the SaltStack beta was out early enough to avoid Chef).
Terraform and Chef definitely go well together. Like peanut butter and chocolate. Terraform is great at provisioning cloud resources but not so great at configuring the details once they're up, Chef is great at configuring servers that exist but can't do squat to provision them in the first place. At my job we use both of them quite a bit to manage our stateful EC2 instances, because of the way they complement each other.
Man I miss Chef. It was wildly good for its time with a vibrant community. Habitat was cool but tried to carve into some niches that were too ambitious. And InSpec was an incredible tool but failed to build the critical community to drive it forward. I haven't experienced anything like the Chef Community since. (AI has some of these vibes in small pockets but it's very disjointed)
Now we're stuck with what I call the "DevOps ball of mud". I gotta learn 15 different yaml formats alongside the nuances of every hyperscaler and micro cloud. Like seriously it's 2025 and we still gotta deal with stateful bullshit and a bunch of unoptimized docker containers flung all over the place. It feels like nobody has solved the application runtime stateful egg and we're all just dancing to the dark gods of Docker, Kubernetes, and Helm in hopes that our blood sacrifices make the engines go for another month.
All three of those tools immediately felt, to me, like the wrong approach the moment I first experienced Docker. The notion that production infrastructure should be mutable and we use automation to make changes to it just introduces so much more state than is necessary. Immutable infrastructure eliminates so many sources issues.
And I think that's where the comment you're responding to is coming from. Once you've experienced Docker/K8s and, to a lesser extent, IaC tools like Terraform, it's hard to see yourself ever going back to tools like Chef in the same way that tools like Chef made it hard to see going back to a world where we configured servers manually.
Docker, k8s, Terraform etc are nice. I make extensive use of them too. But in my opinion they can't be used for everything, because mutable infrastructure is a reality of the world that must be accounted for at some point. For example, at my employer we have on-prem k3s clusters running on bare metal servers. Chef is a perfect tool to manage those, because they are by their nature not something we can treat as stateless, immutable configurations.
It seems to me that this is kind of like abstraction levels in programming. If you can use a high level language with lots of powerful tools, you do. But some people have to live in the world of C or even assembly, because (as James Mickens said) you can't just place a Lisp book on top of an x86 chip and hope it learns about lambda calculus by osmosis. I view IaC tools in the same way: if you can use Terraform or Docker, great! But someone has to use lower level tools to provide the environment in which those things exist. And that's why people shouldn't look at Chef (or other similar tools) as outdated, any more than assembly is outdated just because Lisp exists. They still very much have a strong use case that won't ever go away.
I liked writing chef, but the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying. Ansible is more painful to write but a delight to run.
The client/server model is why I like Chef more than Ansible, tbh. Having my machines run a service which pulls configuration on a schedule is, to me, much saner and easier to manage than having to push configuration from a central source over ssh. But that is obviously just my preference, and if someone doesn't like the client/server model then I can totally understand if they don't like Chef as a result.
To me a deployment of new code or config is a workflow. The ordering and timing of its progress of the fleet is very important. You want to be able to plan it, watch it, and pause or reverse it from that perspective.
SSH is inadequate because this process should be much slower than the life of anyone's terminal window. You could approximate it with cronjob pulls if each node's schedule is a little offset from the previous. But you probably also want different rollout schedules available for different scenarios.
I use Ansible personally when I'm dealing with a server or two. I use Puppet professionally when I am dealing with tens of thousands of servers and trying to keep them all in some kind of unity.
You do indeed need to upload cookbook changes with knife; but if you keep your cookbooks in Git you can set up CI/CD pipelines that spawn a container that runs the knife upload steps for you (and even do validation via cookstyle before). Then all you need to do after changing your cookbooks and/or recipes is to commit those changes to your Git repo and watch the CI/CD pipeline do it's thing.
> the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying
It also has tons of advantages, notably around scale (Ansible id very slow when working with thousands of machines) and ensuring that there is no drift. Also e.g. SaltStack (RIP) has cool features such as reactor to react to events on the machine which are only possible because there's an agent
After using it for a few years, accumulated enough quirks to significantly diminish my initial enthusiasm. The concurrency gotchas, the utter lack of debugging and profiling tools, the weak management of today's most common deployment models (e.g. Docker/containers and cloud services)...it's not "good" by 2025 standards.
I'm sure enterprises still do use it. But they also still use RPG, PL/I, and IMS. So...
Its a variant of the orchestration software. I'm not sure this is as enticing as other permissive licensed projects like OpenTofu/Ansible (push) or OpenVox (pull) based on available documentation/market share.
Of note, this is not affiliated with Chef itself [1], but looks like Chef has blessed it [2]
To quote the first line of the website:
> A Free-as-in-Beer distribution of the open source software of Chef Software Inc. See goals for details, or follow our blog for updates on the project.
Many years ago now (2019ish), Chef stopped producing binaries for their software. The software itself remains FOSS, but you have to build it yourself. Cinc is a community project to build the software and distribute it (with Chef trademarks removed).
For me, Ansible and Pyinfra, but I've been leaning on shell scripts for very simple things that I know will be mostly the same for 5-10+ years, and sometimes I wrap those into larger playbooks.
For immutable infra, shell scripts are king. You're essentially just installing packages and copying files around, there's really no need to get any more complicated than that.
For creating AMIs? Probably Ansible or something similar. Chef is great for ongoing management of servers, but not so good for a one-shot config run like you would do if you're creating AMIs.
Chef did not make a clean transition into the immutable world. Chef Client was great for persistent infrastructure, but the options got dicier once we started talking about pre-provisioned infrastructure like image building:
1. Chef Solo (how I last used it when attempting this), which felt intentionally hobbled. All you needed was one poorly-behaved cookbook that called `search` and the bets were off.
2. Chef Zero, which was unnecessarily complicated for being Chef Solo that wasn't intentionally hobbled, so much so that I kept using Solo for awhile after its deprecation.
3. Chef Client, against a Chef Server that was run either for your other persistent infrastructure, or just to have a place to put the cookbooks. Heaven forbid you weren't cleaning up all of those dynamically-created nodes, though...
I still think Chef's Ruby DSL is much more natural than the YAML manifests used by Ansible, and the ability to integrate at the source level with custom Ruby code is a killer feature as soon as any complexity enters the mix. But I almost certainly would not be using Chef in a greenfield deployment these days.
While I agree with a lot of what you said.
In my experience, it was the need for orchestration that killed it but we are probably using different definitions of "immutable", where in Chef context I think of it as the infrastructure.
For me the killer feature of ansible for me was the ability to gate based on remote state, which really was incompatible with the foundational engineering choices that were almost ideal for its original target.
When you were upgrading rabbitmq, postgres, etc... the view from other cluster nodes was critical, not the local view.
Both chef and puppets tried to graft on what they called orchestration, but was really just batch jobs.
Immutable infrastructure was fairly easy IMHO with chef if your architectural quantum was a machine, but not for situations where that quantum was a cluster, especially with data that needed to persist like with Cassandra etc...
Right. If Chef had adopted agentless earlier (or, rather, made Chef Solo less confusing to use), Ansible would not have eaten its lunch like it did.
If you're still fighting with Chef slowness, hard to debug, complicated setup, you may want to consider Pyinfra.
It is very well thoughout and simple to design and run.
It targets a different audience overall.
I've been using it a bit, and I like it. However, it is a lot more like programming in Python (rather than defining configuration) when you do anything outside the normal rails.
That's not a bad thing, but it is a different thing.
Still testing it more, and my needs are different than everyone else's, but so far I wouldn't say to anyone who already uses Chef, Ansible, Salt, etc. they could switch to Pyinfra, because the 'core' tool for automation is similar, but the ecosystem is altogether different.
I am moving some of my personal projects over to Pyinfra though, but for now mostly to flesh out my own understanding of it—my main stuff is all still Ansible.
I haven't encountered any Chef code in almost ten years. For the stragglers not yet primarily on Kubernetes and Terraform, I see Ansible and some extra Terraform. Maybe I see some Salt here and there.
These are just my anecdotes, for sure, but (also anecdotal) I rarely hear of other "ops" type people using Chef, and most of the ones I know never got more than just their feet wet with Chef (the SaltStack beta was out early enough to avoid Chef).
I committed some Chef code into production today, at a FAANG no less.
It's not great, but it works I guess. I do wish we were on SaltStack or Ansible instead.
I think you would be quite shocked to discover how many millions (10s of millions?) of nodes at hyperscalers and adjuncts are configured with Chef.
> For the stragglers not yet primarily on Kubernetes and Terraform
In my experience - you see all three of these, k8s, TF and chef working in the same cluster. But, I'm only an anecdote of n=2.
Terraform and Chef definitely go well together. Like peanut butter and chocolate. Terraform is great at provisioning cloud resources but not so great at configuring the details once they're up, Chef is great at configuring servers that exist but can't do squat to provision them in the first place. At my job we use both of them quite a bit to manage our stateful EC2 instances, because of the way they complement each other.
Man I miss Chef. It was wildly good for its time with a vibrant community. Habitat was cool but tried to carve into some niches that were too ambitious. And InSpec was an incredible tool but failed to build the critical community to drive it forward. I haven't experienced anything like the Chef Community since. (AI has some of these vibes in small pockets but it's very disjointed)
Now we're stuck with what I call the "DevOps ball of mud". I gotta learn 15 different yaml formats alongside the nuances of every hyperscaler and micro cloud. Like seriously it's 2025 and we still gotta deal with stateful bullshit and a bunch of unoptimized docker containers flung all over the place. It feels like nobody has solved the application runtime stateful egg and we're all just dancing to the dark gods of Docker, Kubernetes, and Helm in hopes that our blood sacrifices make the engines go for another month.
Full Disclosure: I worked at Chef for 5 years
2013 called and wants its favorite infrastructure as code (IaC) tool back.
Tools don't stop being useful just because they aren't trendy. I still use Chef, and I love it. I much prefer it to Ansible or Puppet.
All three of those tools immediately felt, to me, like the wrong approach the moment I first experienced Docker. The notion that production infrastructure should be mutable and we use automation to make changes to it just introduces so much more state than is necessary. Immutable infrastructure eliminates so many sources issues.
And I think that's where the comment you're responding to is coming from. Once you've experienced Docker/K8s and, to a lesser extent, IaC tools like Terraform, it's hard to see yourself ever going back to tools like Chef in the same way that tools like Chef made it hard to see going back to a world where we configured servers manually.
Docker, k8s, Terraform etc are nice. I make extensive use of them too. But in my opinion they can't be used for everything, because mutable infrastructure is a reality of the world that must be accounted for at some point. For example, at my employer we have on-prem k3s clusters running on bare metal servers. Chef is a perfect tool to manage those, because they are by their nature not something we can treat as stateless, immutable configurations.
It seems to me that this is kind of like abstraction levels in programming. If you can use a high level language with lots of powerful tools, you do. But some people have to live in the world of C or even assembly, because (as James Mickens said) you can't just place a Lisp book on top of an x86 chip and hope it learns about lambda calculus by osmosis. I view IaC tools in the same way: if you can use Terraform or Docker, great! But someone has to use lower level tools to provide the environment in which those things exist. And that's why people shouldn't look at Chef (or other similar tools) as outdated, any more than assembly is outdated just because Lisp exists. They still very much have a strong use case that won't ever go away.
I liked writing chef, but the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying. Ansible is more painful to write but a delight to run.
The client/server model is why I like Chef more than Ansible, tbh. Having my machines run a service which pulls configuration on a schedule is, to me, much saner and easier to manage than having to push configuration from a central source over ssh. But that is obviously just my preference, and if someone doesn't like the client/server model then I can totally understand if they don't like Chef as a result.
To me a deployment of new code or config is a workflow. The ordering and timing of its progress of the fleet is very important. You want to be able to plan it, watch it, and pause or reverse it from that perspective.
SSH is inadequate because this process should be much slower than the life of anyone's terminal window. You could approximate it with cronjob pulls if each node's schedule is a little offset from the previous. But you probably also want different rollout schedules available for different scenarios.
Ansible can work that way too.
In fact every time I’ve migrated to Ansible (each time from Puppet), we’ve built the infrastructure so Ansible pulled its configuration.
https://docs.ansible.com/ansible/latest/cli/ansible-pull.htm...
I use this to keep my (too many) Linux desktops configured.
A systemd service runs ansible-pull about 2 minutes after boot. It does its thing.
It has some annoyances, but it works fine. I don't think about it anymore. The git repo is the source of truth.
Different use cases, probably.
I use Ansible personally when I'm dealing with a server or two. I use Puppet professionally when I am dealing with tens of thousands of servers and trying to keep them all in some kind of unity.
You do indeed need to upload cookbook changes with knife; but if you keep your cookbooks in Git you can set up CI/CD pipelines that spawn a container that runs the knife upload steps for you (and even do validation via cookstyle before). Then all you need to do after changing your cookbooks and/or recipes is to commit those changes to your Git repo and watch the CI/CD pipeline do it's thing.
You could use Chef in local mode and pull down the cookbooks from s3 or something.
> the client/server model and its knock on effects (IIRC, needing to upload changes with knife?) was annoying
It also has tons of advantages, notably around scale (Ansible id very slow when working with thousands of machines) and ensuring that there is no drift. Also e.g. SaltStack (RIP) has cool features such as reactor to react to events on the machine which are only possible because there's an agent
IMO Ansible is easier to get started with, but less powerful than Chef.
UNIX: 1973
vi: 1976
BSD UNIX: 1978
x86 instruction set: 1978
UNIX System V R4.2 1983
Linux: 1991.
Kids these days.
Chef is still popular in the enterprise. It's a good tool.
It's an okayish tool.
After using it for a few years, accumulated enough quirks to significantly diminish my initial enthusiasm. The concurrency gotchas, the utter lack of debugging and profiling tools, the weak management of today's most common deployment models (e.g. Docker/containers and cloud services)...it's not "good" by 2025 standards.
I'm sure enterprises still do use it. But they also still use RPG, PL/I, and IMS. So...
I misguidedly thought this was going to be about Chef in Apocalypse Now. Don't get off the boat!
It's an interesting post. I feel like people who are still doing Chef definitely know about cinc already.
Are there Chef Habitat users in the wild?
I was never really able to grok this tool. It always felt like Docker with extra steps.
Are we talking about the orchestration software, like Ansible and Puppet, or is it something else?
Its a variant of the orchestration software. I'm not sure this is as enticing as other permissive licensed projects like OpenTofu/Ansible (push) or OpenVox (pull) based on available documentation/market share.
Of note, this is not affiliated with Chef itself [1], but looks like Chef has blessed it [2]
[1] https://cinc.sh/disclaimers/ [2] https://cinc.sh/blog/cinc_client_is_live/
What is Chef? This website fails to answer that.
To quote the first line of the website: > A Free-as-in-Beer distribution of the open source software of Chef Software Inc. See goals for details, or follow our blog for updates on the project.
Yes, I clicked details. It told me, again, that this is a chef distribution. What is chef, I asked after reading the details page, again.
(Only then did I originally post my question to Hackernews. I can read. The info just is not there.)
I'm dumb and can't figure out wtf this is.
Many years ago now (2019ish), Chef stopped producing binaries for their software. The software itself remains FOSS, but you have to build it yourself. Cinc is a community project to build the software and distribute it (with Chef trademarks removed).
Chef is an infrastructure as code configuration system. The binaries are now proprietary. This is a FOSS replacement.
Huh. Given Ruby/Chef lost, are the Chef maintainers going for a final financial squeeze of whoever is still on the platform?
I think the license change and initial fork was back in 2019? It's been a while.
Did anyone ever tell them they lost? Are you volunteering?
A few years ago, Chef (configuration software, sort of like ansible) changed their license, and this is a fork which maintains the open source.
I legitimately have no idea what infrastructure provisioning tool to use anymore. I normally defaulted to Saltstack Masterless and Chef via Packer.
What "simple" tool is left anymore for me to create my immutable AMIs that aren't bound by some license?
I went back to shell scripts.
For me, Ansible and Pyinfra, but I've been leaning on shell scripts for very simple things that I know will be mostly the same for 5-10+ years, and sometimes I wrap those into larger playbooks.
They're all good and bad in different ways. You just need to pick one. Ansible is GPL3, opentofu is Mozilla Public License.
For immutable infra, shell scripts are king. You're essentially just installing packages and copying files around, there's really no need to get any more complicated than that.
For creating AMIs? Probably Ansible or something similar. Chef is great for ongoing management of servers, but not so good for a one-shot config run like you would do if you're creating AMIs.
Ansible? Fabric? Cloud init?
Fabric is a favourite for this kind of thing (although I'm configuring VMs at runtime instead of building AMIs)
[dead]