Courses Infrastructure as Code & automationBeginner · Configuration management

Chef, Puppet & Salt

The config-management landscape.

Beginner12 min · lesson 8 of 23

Ansible is the most popular configuration-management tool today, but it is one of four you will hear about, and knowing how they differ helps you read existing setups and choose for a new one. The big distinction is agent vs agentless and push vs pull: Ansible is agentless and push-based (a control node pushes config over SSH), while Chef, Puppet, and Salt traditionally use an agent on each host that pulls its configuration from a central server. Each philosophy has tradeoffs in scale, complexity, and how quickly changes propagate.

The four config-management tools

agentless / push (simple to start)

Ansible

YAML, over SSH, no agent — today’s default

agent / pull (scale, continuous)

Puppet

declarative DSL, mature, agent pulls

Chef

Ruby "recipes", agent pulls

Salt

YAML + fast event bus, agent or agentless

Agentless (Ansible) is easy to adopt; agent-based (Puppet/Chef) shines at large scale with continuous enforcement.

Agent-based: Puppet and Chef

Puppet and Chef predate Ansible and are built around an agent on every node that periodically pulls its desired configuration from a central server and enforces it continuously — so drift is corrected automatically on each run, even without a human triggering it. Puppet uses its own declarative language; Chef uses Ruby-based "recipes" and "cookbooks." The agent/pull model scales well to thousands of nodes and gives continuous enforcement, at the cost of running and securing that agent and central server. You will meet them in established enterprises.

Salt, and how to choose

Salt (SaltStack) uses YAML like Ansible but adds a fast message bus for near-real-time command execution across huge fleets, and can run agent-based or agentless. For choosing: Ansible is the easiest to adopt and dominates new projects because there is no agent to manage; Puppet/Chef suit large, long-lived estates that want continuous pull-based enforcement; Salt suits very large fleets needing fast, event-driven control. Most teams today reach for Ansible unless they have a specific reason not to — which is why this course teaches it as the default.

Config management is fading toward immutable infrastructure

A trend worth knowing: as containers and immutable infrastructure spread, the role of traditional configuration management shrinks. Instead of configuring a long-lived server in place (and fighting drift), teams increasingly bake a fully-configured image (with Packer or a Dockerfile) and replace the whole server to change it — no in-place mutation, no drift. Config-management tools remain essential for many estates, but for new cloud-native systems the pattern is often "provision immutable images with Terraform" rather than "configure mutable servers with Ansible." Know both; choose by context.

Ansible: playbooks & inventoryModules: reusable infrastructure