# A small Puppet manifest
class profile::nginx (
  String $version = '1.24.0-1ubuntu2',
) {
  package { 'nginx':
    ensure => $version,
  }
  file { '/etc/nginx/nginx.conf':
    ensure  => file,
    owner   => 'root',
    mode    => '0644',
    content => template('profile/nginx.conf.erb'),
    notify  => Service['nginx'],
  }
  service { 'nginx':
    ensure => running,
    enable => true,
  }
}

Chef: Ruby, InSpec, Test-Kitchen

Chef is conceptually similar to Puppet — agent-based, pull, central server — but the DSL is Ruby. For Ruby shops, that is a feature: cookbooks are real Ruby code, complete with conditionals, iteration, and library reuse. For non-Ruby shops, it can be a barrier.

Chef's defining strength is the testing toolchain. Test-Kitchen drives cookbook development against ephemeral VMs (Vagrant, Docker, AWS, Azure). InSpec tests compliance against running systems with a clean DSL — InSpec profiles are now used independently of Chef cookbooks for CIS benchmark and DISA STIG enforcement across many estates. Chef Habitat extends the model into application packaging.

The corporate context shifted in 2020 when Progress Software acquired Chef. The open-source rename ("Chef Infra") and licence changes (effective Apache-2.0 with attribution requirements for the underlying tooling) caused friction in the community. The product remains capable; the community is smaller than it was at peak.

# A small Chef recipe
package 'nginx' do
  version '1.24.0-1ubuntu2'
  action :install
end

template '/etc/nginx/nginx.conf' do
  source 'nginx.conf.erb'
  owner  'root'
  mode   '0644'
  notifies :reload, 'service[nginx]', :delayed
end

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

Pick Chef when: Ruby is already the team's language; InSpec compliance scanning is central to the use case; Test-Kitchen-style cookbook development workflow matters; team has existing Chef investment.

SaltStack: Event Bus, Real-Time, Big Fleets

SaltStack is the dark horse of the four. The architecture pairs YAML state files (similar to Ansible playbooks) with a ZeroMQ-based event bus that lets the Salt master push commands to thousands of minions in seconds. Salt-master/minion can do pull mode like Puppet, push mode like Ansible (via salt-ssh), or true real-time orchestration via the event bus and the reactor system.

For genuinely large fleets — 10,000+ nodes — and for use cases that need event-driven response (a host's CPU spikes, fire a Salt state to investigate), SaltStack's architecture has no real equivalent. The trade-off is operational complexity: the event bus, the reactor, beacons, and the engines stack create a powerful system that small teams struggle to operate.

The corporate context: VMware acquired SaltStack in 2020, and Broadcom subsequently acquired VMware in 2023. The Salt Project remains open source under the Apache-2.0 licence, but commercial investment has shifted, and the community size has shrunk relative to Ansible.

Pick SaltStack when: fleet exceeds 5,000 nodes; event-driven orchestration is a core requirement; team has existing Salt expertise and operational maturity to run the master/minion infrastructure.

Side-by-Side Decision Matrix

The Migration Question

Customers ask us regularly whether to migrate from Puppet to Ansible (the most common direction in 2026). The honest answer is "usually no, unless there's a real reason." A working Puppet estate represents thousands of engineering hours. Migration is a 6-12 month undertaking that produces no new business value — the same servers run, just managed by a different tool. We migrate when the existing tool is genuinely blocking change (skills shortage, vendor cost, architectural mismatch with new cloud-native workloads), not because Ansible is fashionable.

The pragmatic pattern: keep the existing tool for the estate it already runs; adopt Ansible for new green-field workloads; let the legacy estate retire naturally as workloads migrate to containers or new infrastructure.

The Container Era Reframe

For estates with significant Kubernetes adoption, the configuration management surface shrinks. The container image contains the application config; Helm or Kustomize manages the workload spec; ArgoCD or Flux reconciles cluster state. What configuration management is left for is the host below Kubernetes — kubelet config, containerd config, CNI plugins, kernel tuning, and the agents that aren't part of any pod (logs, metrics, EDR).

That residual surface is small but non-trivial. We typically use Ansible for it, because the host count is small enough that push-based scales fine and the agentless model means one less daemonset to worry about.

How Opsio Helps

Opsio runs all four tools across customer estates and helps customers pick the right one for their context. Our end-to-end devops configuration service covers tool selection, migration strategy when needed, role and module architecture, and the operating model that keeps the practice healthy past the initial rollout. For Ansible-specific engagements we deepen the practice via end-to-end ansible configuration, and we wrap the broader platform work in end-to-end devops consulting when customers want strategic input alongside execution.