Compare Configuration Management Tools — Ansible, Chef & Puppet

In this article, let’s attempt to perform a Like to like comparison between the most popular configuration management systems — viz. Chef, Puppet, and Ansible.

The idea is not to identify the best among the three, as each tool has its own ups and downs, but to provide an overview of the three to enable an easier decision on choosing a tool for your organization’s usage.

Do feel free to ask us for more information at —

If you would want to understand the details about what configuration management is and the concepts in general — read them in one of our previous blogs here.

ansible, chef, puppet, comparison

The above Table attempts to perform a like-to-like comparison, and we will try to elucidate the same in words below.

Scripting Language / DSL (Domain Specific Language)

Each of these tools has their own mechanism around Configuration and architecture. Configuration languages or DSL are different for each of these CM tools, and some tools will demand a higher learning curve to be mastered so should be considered as a parameter for consideration for selection w.r.t the resources in the team.

CM Tools prefer scripting languages like Ruby and Python in general, so any experience with these would help.

  • Puppet — Uses Puppet DSL — which is a Custom scripting language, based on Ruby, if you are aware of Ruby, this is fairly clearer and the hop is not far
  • Chef — Uses Ruby
  • Ansible — Uses Python + YAML


CM Tooling architecture is different in each of the cases. The general architecture is Master — Agent architecture, where one of the nodes are assigned as the master server, which holds and orchestrates all of the jobs, while the agents are installed in each of the target nodes, which simply execute the jobs and respond back with the status back to the master.

Installation & Setup

Based on CM Tooling architecture, the installation and setup could be complicated or not. Having an agent helps esp if the agent-master communication is through encrypted and custom protocols. Ansible is the only odd one of the lot, which achieves the same through a much simpler SSH.

  1. — Many articles emphasize the complexity of building and maintaining the Chef Workstation, though personally, we believe its a matter of perspective
  2. Puppet — Communication between the two needs to be established as a Certificate Signing process, which again can be achieved once the capability is set up.
  3. Ansible — This is probably the easiest, and all commands executed with target Nodes are via SSH.

Do note that While Unix / Linux systems come with SSH enabled by default, for Windows 10 / Windows Server 2018 (updated) / Windows Server 2019 — onwards OpenSSH is embedded within Windows (might need activation though)

Communication & Control

The stability of Master nodes and their mechanism to communicate with the agents are key to the success of this automation. Let’s consider the different methods by which each of these CM tools communicates with respective nodes.

  1. — Configurations conceptualized and maintained on Check Workstations are pushed on to Chef Servers, which then gets pushed to respective Chef nodes (agents), where they are executed.
Chef Architecture

2. Puppet — Master / Node communication is via SSL, and hence Certificate Signing process is to be established between these nodes. Puppet master holds the configuration repository, which is then synchronized with the Agents. Post execution, agents respond back with the facts to the puppet master

Puppet Architecture

3. Ansible — This is probably the easiest of the architectures, and all commands executed with target Nodes are via SSH. Ansible master nodes takes the Playbook and the CMDB (list of all assets as the inputs) — which is not much different from other tools and pushes the configurations to the nodes.

Ansible Architecture

Infrastructure Requirements

(More granular comparison in the table above)

Agents — Installation and Management

Every time a new Node is to be created, the installation and configuration of Agents on these nodes becomes an additional task. In a world with constantly upgrading software instances, upgrading of management of the agent software itself requires some amount of effort, though this is not very complicated and can be automated in most instances.

  1. — Agents are to be installed in node under management
  2. Puppet — Agents are to be installed in node under management
  3. Ansible — No Agents are needed for Ansible and runs on a Server only mode. All commands are executed over SSH on the target node. This can be considered as an advantage for Ansible, earning some brownie points on comparison

Dedicated Infra

It is a good idea to allocate some amount of dedicated infra for each of these tools, as other than easiness to name/manage and upgrade these servers in isolation, cost and team access (Access security) management becomes easier as well. Having said that, technically, it is not mandatory for some tools to have a dedicated infrastructure.

  1. — Yes for the Chef Server
  2. Puppet — Yes for the Puppet Master
  3. Ansible — Not needed. Any node can be used as a Ansible controller/master

OS Support

All the CM tools have a common support matrix here. The master/controller nodes are designed to be installed on a Unix or Linux environment and can manage Nodes of any Operating system (Unix/ Linux /Windows)

Backup Servers / Availability

Availability for each of the CM tools is considered quite high and shouldn’t be a cause of concern. In the event of server failure of the master node, each of them has the option of a backup server / a secondary master which will continue to support the ongoing jobs.

  1. — Option of Backup Server
  2. Puppet — Option for an Alternative Master
  3. Ansible — Option of Secondary Instance

In Summary, there are some fundamental differences between how each of these CM tools work/ operate to achieve exactly the same thing. I have never heard of any organization migrating from one tool to another, as each of these provides same/similar capabilities and the case is not too strong to justify the cost. Hence, it becomes even more important to emphasize choosing the right tool which fits your organization/culture/skillset within the organization/culture.

Do feel free to kick off a conversation around these tools by sending us an email —

We at BridgeApps UK offer Infrastructure Management to our Customers, covering almost all aspects of DevOps & Cloud /OnPremise Infrastructure. Do feel free to enquire more at —

Originally published at on February 20, 2022.



Passioniate Deep Tech bunch — focussing on Infra, DevOps, Microservices, Cloud and Integration. Connect with us for our services.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
D Kuruppath

D Kuruppath


Passioniate Deep Tech bunch — focussing on Infra, DevOps, Microservices, Cloud and Integration. Connect with us for our services.