Config Management Alternatives: Ansible vs Puppet, Chef, Salt

Ansible is the default answer for most teams, but it is not the only answer. Puppet, Chef, and Salt each made different bets about agents, pull versus push, and the language you write in. Choosing well matters because config management is a five-year commitment once the fleet is wired to it. This post compares the four on the decisions that actually affect daily operations.

The Two Big Design Axes

Every config management tool answers the same two questions differently:

• **Where does the change get triggered?** Push means an operator or orchestrator connects to nodes; pull means nodes connect to a server on a schedule.
• **Does the target run an agent?** Agentless tools need only SSH/WinRM; agent-based tools require software (and certificates) installed and kept updated on every node.

Ansible and Salt push by default (Salt can also pull). Puppet and Chef pull on a schedule set by agents. Agentless is friendlier for small fleets; agent-based scales better once you pass hundreds of nodes.

Ansible: The Pragmatic Default

Agentless over SSH, YAML playbooks, and modules for every common operation. Strengths: the lowest learning curve, easy dry-runs, and orchestration of multi-step workflows (rolling deploys, migrations) as a first-class act. Weaknesses: performance at very large scale, and a lean on SSH that gets awkward across ten thousand nodes. For most Netbay-scale workloads — a handful to a few hundred VPS — it is simply the fastest team to onboard.

Puppet: Declarative Discipline

Puppet centers on a declarative resource model and usually runs master-agent with certificates on every node. Its DSL is explicit about resources, ordering, and auditing, and Puppet's strength is enforcing drift: a node that strays from its declared state gets corrected on the next pull. The tradeoff is operational weight — a Puppet server, its CA, and agent upgrades all become things you operate.

Chef: Everything as Code

Chef is built around Ruby: recipes, cookbooks, and the chef-client that converges each node. The model is flexible enough to describe almost anything, and test-driven tooling around cookbooks is mature. The price is that teams who do not write Ruby feel it immediately, and the kitchen-to-production pipeline demands real investment in your team before it pays off.

Salt: Fast and Event-Driven

Salt pairs a master with minions over ZeroMQ and can push or pull. It is fast because it moves data over its own channel rather than SSH, and its event bus supports real-time reactions. The tradeoff is more moving parts to secure and operate, plus a steeper mix of YAML and Python states for non-trivial work.

A Fairness Check You Can Run

Every tool can drive the same nominal goal. An honest way to compare is to implement one tiny job — ensure a user exists, a service is running — in each and run it locally:

# Ansible: agentless
ansible localhost -m ping

# Salt: fire a module from the minion
salt-call test.ping

# Chef: converge a local-mode recipe
chef-client --local-mode -o 'recipe[baseline]'

# Puppet: apply a manifest in no-op mode
puppet apply --noop --modulepath modules manifests/site.pp

# A minimal Puppet manifest exercising the same idea
node 'db01' {
  package { 'postgresql':
    ensure => installed,
  }
  service { 'postgresql':
    ensure => running,
    enable => true,
  }
}

Time the install, the dry-run, and the first real apply on both a fresh machine and an already-configured one. That measurement will tell you more about fit than any blog, because the winner is the tool your team can keep running correctly for years.

Takeaway

Ansible wins on onboarding speed and orchestration; Puppet and Chef pay off for enforcement-at-scale; Salt wins when you need speed and events. Re-evaluate only when the fleet actually grows past what your current tool manages comfortably. If you are starting today, run your comparison on throwaway instances — Netbay lets you deploy fresh Ubuntu boxes in under a minute on netbayhosts.in, delete them, and repeat.