Configuration Management: Ansible, Puppet, Chef, SaltStack

CI/CD CI/CD 9 min read 1708 words Intermediate ExcellentWiki Editorial Team

Configuration management is the practice of maintaining system settings, software packages, and service states in a consistent, automated, and repeatable manner. Instead of SSHing into servers to install packages or edit configuration files, configuration management tools define the desired state in code and apply it across thousands of machines with a single command. This guide covers the four dominant configuration management tools — Ansible, Puppet, Chef, and SaltStack — and the principles that make them effective.

Why Configuration Management Matters

Without configuration management, servers drift from their intended state over time. An engineer installs a debugging package that never gets removed. A critical security patch gets applied on some servers but not others. A configuration file gets edited manually and the change is lost when the server is reprovisioned. Configuration drift is the leading cause of environment-specific bugs and security vulnerabilities.

Configuration management tools enforce idempotency — applying the configuration multiple times produces the same result. If a package is already installed at the specified version, the tool skips it. If a configuration file already contains the intended setting, it is not touched. This property makes configuration management safe to run repeatedly and suitable for scheduled enforcement.

The Four Desired State Paradigms

Configuration management tools fall into two paradigms: push-based and pull-based.

Push-based tools (Ansible, SaltStack in push mode) connect from a central control node to managed nodes and execute configuration. The administrator initiates the run. This model is simpler to understand and debug but requires network connectivity from the controller to all nodes.

Pull-based tools (Puppet, Chef, SaltStack in pull mode) run an agent on each managed node that periodically connects to a master server, fetches the desired configuration, and applies it. This scales to tens of thousands of nodes without requiring the central server to maintain persistent connections.

Ansible

Ansible is the most popular configuration management tool as of 2026. It was acquired by Red Hat in 2015 and benefits from a large community and extensive module library. Ansible is agentless — it connects over SSH or WinRM and pushes configuration to managed nodes.

Architecture

Ansible’s control node runs on any Linux or macOS system. The inventory file defines managed hosts, optionally organized into groups. Playbooks — YAML files containing plays and tasks — describe the desired state. Modules are the units of work: ansible.builtin.package installs packages, ansible.builtin.copy manages files, ansible.builtin.service controls services.

Ansible Galaxy is the community hub for roles — reusable collections of playbooks, files, and templates. Organizations publish thousands of roles for common configurations: Nginx, PostgreSQL, Docker, Kubernetes, and monitoring stacks.

Key Features

Agentless operation. No software needs to be installed on managed nodes beyond Python (which is present on virtually all Linux distributions). This drastically reduces the operational overhead of deploying and maintaining agents.

Idempotent modules. Most Ansible modules check the current state before making changes. The package module checks whether a package is already installed before running the package manager. Tasks report “ok” if no change was needed and “changed” if modification occurred.

Templates with Jinja2. Configuration files are generated from Jinja2 templates, enabling dynamic content based on variables, facts about the target system, or secrets from vaults.

- name: Configure Nginx virtual host
  ansible.builtin.template:
    src: vhost.conf.j2
    dest: /etc/nginx/sites-available/{{ domain }}
  notify: reload nginx

Ansible Vault encrypts sensitive data — passwords, API keys, certificates — within playbooks. Encrypted files are decrypted at runtime using a password or key file.

When to Use Ansible

Ansible is the best choice for most organizations starting with configuration management. Its low barrier to entry, agentless design, and readable YAML syntax accelerate adoption. Ansible excels at:

Bootstrapping new servers
Application deployment (multi-tier rolling updates)
Network device configuration (Cisco, Juniper, Arista modules)
Ad-hoc task execution across fleets

Puppet

Puppet is one of the oldest configuration management tools, first released in 2005. It uses a declarative domain-specific language and a pull-based agent-master architecture. Puppet was acquired by Perforce in 2022 and continues to be widely used in large enterprises.

Architecture

The Puppet master runs on a central server (or load-balanced master tier). The Puppet agent runs on each managed node and connects to the master every 30 minutes by default. The agent submits facts about the node (OS, kernel, IP address, memory) and retrieves a catalog of desired state. The catalog, compiled from Puppet manifests and Hiera data, describes every resource to manage and the order of enforcement.

Puppet’s resource abstraction layer normalizes system resources across operating systems:

package { 'nginx':
  ensure => installed,
---

service { 'nginx':
  ensure => running,
  enable => true,
  require => Package['nginx'],
---

Key Features

Resource abstraction. Puppet abstracts operating system differences. The same package resource works on apt-based, yum-based, and Windows systems because Puppet maps the resource type to the appropriate package manager.

PuppetDB. Puppet’s database stores facts, reports, and catalog data for all nodes. PuppetDB powers inventory queries (“show all CentOS 7 nodes with less than 4 GB RAM”), compliance reporting, and infrastructure visualization.

Enforcement mode. Puppet agents self-correct configuration drift on their regular checkin interval. If a file is deleted, the agent recreates it on the next run. If a service stops, the agent restarts it. This auto-remediation is Puppet’s signature strength.

When to Use Puppet

Puppet excels in large-scale enterprise environments with thousands of nodes, where its self-healing agent model and robust reporting justify the operational overhead of running Puppet masters and PuppetDB.

Chef

Chef uses Ruby-based domain-specific language (DSL) for configuration and a pull-based client-server architecture. Chef was one of the first tools to popularize “infrastructure as code” and remains widely deployed, especially in organizations with strong Ruby expertise.

Architecture

Chef’s architecture includes the Chef server (hosts cookbooks, policies, and node data), Chef workstation (where cookbooks are authored), and Chef client (runs on each node). Nodes check in with the server at a configurable interval, download their run list, and execute the corresponding cookbooks.

Chef resources manage system state:

package 'nginx' do
  action :install
end

service 'nginx' do
  action [:enable, :start]
end

template '/etc/nginx/sites-available/default' do
  source 'default.erb'
  variables(server_name: node['hostname'])
  notifies :reload, 'service[nginx]'
end

Key Features

Chef Infra Client. The agent runs on each node as a Ruby process. It handles convergence — the process of bringing the node to the desired state — and reports success or failure to the Chef server.

Chef Supermarket. The community cookbook repository provides thousands of pre-built cookbooks for common configurations. Organizations publish their own cookbooks within private supermarkets.

Chef InSpec. Chef’s compliance automation tool integrates configuration management with automated compliance testing, enabling “audit as code.”

When to Use Chef

Chef is a strong choice for Ruby-centric teams and organizations that have already invested in the Chef ecosystem. Chef’s testing tooling (Test Kitchen, ChefSpec, InSpec) is mature and well-respected.

SaltStack

SaltStack (now part of VMware, operating as Salt Project under open-source governance) is known for its speed and scalability. It uses a remote execution engine that can run commands across thousands of nodes in seconds.

Architecture

Salt’s master-minion architecture uses ZeroMQ for communication, enabling high-speed message passing. The master sends commands to minions, which execute them and return results. Salt uses a state file format (YAML with Jinja2) similar to Ansible but with its own state module system.

Salt States define the desired configuration:

nginx:
  pkg.installed: []
  service.running:
    - enable: True
    - require:
      - pkg: nginx

Key Features

Reactor system. Salt’s event-driven reactor can trigger actions based on infrastructure events — a new server joining the network, a service failing, a certificate expiring. This enables self-healing infrastructure that responds without human intervention.

Salt SSH. Similar to Ansible’s agentless mode, Salt SSH connects over SSH without requiring a Salt minion. This is slower than the ZeroMQ minion mode but useful for initial bootstrapping or environments where agents cannot be installed.

Grains and Pillar. Grains are static system information collected by the minion (OS, kernel, hardware). Pillar is encrypted data securely distributed to targeted minions. Separating configuration data from state logic follows security best practices.

When to Use SaltStack

SaltStack is ideal for large-scale deployments (10,000+ nodes) where speed and event-driven automation are critical. Its remote execution engine is unmatched for ad-hoc task execution at scale.

Frequently Asked Questions

What is the difference between configuration management and infrastructure as code?

Configuration management (Ansible, Puppet, Chef, Salt) manages software packages, services, and configuration files on existing servers. Infrastructure as code (Terraform, CloudFormation) provisions the servers themselves — VMs, networks, load balancers. The two are complementary: Terraform provisions the infrastructure, Ansible configures what runs on it.

Is Ansible better than Puppet?

For small to medium environments (under 500 nodes), Ansible’s agentless simplicity makes it the better choice for most teams. For very large environments or those requiring self-healing configuration enforcement, Puppet’s agent model and PuppetDB reporting provide advantages. Evaluate based on team expertise, scale, and compliance requirements rather than feature checklists.

Should configuration management be run as part of CI/CD?

Yes. Configuration management playbooks should be tested and applied through CI/CD pipelines. Test new playbooks in a staging environment with Kitchen-Ansible or Molecule before applying to production. Use a CI/CD pipeline to run configuration management on a schedule (drift correction) and in response to infrastructure changes.

How do you handle secrets in configuration management?

Ansible Vault encrypts secret data within playbooks. Puppet uses Hiera with eyaml backend for encrypted data. Chef has encrypted data bags and Chef Vault. SaltStack uses encrypted Pillar data. For modern environments, integrate with a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) that configuration management tools can query at runtime.

Conclusion

Configuration management transforms server administration from manual, error-prone SSH sessions into automated, idempotent, and auditable processes. Ansible offers the gentlest learning curve and broadest adoption. Puppet provides enterprise-grade self-healing at scale. Chef excels in Ruby-centric environments. SaltStack leads in event-driven automation and raw execution speed. The common denominator is that all four tools eliminate configuration drift and make infrastructure reproducible.

For a comprehensive overview, read our article on Artifact Management.

For a comprehensive overview, read our article on Ci Cd Best Practices.

Share this article

X LinkedIn Facebook Email