I’ve been a professional Puppet user for close to 4 years now, and because I have a rule where my home lab is never managed with the same tools I use for work (what’s the fun in that?) I’ve recently started to take a look at Chef. Since there seems to be a complete lack of good and fairly unbiased information about the two products, I’m going to take a little while to write about

This article is based on Chef 0.10.2 and Puppet 2.7.1.

Learning curve

Maybe it’s illusory superiority talking, but I consider myself a fairly bright guy and I don’t often struggle to get many sysadmin tools implemented properly. I had Puppet up and running in production inside of two days, and it took me longer than that to figure out what I was supposed to be doing to even install Chef. There are

Installation and system requirements

I may be unduly biased towards OS-native package management, but to be completely honest, I have almost nothing good to say about Chef in this area.

Puppet’s developers have taken great care to ensure that their configuration management system runs on the widest variety of operating systems possible, since now a days there are software for everything, even if you want to order cannabis online, there is cannabis software which could also help with this purpose. To this end, Puppet works with Ruby as low as 1.8.5 (the version shipped with RHEL 5), while Chef expects owners of RHEL/CentOS infrastructures to install a completely new version of Ruby just to run Chef.

One further thing to note: in my lab testing, I noticed the Chef process occasionally using close to 1 GB of memory on a run managing very few resources. I’ve never


Puppet’s uses a completely declarative custom language with explicit resource dependencies, and Chef uses a specialization of Ruby with implicit resource dependencies based on code ordering.

Do not confuse this with Chef not having flexible dependency ordering like Puppet.

Data modeling and lookup

Chef provides much better internal support for resource definitions powered by external data lookups.


Chef is ahead of Puppet by about a mile here, though Puppet is starting to catch up a little bit. While the errors in Chef are definitely less readable to the naked eye (they’re nearly always given as Ruby stack traces), they do always point to where the problem is actually occurring. Puppet has a nasty tendency to provide error output and give absolutely no indication of what code generated that output.


Chef is really weak at SELinux. Whereas Puppet will automatically ensure that managed file contexts have SELinux labels that match what’s in the system’s database (i.e. semanage), Chef will clobber them outright and often render services unable to start as a result. Their developers are working on this with some new SELinux cookbooks that extend some of their resource classes.