Installing OpenVox 8 on Ubuntu 24.04: the open-source Puppet replacement

If you came here looking for how to install open-source Puppet on a current Ubuntu, the short answer is that you can't, and it is not your fault for not knowing. The instructions everyone wrote — add deb.puppetlabs.com, install puppet-agent — stopped producing new versions in early 2025.

This article covers what to do instead. If you are running Puppet today, the migration is at the bottom and it is less painful than you are probably expecting.

What actually happened

Perforce acquired Puppet in 2022. In November 2024 they announced that new binaries and packages would ship only to a private, controlled repository, with community access gated behind an end-user license agreement and free use capped at 25 nodes. Beyond that, you buy a commercial license.

The core codebase stayed Apache 2.0, but public releases and the public packaging pipeline both stopped. In practice, "open-source Puppet" ceased to be a thing you could install.

The community response was OpenVox, run by Vox Pupuli — the same collective that already maintained a large share of the Puppet module ecosystem and its testing tooling. They describe it as a soft fork, meaning the intent is to stay downstream-compatible with Puppet for as long as that remains possible, and there is a standards committee steering language evolution that Perforce has been invited to join.

The practical upshot for you: from release 8.11 onward, OpenVox is functionally equivalent to Puppet. Same command names, same configuration file paths, same modules from the Forge, same manifests. The visible differences are help text, man pages, and package names. It is not a new tool to learn.

Which thing should you actually install?

That last row matters more than it looks. The old public repositories still exist and still resolve, so an old install keeps working and quietly stops receiving security patches. If you have Puppet agents installed from deb.puppetlabs.com, they are frozen at whatever shipped before the cutoff.

Before you start

Three things that cause most first-run failures, all cheap to get right:

A real FQDN. Certificates are issued against hostnames, and a box called ubuntu will generate a certificate you regret.

sudo hostnamectl set-hostname puppet.example.com
echo "127.0.1.1 puppet.example.com puppet" | sudo tee -a /etc/hosts

Synchronised clocks. Certificate validation is time-sensitive, and a server whose clock has drifted will reject agents with an error message that says nothing about clocks. Ubuntu 24.04 ships systemd-timesyncd enabled; confirm it with timedatectl status and look for a synchronised clock.

Port 8140 open on the server, from your agents:

sudo ufw allow 8140/tcp

Enable the repository

OpenVox ships release packages per distribution and major version. For Ubuntu 24.04 and OpenVox 8:

wget https://apt.voxpupuli.org/openvox8-release-ubuntu24.04.deb
sudo dpkg -i openvox8-release-ubuntu24.04.deb
sudo apt update

Swap the filename for your release — ubuntu22.04, ubuntu26.04, debian12, debian13 are all published at apt.voxpupuli.org. Browsing that index is the fastest way to confirm what exists for a given platform rather than guessing at a URL.

Install the agent

sudo apt install openvox-agent

The binaries land in /opt/puppetlabs/bin, which is not on your PATH by default — the same annoyance Puppet always had, preserved deliberately for compatibility. Either use the full paths or add it:

echo 'export PATH="/opt/puppetlabs/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Confirm it works without involving a server at all:

puppet --version
sudo puppet apply -e 'notify { "OpenVox is alive": }'

If you only need masterless configuration management — manifests applied locally, driven by git and cron — you are finished. That is a legitimate and underrated way to run Puppet, and it skips every certificate problem below.

Install the server

On the machine that will act as the primary:

sudo apt install openvox-server

This pulls in a JRE. The service and its defaults file keep the Puppet names for compatibility, so check what you actually got before assuming:

systemctl list-unit-files | grep -iE 'puppet|vox'

The default JVM heap is conservative. For anything past a handful of nodes, raise it in the defaults file — -Xms2g -Xmx2g is a reasonable starting point for a small estate, and the usual advice is to set minimum and maximum to the same value so the JVM does not spend time resizing.

sudo systemctl enable --now puppetserver
sudo systemctl status puppetserver

Point agents at it and sign

On each agent, in /etc/puppetlabs/puppet/puppet.conf:

[main]
server      = puppet.example.com
certname    = web01.example.com
environment = production
runinterval = 30m

Trigger a run to generate and submit a certificate request:

sudo puppet agent --test

It will wait for the certificate. On the server, list and sign:

sudo puppetserver ca list
sudo puppetserver ca sign --certname web01.example.com

Then rerun puppet agent --test on the agent, and it should fetch a catalogue and apply it. Enable the service for scheduled runs:

sudo systemctl enable --now puppet

Migrating an existing Puppet installation

This is the part most people are dreading, and it is genuinely close to a package swap — with one hard rule: Puppet and OpenVox cannot coexist on the same system. The OpenVox packages will remove the Puppet ones as part of installing.

Back up first, unconditionally:

sudo tar czf /root/puppetlabs-$(date +%F).tar.gz /etc/puppetlabs

Then enable the OpenVox repository as above and install. Your existing configuration under /etc/puppetlabs/ is left in place and used as-is — including your CA and issued certificates, which is what makes this a swap rather than a rebuild. Do not purge configuration.

The one case that is more work is distro-packaged Puppet modules. If you installed modules as .deb packages rather than through a Puppetfile, you will need to move them to a Puppetfile first, or wait until your distribution ships OpenVox itself. Migrating from Puppet Enterprise is a different path again — use their uninstaller on each node before installing OpenVox.

Do the server last, after agents. And do one agent first, on something you do not care about.

Version choices, as of mid-2026

OpenVox 8 is what you want. It is the current stable line — agent releases through 8.28.x, server and database through 8.14.x — and it is the version the install documentation targets.

OpenVox 9 exists but is beta. A 9.0.0 beta shipped in July 2026, and release packages are published for Debian 12/13 and Ubuntu 22.04, 24.04 and 26.04. It is worth a test VM, not a production estate. Note that OpenVox 8 moves to maintenance mode once 9 lands properly, so plan the upgrade rather than being surprised by it.

Ubuntu 26.04 is supported. Server and database packages gained 26.04 support in spring 2026, so a new build on the current LTS is a reasonable choice — just take the matching openvox8-release-ubuntu26.04.deb.

One habit worth forming: check the OpenVox Server release notes before upgrading, not after. The project publishes known issues alongside releases, occasionally including a recommended downgrade when a regression slips through, and reading that page takes thirty seconds against an outage that does not.

Is it worth staying on Puppet at all?

Fair question, given the disruption. The case for OpenVox is that your manifests, modules, Hiera data and mental model all carry over unchanged, and the fork is run by the people who were already maintaining most of the module ecosystem. The switching cost is genuinely a package swap.

The case against is that if you were already considering Ansible or a pull-based Kubernetes-native approach, this is a natural moment to do it — you are touching every node anyway. What you should not do is stay on frozen Puppet packages from the old public repositories, which is the one option guaranteed to leave you unpatched.