Chef

Chef manages configuration through recipes written in Ruby, organised into cookbooks. Agents converge managed hosts toward the state the recipes describe, checking in with a Chef server.

Its distinguishing choice is that configuration is a real programming language, not a DSL over YAML and not a purpose-built declarative language like Puppet’s.

The trade that follows

Ruby means full expressiveness. Complex conditional logic, data transformation, helper libraries, and abstractions are all available because it is just Ruby, and for genuinely complicated configuration this is real power that Ansible’s YAML makes awkward and Puppet’s DSL constrains.

It also means configuration can be as hard to understand as any other program. Recipes with substantial embedded logic are code, and they need the discipline code needs — review, tests, structure. Chef takes this seriously, with ChefSpec for unit tests and Test Kitchen for convergence testing on real instances, and that testing story is better developed than anywhere else in the category.

The requirement, though, is Ruby fluency on the infrastructure team. Where that exists, Chef is powerful. Where it does not, recipes become copy-adapted from examples nobody fully understands, which is worse than a constrained tool that forces simpler solutions.

Where it sits now

Chef pioneered a great deal of what the category takes for granted, and its position has weakened. Ansible took the low-adoption-cost ground decisively, immutable infrastructure and containers removed much of the configuration-drift problem the category existed to solve, and the commercial history since the Progress acquisition has added uncertainty about the open-source path.

It remains capable and well engineered. I would not choose it for something new — Ansible for lower adoption cost, Puppet or Salt for continuous convergence — and where it is already established with people who know Ruby, it works well and replacing it is not obviously worth the effort.

The general pattern is worth noting: configuration management assumes long-lived mutable servers. Where infrastructure is rebuilt rather than modified, most of the category’s value moves to image building and the remaining need is much smaller.

See also: Ansible, Puppet, SaltStack, the comparison, and NixOS for the declarative-whole-system approach.