Ansible vs Chef vs Puppet: What's Still Free

Ansible vs Chef vs Puppet: the short answer

Ansible vs Chef vs Puppet comes down to one design choice and one licence question. Ansible connects to your servers over SSH and pushes changes when you run it, so nothing extra runs on the server. Chef and Puppet put an agent on every server, and that agent pulls its configuration from a central server on a timer.

The licence question is newer. Ansible's engine, ansible-core, is still GPL-3.0 (GNU General Public License, version 3). The official builds of Chef and Puppet now come with licence terms attached, so the free path for each one runs through a community build: Cinc for Chef, and OpenVox for Puppet.

For one VPS, or a few dozen reachable over SSH, Ansible is the low-overhead choice. An agent that pulls on a timer earns its extra cost when you need drift corrected continuously across a large fleet. Every version, price and licence detail below was read on the project's or vendor's own page on 9 November 2026.

What actually differs between Ansible and Chef?

Push over SSH versus an agent that pulls

Ansible runs from a control node, which is any UNIX-like machine with Python installed. Ansible's documentation describes it as "using SSH with existing OS credentials to access remote machines." The managed server needs a user account that can log in over SSH with an interactive POSIX shell, plus Python for the code Ansible sends. There is no daemon on the server and no central server to run. If you can SSH in, you can manage the box. The introduction to what Ansible is and how it works covers this model in more detail.

Chef works the other way round. Chef Infra Client is an agent that runs on each managed node. The node contacts the Chef Infra Server, downloads new or changed cookbook files, and applies them. When chef-client runs as a daemon, its --interval option sets how often it runs, and the default is 1800 seconds, which is 30 minutes. --splay adds a random number of seconds to that interval, so a thousand nodes do not all hit the server in the same second. --once makes a single run and ignores both.

Puppet uses the same pull model. In the OpenVox source code, the agent's runinterval defaults to 30 minutes. A runinterval of 0 means "run continuously", not "never run", which surprises people who set it to 0 to switch the timer off.

YAML playbooks versus Ruby recipes

An Ansible playbook is YAML. You list tasks, and each task declares the state you want, such as "nginx is installed". Ansible's docs say the syntax "reads like documentation", and for short playbooks that is true.

Chef organises its code in cookbooks. A cookbook holds recipes, a recipe uses resources, and a run-list sets which recipes run on a node and in what order. Recipes are written in a Ruby-based DSL (domain-specific language). That gives you a full programming language when the logic gets complex. It also means your team writes and reviews Ruby.

Puppet has its own declarative language. You describe resources and the relationships between them, and Puppet works out the order. The three snippets later in this post show the difference better than a description can.

How each one handles drift

Drift is the gap between what your configuration says and what is really on the server. Someone edits /etc/nginx/nginx.conf by hand, or stops a service while debugging, and forgets.

Chef and Puppet correct drift on their own. The agent runs every 30 minutes by default, sees that the server no longer matches, and puts it back. You do not have to remember anything.

Ansible corrects drift only when something runs it. By default that is you, typing ansible-playbook. You have two ways to close the gap. You can run the playbook on a schedule from the control node, with cron or a systemd timer. Or you can use ansible-pull, which Ansible's docs describe as inverting "the default push architecture of ansible into a pull architecture". Each node pulls the playbook from a source repository on a cron schedule and applies it locally, and the docs call this useful "both for extreme scale-out and periodic remediation." Before you trust a scheduled run, run the playbook in check mode to see what it would change without changing it.

Who owns each tool, and what is still free?

Ansible: Red Hat and IBM

Ansible belongs to Red Hat, and Red Hat's own About page says it has been "Joined with IBM since 2019." The engine, ansible-core, is GPL-3.0. The latest release on GitHub is v2.22.0, published on 2 November 2026, with maintenance releases for the 2.21, 2.20, 2.19 and 2.18 lines on the same day. The ansible package that many people install is ansible-core plus a community-curated set of collections. If you are not sure which one you need on Ubuntu, read which Ansible package to install on Ubuntu Server first.

The free web interface is AWX. It is Apache-2.0 licensed and gives you a web UI, a REST API and a task engine built on top of Ansible. Its README carries a warning worth reading: "Releases of this project are now paused during a large scale refactoring." The last AWX release came out on 2 July 2024. Plan for a tool that is not getting new releases.

The paid product is Red Hat Ansible Automation Platform. Red Hat's pricing page lists two subscriptions: Standard, with 9 AM to 5 PM support, and Premium, with 24x7 support. It publishes no prices. It says only that "Pricing varies based on your sizing and subscription choices," and offers a trial. If a comparison article quotes a price for Ansible Tower, check it against that page, which today names no Tower product and shows no figures. The Tower name has not fully disappeared from Red Hat's site: it survives on the Ansible product page as link text for a Splunk integration.

Chef: Progress, and the licence-key rules

Chef's pricing page says "Chef is part of the Progress product portfolio." The newest Chef Infra Client in Chef's release notes is 19.4.46, dated 19 October 2026. Client 19 is where licensing changed. The release notes say Client 19 "uses standard licensing for commercial, community, and trial customers."

Here is what Chef's docs said on 9 November 2026, page by page:

• Running Client 19. The Client 19 licence page says Chef Infra Client does not need a licence key to run if you download an official distribution. You still accept the EULA (end-user licence agreement) on the first run, with --chef-license accept or the CHEF_LICENSE environment variable.
• The Ruby gem. The same page, and Chef's licence-key page, say a copy installed from the public Ruby gem on RubyGems.org does need a key to run.
• Downloads. Chef's general licensing page says the licence "is only enforced at the point of downloading software." It says a key is required to download binaries from the Progress Chef Download Portal or Habitat channels, and for workflows that download from Chef APIs at runtime, such as knife bootstrap and kitchen converge. If you supply your own binary source, those two need no key.
• Bootstrapping. The Workstation 26 licence page, last modified 28 July 2026, disagrees. It says knife needs a licence only to bootstrap Chef Infra Client 18 and earlier, because Client 19 "is distributed through pre-signed URLs." The Workstation 26.1 install page then lists "a valid Progress Chef license key" as a prerequisite anyway.

The pages contradict each other on bootstrapping. Read both docs.chef.io/licensing and the Workstation 26 licence page on the day you build automation around knife bootstrap.

The licensing page lists three licence tiers. Free has no time limit, and it covers non-production and personal non-commercial use. Trial runs for 30 days for non-production evaluation. Commercial covers production and non-production use. Chef's pricing page lists SaaS plans at $59 per node per year for Business and $189 per node per year for Enterprise, with Enterprise Plus by quote. The Self-Managed tab lists no prices.

The free path is Cinc. Cinc describes itself as "a community-built, free-as-in-freedom distribution of Chef's open source projects," and both its source and its builds are Apache-2.0. Cinc still ships a 19 line: the download mirror lists Cinc 19.4.46, dated 22 October 2026, next to the earlier 19.x builds and the 18.x line. Cinc's download page does not mention licence keys or activation.

Puppet: Perforce, and the OpenVox fork

Puppet belongs to Perforce, and the Puppet licence agreements are issued by Perforce Software. Perforce's commercial build is called Puppet Core, and Puppet's help site lists the current version as 9.1.3. The Puppet Core install page says the packages, which include puppetserver, puppet-agent and puppetdb, are "available only if you purchased Puppet Core."

Puppet's pricing page lists a free Developer tier for fewer than 25 nodes and a Commercial tier for 25 or more nodes, with custom pricing. Read the licence behind the free tier before you plan production on it. The Puppet Core Developer Program Licence Agreement, dated 30 January 2026, is a non-commercial licence granted to develop or test modules. It charges no fee "so long as the aggregate number of Managed Nodes does not exceed twenty-five (25)." Its node count includes nodes running open source Puppet. Note the small mismatch: the pricing page says fewer than 25, while the agreement allows exactly 25. Either way, this is a developer programme, not a free production tier.

According to Vox Pupuli, the community group behind OpenVox, Perforce stopped public packaging in late fall 2024, and a community fork followed. That fork is OpenVox. Vox Pupuli announced OpenVox 8.11 on 21 January 2025 and described it as "functionally equivalent to Puppet" and "a drop-in replacement." On 9 November 2026 the release marked Latest on GitHub is OpenVox 9.3.0, published on 3 November 2026 as a security fix for advisory GHSA-ffr6-rwpm-p5wq, which GitHub rates Critical with a CVSS 4.0 (Common Vulnerability Scoring System) score of 9.4. The 8.x line got 8.32.0 on the same day. If you run OpenVox already, update. The code is Apache-2.0, and packages come from apt.voxpupuli.org, which has release packages for Debian 12 and 13 and for Ubuntu 22.04, 24.04 and 26.04.

Install nginx and keep it running in all three tools

The task is the same in each tool: install nginx, start it now, and start it at every boot. The snippets assume an Ubuntu 24.04 VPS. Run each one twice. The first run makes changes. The second run should change nothing, because the server already matches. That property is called idempotence, and it is the point of all three tools.

Ansible

Ansible runs from your laptop or another control node. Create an inventory file, inventory.ini, with your server's address and SSH user:

[web]
203.0.113.10 ansible_user=youruser

Then the playbook, nginx.yml:

- name: Install nginx and keep it running
  hosts: web
  become: true
  tasks:
    - name: Install nginx
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Start nginx now and at boot
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

ansible-playbook -i inventory.ini nginx.yml --ask-become-pass

ansible.builtin.package hands the work to the server's own package manager, apt on Ubuntu. Ansible's docs say started is idempotent and "will not run commands unless necessary." On the second run, the PLAY RECAP line should show changed=0. If the first run fails with UNREACHABLE!, Ansible could not open an SSH session, so test ssh youruser@203.0.113.10 by hand before you change the playbook. The guide to the Ansible inventory file explains host groups and connection variables.

Chef, using Cinc

Chef's normal model is a node and a server, but Chef Infra Client can also run a single recipe file in local mode, which is enough for this test. Install Cinc Client on the VPS itself. Cinc's docs give this command, where -v 19 installs the latest 19.x build. It pipes a script into sudo bash, so open the URL and read the script first if that matters to you:

curl -L https://omnitruck.cinc.sh/install.sh | sudo bash -s -- -v 19

Write the recipe to nginx.rb:

package 'nginx'

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

sudo cinc-client --local-mode nginx.rb

--local-mode runs Chef Infra Client against local files instead of a Chef Infra Server, and the recipe path is the file to run. The package resource's default action is :install. On the service resource, :enable turns the service on at boot and :start starts it and keeps it running. Cinc also installs a chef-client wrapper that redirects to cinc-client, so Chef tutorials still apply.

Puppet, using OpenVox

Enable the Vox Pupuli repository with its release package, then install the agent:

wget https://apt.voxpupuli.org/openvox9-release-ubuntu24.04.deb
sudo apt install ./openvox9-release-ubuntu24.04.deb
sudo apt update
sudo apt install openvox-agent

Write the manifest to nginx.pp:

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

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

sudo puppet apply nginx.pp

In the OpenVox source, installed is an alias for present on the package type, running is a valid ensure value for a service, and enable => true means the service should be "enabled to start at boot." The require line makes Puppet install the package before it manages the service. If sudo answers puppet: command not found, the agent's binary directory is not on root's PATH. Find the full path with dpkg -L openvox-agent | grep 'bin/puppet$' and run that path instead.

Check the result, whichever tool you used

systemctl is-enabled nginx
systemctl is-active nginx
curl -I http://localhost

You should see enabled, then active, then a response that starts with HTTP/1.1 200 OK. If is-active prints failed, the tool did its job and nginx itself refused to start. Read journalctl -u nginx -n 50 for the reason.

When does an agent-based pull model earn its overhead?

An agent costs you something on every node: a package to update and a process to keep running. On the server side, you also run and back up a Chef Infra Server or a Puppet server. That cost pays off in these cases:

• Continuous drift correction across a large fleet. When hundreds of nodes must snap back to policy every 30 minutes without anyone running a command, the agent timer is the feature.
• Compliance evidence. An auditor wants proof that every node was checked recently. A scheduled agent run on each node gives you that by design, instead of depending on someone remembering a playbook.
• Nodes you cannot reach over SSH. An agent connects out to its server, so a node behind NAT (network address translation) or a strict firewall still gets its configuration.
• A team that already writes Ruby or Puppet code. Years of tested cookbooks or modules are worth more than a cleaner design on paper.

For a handful of VPSes you reach over SSH, none of that applies. You would run an extra server to manage a few machines. Ansible with a scheduled run, or ansible-pull on each node, covers periodic drift correction at that size. Managing several Linux servers from one place walks through the options at that scale.

One more boundary. All three tools configure servers that already exist. Creating the servers, networks and volumes in the first place is a provisioning job, and how Ansible and Terraform split that work is the next question to answer if that is what you need.

Which one should you pick for a few VPSes?

Pick Ansible. It needs nothing on the server beyond SSH and Python, the engine is GPL-3.0, and you can stop using it tomorrow without leaving an agent behind. If you are new to it, how hard Ansible is to learn sets honest expectations. The practical next step is writing your first Ansible playbook against a VPS.

Pick Chef or Puppet when you inherit a codebase written for them, or when the fleet is large enough that a pull agent pays for itself. In that case, decide early between the vendor build and the community build. Cinc and OpenVox are both Apache-2.0. Progress and Perforce sell the official builds, support and licences, and their licence pages change, so read them again before each upgrade.

FAQ

Is Chef still free to use?

Chef's licensing page lists a Free licence with no time limit, and it covers non-production and personal non-commercial use. Production use is what the Commercial licence is for. Chef Infra Client 19 from an official distribution needs no key to run, while the copy from RubyGems.org does. Cinc, the community build of Chef, is Apache-2.0, ships a 19.x line, and its download page does not ask for a licence key.

Is Puppet still open source?

Perforce now ships its Puppet Core packages only to customers who purchased Puppet Core. Puppet's free Developer tier is a non-commercial licence for developing or testing modules on up to 25 nodes. The open source continuation is OpenVox from Vox Pupuli. Its code is Apache-2.0 licensed, and 9.3.0 was the latest release on 9 November 2026.

Does Ansible need an agent on the server?

No. Ansible connects over SSH with the server's existing login credentials and sends the code it needs for each task. The server needs a user account with an interactive POSIX shell and Python installed. Nothing runs on the server between playbook runs.

What happened to Ansible Tower?

Red Hat's current pricing page lists Red Hat Ansible Automation Platform in Standard and Premium subscriptions, publishes no prices, and names no Tower product. The free, open source web interface is AWX, which is Apache-2.0 licensed. Its releases are paused during a large refactoring, and the last one came out on 2 July 2024.