Puppet fork OpenVox makes first release

Yes, all of Wikimedia's servers rely on it: https://gerrit.wikimedia.org/g/operations/puppet/

I have a very small puppet deployment (~10 puppet clients), since circa 2011-2012, for semi-automatic long-lived/persistent full-system Ubuntu-based lxc[1] containers. For deployment, I setup the base container, change the uid 1000 password, install and connect the puppet agent to my server, let it do its thing (mostly installing packages, registering the containers with my nagios/icinga2 instance[2], and creating my needed local accounts), and wrap up the setup by manually setting up LDAP authentication (nowadays via sss). Although it hasn't had anywhere near perfect backwards/forwards/"API" compatibility, it mostly never got in my way and the language(s) are a breeze to use. Not a fan of the Java-based puppetserver/puppetdb for resource usage, but it's still within reason.

Didn't know puppet had discontinued/closed-sourced their communtiy edition, gonna have to migrate these coming weeks.

[1]: Have been trying incus on a different deployment and have loved it so far, next refresh cycle (2026) I'll most likely migrate to that.
[2]: nagios 3 integration was amazing; icinga2 has lots of moving parts and has forced me to use puppetdb, athough I admit my monitoring solution for a loooong time has been a well-stocked byobu session...

My experience is that the various tools in this space (Ansible, Puppet, Chef, etc) are all just as good/bad as each other, in different ways that generally result from the different models that they use. Ansible definitely has a lower barrier to entry than Puppet, and has advantages when it comes to managing clustered systems with interconnected state, but once you get to more complex deployments it doesn't matter what you use - it's a hideously complex problem space, there's no magic bullet that will make it easy and simple.

The biggest thing is really the module library that's available - yes, you can write your own Ansible/Puppet/etc code to manage your particular deployment of whatever, but almost all of the time it's a hell of a lot faster to use code written by someone else. This means the breadth and quality of the module library, and how well it's maintained and kept up to date, is one of the key differentiating factors for the different tools. There are also more intangible things like coolness and "momentum" that influence other factors - Ansible is better known and has more momentum these days than Puppet, so people are more likely to use it if they're starting from scratch, regardless of whether it's an objectively better choice; that feeds back into the maintenance and development time that people put into the module library.

Having made a choice at some point, though, you pretty quickly end up committed to that choice - it's extraordinarily difficult to change the configuration management system you're using without basically rebuilding everything from scratch. Where I work we've been using Puppet to manage our in-house OpenStack deployment for ten years - that's a lot of history and domain-specific knowledge that would need to be replicated if we wanted to move to Ansible, even though the OpenStack project's Ansible code is better maintained than their Puppet code.

Custom images are kind of orthogonal to this, though only kind of - the ad-hoc image build scripts that are used to build the vast majority of custom images (big piles of shell code in most cases) are really just another different attempt at tackling the same problems Puppet and Ansible attempt to solve. The only real advantage is that they're generally more discrete, only tackling a single application rather than a whole system; at the same time, you then require lots of other tooling around those images to pull everything together into a full software stack, at which point you get all the complexity of the various container orchestration systems that are out there. And where do you run your Kubernetes deployment? If it's bare metal, you're probably using Ansible to manage everything underneath Kubernetes . . .

We still use Puppet for most of our systems (about 100+ Linux servers, mostly Debian, some RHEL/Centos).

Having used Helm and K8S for a bit in some projects I sort of like K8S even though it has some flaws but I would rather gauge out my eyes than debug Helm templates on the scale to replace all our Puppet deployments. K8S also seems quite unsuitable for relatively small deployments where we currently use something like the smallest (or slightly larger) Cloud servers Hetzner offers for production and development systems each.

Personally I would change quite a few things about Puppet, almost none of which are any better in K8S, mainly around stronger static checks and better abilities to use a single source of truth to setup data used on multiple systems (e.g. a system, the server setting up DNS for it, the server setting up a backup storage location for it, the monitoring for it,...) and to coordinate the timing of those changes on various systems better.

Speaking of timing, K8S is also even slower than Puppet to deploy, especially if you take the image build into account but even ignoring that restarting containers tends to take in the order of 10 times as long as rebooting one of the cloud servers and probably 2-3 times as long as even the longer Puppet runs on those servers.

There are environment where direct login to root (or sudo-to-root capable) accounts is not possible. Admin logins are possible, but must be done through session-recording proxies with MFA. This tend to work poorly with Ansible's model.

On the other hand, such envs are fine with agent system, where agents connect to central mothership to get instructions what to do. Like Puppet.
Periodic, automatic config drift remediation is a nice bonus for Puppet, too.

Wasn't sure if you were implying Ansible makes sense in the cloud? Does it?

The last three companies I worked at used Terraform. Before that, the offerings in the cloud were a bit lower level then nowadays, and it was salt all the way.

I don't particularly like (or dislike) Terraform, so wondering about the alternatives.

Yes. All of OpenStack public cloud infrastructure is maintained using Puppet.