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.
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.
"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".
> 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.
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.
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.
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'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 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
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.
1. I didn't realize puppet was open core.
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?
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.
Salt is owned by VMware; I would think twice before using it given their situation.
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.
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.
Yeah, I have used that approach since around 2015. In order to create these prebaked images, you will usually want to use a CM tool anyway, though.
Puppet is owned by Perforce which is owned by private equity, not venture capital, and worse than venture capital.
> OpenVox sounds like a text to speech engine.
"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".
> 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.
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.
> not Puppet (the browser automation tool)
Puppet or Puppeteer ?
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.
I'm looking to introduce CM to my homelab, anyone got some good arguments why I should look at puppet/openvox instead of ansible?
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.
Both are solid and will do the job.
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.
The DSL (and associated IDE support) is about the only thing I like about puppet
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 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
You may want to consider NixOS as yet another option.
What's the story behind the name OpenVox? Hard to draw relation to Puppet from it.
Vox pupuli is a long running puppet related thing
Seems like the pupuli part is more relevant than the vox part.
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.
Regarding the first issue, Perforce's halt to providing open source puppet's public binaries / package repos: Posted on the "Puppet By Perforce" blog 2024-11-07 https://www.puppet.com/blog/open-source-puppet-updates-2025
> 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.