3. What is the main use case of Puppet / OpenVox in 2025? Same as always? Isn't CM a lot less relevant in the age of platforms like Flatcar and Bottlerocket?
4. Why fork puppet instead of contributing to ansible or salt?
Configuration Management of one form or another is a way to ensure consistency across a fleet of servers, and reduce administration overhead. VMs aren't going away any time soon, despite SaaS companies best efforts.
Companies with 100s to 1000s of hours of investment in software like Puppet aren't going to rearchitect without being forced to. By the application becoming unsuitable for current needs, or due to cost.
Broadcom bought out VMWare and jacked the price up by unworkable amounts. Puppet is now owned by a venture capital company and the non-zero possibility is they'll follow Broadcom's playbook. That's why Puppet is being forked.
Why not contribute to Ansible or Salt? What individual programmers do in their spare time is irrelevant to the majority of users of those products.
VMs can be run as immutable prebaked images, with no configuration management needed. They may not be going away, but the way the tech is used is changing.
Configuration changes. With immutable image every time any parameter changes you have to rebuild and re-deploy image which looks like a waste of resources - to change even 1 byte you need to re-build and re-push an image (which could be a multi Gb one). Then restart a whole cluster which depending on the application can be either costly or disruptive (in case of long lived network connection, on in case if you have a database). And sometimes you need to change configuration parameters many times per day.
What developers tend to do when forced to use immutable infra is to move configuration from on-disk files to RAM and query it using network API from a central system. The problem is that it makes systems less reliable. If a VM/server restarted it can practically always read a config form disk but if you service relies on an external system to get runtime configuration it would not work if this external system is down, overloaded, misconfigured, returns wrong config because of a bug e. t. c. And it does happen in practice even when system designers tell they configuration API is very reliable (in theory). After seeing such systems fail I like simple on-disk configs more and more.
Sure. And some of us may want or need to do live changes at runtime across the fleet without needing a full rebuild and redeploy. It can certainly be more green. It's fine if you find it useful to be dogmatic and consistent but don't expect that to be the right approach everywhere or for everyone.
CM is useful here. And usually in the bootstrapping of such architectures.
I don't know if I'd describe the approach as dogmatic so much as deterministic. Live patching is certainly faster than the alternative, but you have to make sure you e.g. restart services when the underlying libraries get updated, as one example. Otherwise a naive vulnerability scanner might see that the OS package for e.g. openssl is up to date, meanwhile the version loaded by nginx, which is now removed on disk, is vulnerable.
Er, and how to you make the images? Or a family of tweaked images for different use cases. The make sure security standards, access to centralized services, etc is working?
I've used both. Ansible is abysmally slow compared to puppet.
Loosing puppet would be bad -- I don't want to go back to ansible (I used it from the beginning, when Michel DeHaan was still onboard. I don't like the crude mixture of programming language and YAML it became)
> 4. Why fork puppet instead of contributing to ansible or salt?
Puppet and Ansible (not sure about Salt) works very differently. Puppet is pull based, as in each client pulls their configuration from a central server at regular intervals, where as Ansible pushes a configuration when asked. Puppet is also more of a "Ensure that my client is in this state" while Ansible can be see as "Run these steps on the client", that's not a 100% accurate and people have also made Ansible work in a pull configuration, but I feel that makes picking one over the other a little simpler.
In any case, Puppet is easier to scale to thousands of servers. Ansible is easier to develop for and easier to upgrade or run multiple versions simultaneously. It two different approaches to the same/similar problem, but they are fare from interchangeable.
I am glad you at least mentioned ansible-pull[1] since it's just common to use push based setups, but not the only way. I don't know exactly how puppet thinks of these things but ansible-pull is also still agentless (meaning one does not need to register the managed machine a priori). I also especially like "--only-if-changed" <https://docs.ansible.com/ansible/11/cli/ansible-pull.html#cm...> which can keep keeps the journalctl noise down if that option is appropriate to your setup
> Puppet is easier to scale to thousands of servers
I would have expected the opposite. Pushing changes as required seems easier when the head node is the only one with smarts deciding on what happens next. Unless Ansible has some hard cap on how many servers it can direct in parallel?
The head node has to do all the processing of what changes to make, for each server it runs against. Pull based systems have the destination server do that, making them scale horizontally natively.
Presuming there's no need for orchestration between nodes (which pull-based configs make very hard/impossible), pull-based systems parallelize perfectly where push-based systems cannot parallelize.
SSH is also very slow as far as these things go. At some point the head node just gets saturated on doing SSH encryption or the NIC.
Puppet servers can be scaled horizontally - create N puppet servers and then allow a client (an agent) to select a random server (either using a load balancer or just a DNS RR). But even a single server on modern hardware with appropriate tuning should be able to serve thousands nodes.
Puppet is actually a very competent infrastructure-as-code tool. I never liked the typical architecture where you run a few central puppetmaster nodes with hundreds or thousands of puppet agents all syncing to that...
There are other ways to use the tool, however. In contrast with a centralized infrastructure, it's also possible to just collect a few puppet manifests in git, then you simply clone the repo and run `puppet apply` on demand.
Puppet is still a powerful language for declarative representation of system configuration. Works to apply a specific configuration at a specific time or as a way to automate the construction of VM images.
One place puppet excels is when you want to reuse a bit of configuration in bare metal, virtual machine or container images. With puppet you can pretty easily generate all three from one source of truth with minimal special-cases for the config variants.
All that being said, I haven't reached for puppet as my first choice tool in quite some time. Maybe time to change that and give OpenVox a look. It'll be a win if OpenVox saves me from further suffering through the indignity of working with Ansible.
"There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors."
The names of things today is terrible. If I hadn't known what Puppet was, even vaguely, I would have thought this was some kind of speech recognition or TTS project as well. This may as well be called "FileDefrag" or "OpenSec".
Per https://voxpupuli.org/openvox/ , this is a community fork of Puppet (the tool like ansible/chef/salt), not Puppet (the browser automation tool). In case anyone else was confused too.
I just wanted to comment that there is no browser automation tool called Puppet when I found out there's a scraper thing that allows entering natural language description for the task (probably using LLM and Puppeteer under the hood). Given that this is quite obscure I guess they indeed mixed it up with Puppeteer.
Ansible works best when you only have Linux/BSD systems to manage, due to its heritage and doing everything through SSH.
If you have other systems to manage, like Windows or VMware ESX etc., it feels like a kludge with the delegation to localhost to get to the plugins.
Also, it can be tricky to use if your Linux systems have different Python interpreter versions because it's not at all straightforward to override the python interpreter used.
Looping constructs and sub-tasks etc. are also awkward to use, and the initial setup for a small automation project might be overwhelming for newcomers.
On the other hand you get a massive community with plugins for almost every conceivable system/OS, so that's definitely a huge plus
For sure not everything, I get a lot of mileage out of using SSM into ec2 hosts which doesn't even have Internet facing addresses
I am thankful that I've never had to manage Windows but I don't believe they're managed as localhost since if nothing else ansible doesn't offer control node execution on Windows
Word of advice: Whatever you use, try to be relatively consistent with commiting your changes. A traversable git history and clean enough state to keep track of what's fresh can be super helpful especially when troubleshooting or coming back after messing around with whatever.
And never commit inline secrets. Find out one of the ways to inject/separate/template secrets that's workable for you to stick with it.
For home use definitively recommend Ansible. I've used/uses both and for a handful of servers/VM and for a single administrator I'd always pick Ansible. Realistically what you want is just a tool that store a configuration in some VCS and an a why to apply that configuration quickly.
Ansible will allow you to do that with just "pip install ansible". Puppet requires you to setup so infrastructure, which you need to way of bootstrapping.
Personally I also find Ansible easier to work with, in the sense that you can more easily do stuff in small increments. Upgrading Ansible is also a lot simpler. Puppet really cool and powerful, but for home stuff or a small business I'm not sure the overhead of managing Puppet itself is worth it.
Puppet is a project to implement. Once it's implemented, it's great. It requires dedicated infrastructure to work properly.
Ansible is much easier to step into slowly if you don't have time to implement a full deployment project before you can use it. You can start without dedicated infrastructure and add later if you want more centralized management.
https://github.com/ansible/awx#readme is also helpful if one needs "runbook" behavior to allow arbitrary audiences to run playbooks without the headache of installing something and dealing with local cred management. Interestingly, it also offers a "callback" system to allow machines to request a playbook upon themselves in cases where ansible-pull isn't appropriate/helpful
Ansible is a little bit easier to get started for a few reason (yaml instead of a DSL, ssh only...) ; it's also mostly tasks running through SSH which may feel a bit more "natural" when you are configuring machines initially.
In terms of idempotency I find it is easier in ansible to mess up something but if you are careful they are on par. I've used mostly ansible over the past few years in various jobs but the first I got in touch with ~10 years ago was puppet and it felt very solid especially for heterogeneous environments (we had different archs and OSes to manage). Also puppet scales very well because it has agents as well as many tools to manage large infrastructures which I tried and were already quite convenient 10 years ago.
TL;DR probably use ansible unless you have a very specific use case.
I am a pretty big proponent of ansible but I have given grave consideration to making a fork that uses Skylark instead of yaml because the "what can I type here?" story is terrible as is. Most of the jinja expressions are already basically python so it seems like a natural fit
That will keep SSH installed, a service running, and the puppet config file managed forever. If you accidentally replace the config file it will be fixed and the service restarted. If you remove the package it will be reinstalled, config file updated, and service started.
Not a fan of ansible, it's more of a "run this playbook", which translates to reinstall and "run this playbook", which in environments that don't reinstall very often can be painful. Since ansible playbooks don't know the current machines state they never know exactly what commands to run.
Generally if you spin up containers or similar short term servers I think ansible is fine. If it's a larger and more complicated environment with longer lived servers I'd use puppet.
Oh, one other think I like about puppet is if you say apply X to all nodes, you can literally not run puppet (it will fail to compile the manifests) if you try to override it. Which security auditors LOVE.
I've repeatedly tried to make Puppet work for "small" installations, be it a single dev laptop, our fleet of default base VMs (before containers were a thing), or home use. You couldn't really do anything without community packages, and their update rate was kinda meh. A lot of churn.
Puppet always seemed to me like a scalable enterprise solution, but you either need a team to keep it in check, or just never update.
I'm not specifically recommending Ansible, but it's what I've been using for a couple years, and I would always recommend that for home use over Puppet.
Disclaimer: I last used Puppet in 2017, but for like 7 years extensively before that and everything I mentioned happened several times.
Second disclaimer: By now I think parametrizing everything is a huge mistake - the real worth is editing the config in one place and having it in SCM. if you only parametrize 2 lines out of a 100 line config file and basically copy it over with 2x `sed` - that's fine.
Ansible looks like a default choose for this use case but for my personal server (running in a VM) I'm planning to migrate away from Ansible and try puppet. I tried to use Ansible for a few years and abandoned it because it was too tedious to maintain configuration in Ansible. Puppet of course also requires time but if feels so much easier, mainly because it has ruby-like DSL (not YAML).
I am a user of puppet and have used many of the community puppet modules developed under the Vox Pupuli group ( They have 175 modules on puppet forge: https://forge.puppet.com/modules/puppet ). Looks like I've missed the news and they're (soft) forking puppet as OpenVox; does the following appear right?
Summary of what I can find: It seems Perforce have announced they will stop providing open source puppet's public binaries and the public package repositories. Private access to their binaries will require either developer license (with one of the limits being 25 nodes) or a commercial license. Secondly, they are reducing public source code contributions to Puppet. A response to this by Overlook InfraTech / Vox Pupuli has resulted in a fork called OpenVox.
> In early 2025, Puppet will begin to ship any new binaries and packages developed by our team to a private, hardened, and controlled location.
> Community contributors will have free access to this private repo under the terms of an End-User License Agreement (EULA) for development use. There will be no license changes for the open source version of Puppet.
This is backed up by nightlies suspended from 2024-11-06 https://nightlies.puppet.com/apt/dists/index.html . From the blog post, it would appear that access to binaries is only going to be free for 25 nodes.
> The new development license is an EULA that allows developers free access to our hardened Puppet releases (up to 25 nodes). Capacities higher than 25 nodes will require a Puppet Labs Support Commercial License.
> Community developers will continue to have access to binaries and packages for development purposes under a new developer license (EULA).
Releases prior to the annoucement appear available, but there is no statement suggesting that will remain in the blog post. I have a few dozen physicals and a few dozen VMs running puppet but don't have a commercial license, so this will impact me.
Regarding the second issue, reducing public source code contributions to Puppet, there is this from the same blog post:
> We will release hardened Puppet releases to a new location and will slow down the frequency of commits of source code to public repositories.
Regarding the community response, it seemed to start with providing community packages and has become the "soft fork"? From https://voxpupuli.org/openvox/
> OpenVox started life as a Puppet™ mirror by Overlook InfraTech to continue providing community packages when Perforce discontinued public packaging efforts in late Fall of 2024. It soon became clear that they were also moving all further Puppet™ development to internal forks and ceasing development on open source Puppet™. A community fork using Overlook InfraTech's packaging pipeline was the inevitable response.
> We consider OpenVox a soft-fork because we intend to maintain downstream compatibility for as long as we are able. As such, we've created a Puppet™ Standards Steering Committee to set the direction of features and language evolutions and have invited Perforce to participate.
2. OpenVox sounds like a text to speech engine.
3. What is the main use case of Puppet / OpenVox in 2025? Same as always? Isn't CM a lot less relevant in the age of platforms like Flatcar and Bottlerocket?
4. Why fork puppet instead of contributing to ansible or salt?