Reading Time: 8 minutes

Which one is appropriate for you?


Table of Contents

I. Puppet
II. SaltStack
III. Chef
IV. Ansible
IV. Conclusion


Configuring a single server with the required software is a reasonably simple task. However, if numerous servers need to have the same or similar software and configurations installed on them, the process would use numerous man-hours to complete, which would deplete your already strained resources. Without some form of automation, this task can become nearly insurmountable. With this task in mind, new configuration management tools were developed to address the need to deploy new servers with premade configurations and updates, that allowed for a smoother and more manageable automation process. To keep these servers syncing and to manage updates across a broad swath of hosts in a data center or cloud environment, automation tools like Puppet, SaltStack, Chef, and Ansible meet this need.

Choosing the right management tools for use for your infrastructure is a critical decision. This is why we are reviewing the available options for these projects. These tools offer the most benefits to DevOps and sysadmins alike. Hopefully, this information can point you in the right direction. While it is true that all the configuration tools mentioned above will most likely accomplish these tasks, each offers different methodologies and roles in somewhat different ways to achieve this goal. This article aims to show you some of the essential differences each software management platform provides. This will allow you to make a more informed decision as we try to touch on each software title and its benefits, and then offer an overview at the end




Puppet is one of the oldest and most trusted management tools in our list. Because of this, it offers a broader support base within the Puppet community as well as from the Puppet team. Puppet also provides an open-source edition of its software that can be installed on a wide variety of operating systems. The enterprise version of the software is, however, capable of encompassing larger systems like IBM's AIX or F5 Big-IP hardware. It should be noted that the Puppet master server can only be installed on Unix/Linux operating systems.

A Puppet deployment is usually comprised of a master server and multiple client machines (which are referred to as Agents). Puppet is one of the tools in this list which uses its own unique language that is based on Ruby. The Puppet DSL (or Domain Specific Language) is used to describe the desired state of your system within a file, which is called a manifest file. Manifest files are fundamentally a set of configurations or tasks that determine how your network and operating system resources (such as services, packages, and files) are configured. Puppet then compiles the manifest files into catalogs and pushes each catalog to its designated node so that the node is reconfigured to the desired state across the entire infrastructure.

Puppet additionally offers an intuitive and straightforward web-based UI that's used to complete a more significant number of tasks, including real-time node management. Additionally, because Puppet is set up in a multi-master architecture form, if the currently active master goes down, another master will replace the previous master to avoid degraded availability. 

Puppet updates the configuration of the nodes by having the clients check the master for updated manifests and then pulls the new configurations down from the Master server. Because of this feature, Puppet is more system-administrator oriented than many of the other tools noted here. A downside of Puppet is that there is no immediate remote execution available for the nodes. Additionally, Puppet has a steeper learning curve, due to the required knowledge of the Puppet DSL and Ruby programming languages.




SaltStack (also referred to as Salt) is one of the newer tools in this list. It is, however, still very relevant in the software configuration management realm. Salt has a relatively active community and effective support. Salt is designed to allow for low-latency, high-speed communication, and data transmission between the nodes for remote execution. Salt is designed to work with the Unix/Linux and Windows operating systems, but the Master Salt server can only work on Unix/Linux operating systems.

SaltStack is composed of a Salt Master, which is the central Salt server, and clients who are called Salt Minions, which run as agents on each of the node machines. Mastering the language of Salt is relatively easy as it's human-readable configurations use Python and YAML files, which is one of the more natural and straightforward data structures. While Puppet works in a manner where the nodes request the updates, Salt works in opposition to this. The Salt Master pushes all the configurations to all the client machines. Additionally, Salt serves as an asynchronous file server, which increases the speed of the file transfers that serve the Salt Minions. Deployment speed is one of the main goals of Salt's philosophy.

Salt also can run in a multi-master configuration. If a Salt master server goes down, the agents will connect to another master listed in the configs. This feature increases the overall availability and redundancy of the system as a whole. An additional benefit of Salt is that it allows for parallel execution of multiple commands at once. These commands are encrypted via AES (Advanced Encryption Standard) and pushed to the client nodes via the SSH protocol. One last advantage of Salt is that it can manage multiple masters. Salt offers a Web UI as well; however, it has limited capabilities and features.




Chef began as an internal server-to-server deployment tool before it was ultimately released as open-source software in 2009. A significant benefit of Chef is that it also offers a large support community with extensive documentation and guidance. The Chef master and node software works on both Unix/Linux systems, but only the client and workstation versions can be deployed on Windows servers. 

Chef's configuration options consist of Cookbooks and Recipes. The recipes are the definition files that can be combined with attributes, files, libraries, and other recipes to build Cookbooks. These cookbooks can then be used for client deployment. 

Chef consists of 3 main components:

  • Chef Workstation — The Chef workstation is used by system engineers to create, test, and deploy the cookbooks to the Chef master servers.
  • Chef Master Server — Chef Servers are essentially the hub where all the Chef configuration data is stored. This information includes cookbooks, server data, and other relevant info.
  • Chef Client — The Chef client is the end-node machines managed by Chef master servers. These servers periodically pull and execute cookbook configurations from the Chef master server.

Chef's programming language is similar to Puppet, in that it uses a DSL (Domain Specific Language) unique to Chef, but it supports scripts written in Ruby as well.

Chef is primarily set up as a Chef master server, as well as a backup server in case the central Chef master server goes down. If an outage occurs, the backup master server will replace the central Chef master server. This is how redundancy is incorporated into the Chef environment. Chef also offers additional cloud and infrastructure automation, in addition to automated workflows, which are used to provide continuous delivery to the client machines. One stipulation that should be noted; The primary language favors programmers as it requires the use of the DSL/Ruby oriented scripting in the Cookbooks. Chef and its infrastructure are very stable and built for reliability. Chef also offers sequential execution order, as opposed to, for example, Salt, which provides parallel execution.




Ansible is one of the more modern tools utilized as a configuration management solution. It is arguably one of the most popular software due to its simplicity and straightforward configuration. Like the previous tools, Ansible supports both Windows and Unix/Linux client machines, but the Ansible master server requires a Unix/Linux-based server. 

In contrast to the previous tools, only an Ansible master is necessary to run because Ansible uses the SSH (or RDP for Windows) protocols to open a connection to the client servers to execute its sequential commands. Ansible is similar to Puppet in that the Ansible configuration files are Python-based and use YAML files for the structured data. These files are called Playbooks. Ansible also supports a Python API, which can be used to respond to specific events to exert control of the nodes themselves. Ansible can also be used via a command-line interface. Using a CLI interface in this way would not require the use of a configuration file if a simple task such as restarting a server. For more complex tasks, a playbook is necessary since the master server pushes the information to the client nodes. Ansible is also suitable for real-time remote execution of commands or application management.

In regard to redundancy, Ansible is usually configured as a single active master server (referred to as a Primary Instance) as no agents are required to connect to it. A secondary master can be configured to take over if the master server goes down. Because Ansible uses an agent-less approach, it can deploy changes or push updates relatively quickly to all the nodes by an engineer. A downside to Ansible is that the client computers do not check for any periodic configuration changes on the primary master.



In simple terms, a configuration manager provides an abstraction layer between a servers existing configuration and its desired state. This goal is accomplished by focusing more on a specific outcome instead of the verbose tasks needed to accomplish them.  

In our review of these four products, if we look for a conclusion based solely on popularity, the clear winner is Ansible. This is due to the fact that a much wider group of admins chooses to use Ansible as their primary configuration management tool compared to the other products in this article. Ansible does have its advantages as it is directed more towards a SysOps oriented role in regard to its structure and paradigm. Salt is similar in this aspect, but it is unlike Puppet and Chef as they are more Developer oriented. Additionally, Ansible is one of the easier options in this list to set up, configure and begin using right away. 

Puppet, on the other hand would be the one that is most approachable and reliable from the standpoint of usability. Although as previously outlined, a working knowledge of Ruby is necessary to take the full advantage of its wide range of features, structure, and scalability. Puppet’s configuration can become very granular and sometimes complicated, but it is the safest bet if you are looking for a non-heterogeneous software environment. 

If you are looking for a configuration tool that is streamlined towards a more uniform infrastructure, Ansible and Salt would be more suited towards that goal. Salt in and of itself is one of the more reliable and robust tools on this list, but is brought down a notch due to the Web UI’s difficulty for beginners to understand some the deeper configuration options available. However, it makes up for this by its advanced scalability options and an approachable work environment from the SysOps or administrator's perspective. There are also multiple addons available which improve and extend the abilities of UI which enhance the usability and functionality. 

Chef in and of itself is a very straightforward and well-designed tool. It offers an improved approach for ease of access and a greater level of practicality than Puppet. As previously mentioned, Chef can pose a notable learning curve for SysOps or system administrators who are lacking development oriented experience, as it requires a broader understanding of programming languages and experience. 

In conclusion, Ansible is a straightforward choice for entry level configuration management because of the available documentation, its structure, and ease of accessibility. Puppet is also a solid tool, but a user or team will be required to learn new coding procedures and function in order to conquer the steeper learning curve when using its DSL (Domain Specific Language) programming. In terms of usability, scalability and multi-environment options, Salt will resonate most clearly with system administrators who wish to take advantage of it many options and highly appealing scaling capabilities. Chef has a well-designed layout, structure and offers a considerable level of stability. There may be some initial difficulty with the learning curve as it is more oriented to the skills of a programmer. All of these tools perform specific role when configuring your infrastructure and its desired states. Their utilization will depend entirely on your configuration needs, support personal and the convenience level needed to implement them.


We’d love you to join us!

Give us a call at 800.580.4985, or open a chat or ticket with us to speak with one of our knowledgeable Solutions or Experienced Hosting advisors to learn how you can take advantage of these techniques today!

Avatar for Daniel Torma

About the Author: Daniel Torma

Latest Articles

Change cPanel password from WebHost Manager (WHM)

Read Article

Change cPanel password from WebHost Manager (WHM)

Read Article

Change cPanel password from WebHost Manager (WHM)

Read Article

Change cPanel password from WebHost Manager (WHM)

Read Article

Change the root password in WebHost Manager (WHM)

Read Article