[Blog](/blog)

Show links

Resources

[Blog](/blog)

[Breaches](/breaches)

[eBooks, reports, & more](/resources)

[Events](/events)

[News](/news)

[DevOps](/category/devops)

Show links

Categories

[Attack Surface Management](/category/attack-surface-management)

[Company News](/category/company-news)

[Compliance and Regulations](/category/compliance-and-regulations)

[Cybersecurity](/category/cybersecurity)

[Data Breaches](/category/data-breaches)

[DevOps](/category/devops)

[Human Cyber Risk](/category/human-cyber-risk)

[Risks and Vulnerabilities](/category/risks-and-vulnerabilities)

[Third-Party Risk Management](/category/third-party-risk-management)

[Vendor Risk Management](/category/vendor-risk-management)

[Chef vs Docker: What are the Differences?](/blog/docker-chef)

Publish date

November 19, 2024

{x} minute read

# Chef vs Docker: What are the Differences?

[Get a demo](/contact-sales)

[Free trial](/demo)

[Download the PDF guide](#)

[Free trial](/demo)

Written by

[Abi Tyas Tunggal](/team/abi-tyas-tunggal)

Writer and Senior Product Manager at UpGuard.

Abi's work has influenced leaders across cybersecurity, technology, and financial services.

Reviewed by

[Kaushik Sen](/team/kaushik-sen)

Chief Marketing Officer

Kaushik has a background in software engineering, enterprise solution architecture, and data analytics. He brings a unique, data-driven perspective to cybersecurity education.

Table of contents

Free resource

###

[Download now](#)

One of the things that sysadmins and devops have long regarded as a necessary evil is the overhead time wasted twiddling one’s thumbs while waiting for a new server’s creation. With the advent of virtualization and cloud computing and the resultant massive increase in need for computing, the frequency of new-server creation has only increased as well.

Enter tools like [Docker](https://www.docker.com/) and [Chef](https://www.chef.io/). In a nutshell, they both make it much easier to define and roll out machine-level changes quickly in a multi-server environment. But the roads they take to arrive to the location of this holy grail are very different indeed, as we shall now see.

## What They Are

[Docker](/blog/docker-vs-vmware-how-do-they-stack-up) started life as an open-source side project called dotCloud. But when its creators realized its potential, it quickly became a top priority. It is a Linux-only tool developed in the Go language, and it builds on LinuX Containers (LxC) to create Virtual Environments (VE’s). Now pay attention kids, because a VE is radically different from a virtual machine (VM). A VM is created by a virtualizer tool or emulator (HyperV, VMWare, etc), and it is a full image of a source machine, including the OS, disk config, network and even virtual processors. The resulting bloated mass eats up quite a bit of disk space and is slow to deploy and start up.

Docker solves this problem by isolating the OS from the kernel. It then creates a ‘level-zero’ package from the kernel-machine baseline. Any subsequent changes are captured as snapshots called namespaces, and can be run in standalone containers as virtual systems. Snapshots capture only the changes from the ‘base template’, not the full machine setup (unlike VM’s). From this point, namespaces are stored and can be installed on their own to create full environments on any Docker-ready host.

[Chef](/blog/chef-open-source-vs-hosted-chef-vs-on-premises-chef) is a CM tool. Together with [Puppet](https://puppet.com/), they are the big boys of the CM marketspace. It was first released in 2009, and it helps admins and devops professionals manage their environments by making it easy to roll out changes and even provision new machines. Chef fully supports Windows as well as Linux and Unix, and it also boasts a proper GUI (though still not as slick as Puppet’s). However, there are complaints that Chef is a muddle to understand for newbies, and the documentation is not easy to wrap your head around, especially for newbies. 

## How They Work

[Docker](/blog/docker-vs-lxc) doesn’t create its own virtual computer with a distinct OS and processors and hardware emulation. A VE is a lite VM; it rides on the already existing kernel’s image of the underlying hardware, and only creates a ‘container’ in which to run your apps. It can even recreate the OS, since the OS is just another app running on the kernel. Think of Docker as a turbocharged version of LxC; it offers the following additional features that LxC doesn’t:

* Portable deployment across machines: you can use Docker to create a single object containing all your bundled applications. This object can then be transferred and quickly installed onto any other Docker-enabled Linux host.
* Versioning: Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc.
* Component reuse: Docker allows building or stacking of already created packages. For instance, if you need to create several machines that all require Apache and MySQL database, you can create a ‘base image’ containing these two items, then build and create new machines using these already installed.
* Shared libraries: There is already a public registry (<https://hub.docker.com/>) where thousands have already uploaded the useful containers they have created. Again, think of the AWS common pool of different configs and distros – this is very similar.

For an exhaustive list of Docker’s capabilities, [follow this link](https://stackoverflow.com/questions/17989306/what-does-docker-add-to-lxc-tools-the-userspace-lxc-tools).

[Chef](/blog/puppet-vs-chef-revisited) makes use of a master-agent setup, in which a central master server coordinates and sends out instructions to a number of agents installed on all other client nodes. The agents can even be installed from the client side using the ‘knife’ tool and SSH for easy deployment. All this is managed by either a GUI or a CLI using base Ruby as the DSL. The GUI is useful, but for most advanced tasks it will be inevitable that one will have to learn Ruby. Chef and other CM tools utilize an infrastructure-as-code model – to work effectively all infrastructure nodes being managed must be expressible purely in code, in this case Ruby. You define the changes you want and the subset of machines you want those changes to be applied to, then the Chef server does the rest. For instance, if you need to upgrade all Windows 2008 servers with the .Net 2.0 framework to .Net 3.0, you will define this on the Chef server and it will be rolled out. One caveat though – Chef’s implementation of ‘push’ from master to agents is still sub-par; the crowdsourced recommendation is that you instead configure your agents to periodically ‘phone home’ to check if the master has any changes for them to deploy on their machines. Needless to say, this is a major annoying drawback that Chef’s creators are working to resolve. 

Chef configs are packaged into JSON files called ‘cookbooks’, and the software can run in either a client-server mode, called Chef-server, or standalone mode called ‘Chef-solo’. Part of Chef’s appeal is that a huge number of cookbooks have been created and shared freely on the net.

## Conclusion

So which is best, [Docker](/blog/docker-vs-vagrant) or Chef? As with so many complex choices, the answer is “It depends.” Depends on what you want to achieve, and the level of trust you have in the tool – Chef is tried and tested, while Docker is still very new and even its creators hesitate to recommend it for production environments. Actually, Docker and Chef can even complement each other; Docker is used for quickly provisioning new servers, and Chef is used for rolling out the small, detailed changes to existing machines, a task for which Docker may be ill-suited. Alternatively, Docker would be ideal in a setup mainly requiring creation of new read-only server instances, in which the change consists of an entirely brand-new server.

## References

<https://phunehehe.net/docker-vs-chef-vagrant/>\
<https://stackoverflow.com/questions/16047306/how-is-docker-different-from-a-virtual-machine>\
<https://groups.google.com/forum/#!topic/docker-user/NF86nnPMZ6k>

Free resource

###

[Download now](#)

## Related posts

Learn more about the latest issues in cybersecurity.

DevOps

#### [Boost Your Cybersecurity with DevSecOps](/blog/devsecops)

Explore how DevSecOps can significantly enhance your organization's cybersecurity posture by integrating security into your development process.

[](/team/leah-sadoian)

[Leah Sadoian](#)

July 4, 2025

DevOps

#### [Release Testing Basics](/blog/release-testing-basics)

Learn how to start testing your software before releasing it to the public, an essential part of the Software Development Lifecycle (SDLC).

[](/team/upguard)

[UpGuard Team](#)

November 19, 2024

DevOps

#### [SCOM vs Splunk](/blog/scom-vs-splunk)

How does Microsoft's data center monitoring solution compare to Splunk's leading platform for IT operational intelligence? Read more to find out.

[](/team/abi-tyas-tunggal)

[Abi Tyas Tunggal](#)

November 19, 2024

DevOps

#### [Agent vs Agentless Monitoring: Why We Chose Agentless](/blog/agent-vs-agentless-and-why-we-chose-agentless)

Agentless data collection involves collecting data without installing any new agents. Learn why we didn't choose agent monitoring.

[](/team/upguard)

[UpGuard Team](#)

November 19, 2024

DevOps

#### [LXC vs Docker: Why Docker is Better](/blog/docker-vs-lxc)

LXC (LinuX Containers) is a OS-level virtualization technology and Docker is an extension of LXC’s capabilities achieved through a high-level API.

[](/team/abi-tyas-tunggal)

[Abi Tyas Tunggal](#)

July 4, 2025

DevOps

#### [DigitalOcean vs Linode](/blog/digitalocean-vs-linode)

DigitalOcean has made a splash in the world of virtual private servers but Linode has steadily built a quality platform.

[](/team/abi-tyas-tunggal)

[Abi Tyas Tunggal](#)

July 4, 2025

[All posts](/blog)

Experience superior visibility and a simpler approach to cyber risk management

[Get a demo](/contact-sales)

[Free trial](/demo)
