Open-source Puppet binaries moved behind a EULA: what to do

Why the EULA change forces a decision on your Puppet estate

Your Puppet nodes now depend on packages that Perforce distributes under a EULA, so your node count now has a licensing consequence. You have three options: pay for Puppet Core, stay on older public packages, or move to OpenVox, the open-source Puppet implementation maintained by Vox Pupuli. Since early 2025 new Puppet packages have come from a private repository, free under a development EULA up to 25 nodes and licensed above that. The right choice depends on three things: how many nodes you run, what support you need from a vendor, and how much change your operations team can absorb in its next release cycle. Confirm with Perforce how the EULA counts nodes in your estate before you compare any option.

Staying on older public packages postpones the decision without removing it. Packages you already have keep running, but new releases and security fixes will not arrive through the same channel for free, so record which versions each group of nodes runs and watch for the point where those versions stop receiving updates. Paying for Puppet Core keeps the vendor relationship and the support path, but the cost recurs and grows with the estate. Ask for the quote in writing against your current node count, the support tier you need, the contract term and any charges for nodes added during the term. Those written terms are what let you compare the paid option fairly with the other two.

Moving to OpenVox is the option with the most change. The OpenVox install documentation states that OpenVox 8.11 is functionally equivalent to Puppet, with the same command names and configuration paths, which lowers code-level risk. The migration work sits in the packaging: Puppet and OpenVox cannot be installed on the same system, the Puppet Enterprise uninstaller must run on each node first, and backing up the whole /etc/puppetlabs tree is strongly advised. Plan a pilot on a small group of nodes, confirm which Puppet Enterprise console and orchestration functions you will replace, and keep a rollback plan until the pilot has run cleanly. Use the OpenVox install guide to check package names against your operating systems.

What the EULA change requires from your Puppet estate

The EULA change turns routine package updates into operator decisions. Each card below is a check to complete before you choose between paying for Puppet Core, staying on older public packages, or moving to OpenVox. Confirm each point with Perforce for your own license position.

Inventory the package source on each node

Start with a list of every node and the package source it uses. Hosts installed from older public Puppet packages, hosts installed from the private repository, and hosts that pull packages through a mirror you control each need a different answer. Record the agent, server and PuppetDB versions for each host. Without this list, you cannot tell which nodes the EULA reaches.

Count nodes against the threshold

The development EULA covers new private packages for up to 25 nodes, and licensing applies above that count. Count agents and infrastructure hosts separately, then ask Perforce how it counts each type. Re-count after every growth event, because a node added in one quarter can cross the line without anyone noticing.

Read the terms above the limit

Read the license terms that apply once your count passes the development limit. Check what the subscription covers, who may install the packages, and what changes at renewal. The EULA summary alone does not settle these points, so get the current written terms from Perforce and have legal review them against how your teams actually use the packages.

Assign patching ownership

Once public packages stop changing, security and bug fixes depend on the package source you choose. Perforce ended public Puppet packaging in late 2024, so hosts that stay on old public packages receive no new builds from that source. Decide who tracks advisories, tests updates and rebuilds the stack, and whether that work sits with your team, a support contract or a community project.

Plan backup and removal per host

Before any OpenVox install, run the puppet-enterprise-uninstaller script on each Puppet Enterprise node and back up the whole /etc/puppetlabs tree, which Vox Pupuli strongly advises. Puppet and OpenVox cannot share a system, so schedule each host as its own cutover with a tested rollback copy. The OpenVox install guide lists the packages and steps.

Puppet Core, frozen public packages or OpenVox compared

This table compares the three paths open to Puppet users after new packages moved behind a EULA: paying for Puppet Core, staying on older public packages, or moving to OpenVox. Read each row as a question to answer for your own fleet, starting with licensing and node count. The main takeaway is that only OpenVox combines a free, open license with a maintained release line, while the other two options trade cost or currency for continuity.

Question	Puppet Core (licensed)	Frozen public packages	OpenVox
How it meets the EULA constraint	Uses packages from Perforce's private repository under a commercial license above the free node limit	Keeps installed public builds, which receive no new packages from the vendor's public channel	Installs from Vox Pupuli repositories, outside the Perforce EULA
License terms	Commercial, quoted by Perforce; confirm the node threshold and terms in writing	Original open-source license of the earlier public packages; confirm terms with your legal team	Dual-licensed under CC BY-SA 4.0 and Apache 2.0
Compatibility with existing code	Native Puppet, so existing modules and manifests run unchanged	Native Puppet as installed, but fixes and new platform support depend on what you already have	The 8.11 release is functionally equivalent to Puppet, with the same command names and configuration paths
Cost components	Recurring license fees, plus servers, PostgreSQL for OpenVoxDB equivalents, and internal staff time	Low license cost, but unplanned staff time for security patches and OS upgrades	No license fee; you pay for servers, PostgreSQL, migration effort and staff time, plus any paid support you arrange
One-time versus recurring costs	Recurring license and renewal; migration and training are one-time	Mostly recurring hidden labor for patching and workarounds	One-time migration and testing; recurring infrastructure and maintenance
Who supports it	Perforce, under your contract	Your team, the community, or a third party you engage	Vox Pupuli community; a commercial partner only if you contract one
Main trade-off	Predictable vendor support, but cost grows with node count	Lowest immediate spend, highest risk of drift from security fixes	Free and governed openly, but you own operations and must confirm feature parity for any Enterprise console use
Ask before deciding	Get a written quote for your node count and support tier	Confirm which packages you can keep receiving updates for and their security exposure	Check the 8.11 install documentation against your OS and plan a pilot on non-production nodes first

Which path fits your estate

If your estate is at or under 25 nodes, the development EULA may cover your current use, so the decision is often about support and long-term fit rather than an immediate license purchase. Confirm the terms in writing before you rely on them, because the threshold applies to the EULA text and the way your nodes are counted. Effort is usually modest in node count, but it still depends on how much custom code and how many agents you manage.

Count every managed node: include compile masters, the primary server and any agents that check in intermittently, then compare that total with the EULA limit.
Choose the support model first: if you need a vendor contract, ask Perforce for terms. If your team can support community software, OpenVox is the main alternative.
Back up before any change: copy the whole /etc/puppetlabs tree to a location outside the node, then test restoring it.
Run the uninstaller on each Puppet Enterprise node: OpenVox's install guide asks you to run the puppet-enterprise-uninstaller script before installing packages.
Test your code on a sample node: OpenVox 8.11 is documented as functionally equivalent to Puppet with the same command names and configuration paths, but confirm your modules on a test node first.

Before you commit, confirm your exact node count and the EULA terms that apply to your use case.

If your estate cannot send packages outside its network, the main work is building an internal copy of the OpenVox repositories and proving that the copy matches what the vendor published. Installation normally pulls packages from the Vox Pupuli apt and yum repositories, so you will need a mirror, a process for approving new versions and records that auditors can review. The cost is mostly internal staff time and infrastructure, and the terms of any Perforce license that requires connectivity should be checked separately.

Mirror the repositories internally: copy the openvox8-release package and the agent, server, OpenVoxDB, termini and OpenBolt packages to a repository your hosts can reach.
Verify before import: confirm package signatures against the keys published in the install documentation, and record the hash of each file you import.
Pin and record versions: keep a dated record of each version you approve, and note that the release repository you mirror determines the major track you receive.
Plan offline uninstalls: run the Puppet Enterprise uninstaller on each node during a change window, and keep a tested restore path for /etc/puppetlabs.
Document evidence for assessors: keep change tickets, backup results and test records, and ask your independent assessor which evidence they expect.

Before you start, confirm with Vox Pupuli how their packages may be mirrored, and confirm with Perforce whether your license needs network access.

How to move to an open-source Puppet alternative step by step

This sequence takes a Puppet Enterprise or open-source Puppet estate to OpenVox with a recoverable backup, a clean removal of the old packages on each node, and agents that check in to the new server before you retire anything.

Inventory nodes, certificates and code
The platform team lists every Puppet server, compiler, agent and OpenVoxDB host, along with the operating system and version on each. Record which nodes run Puppet Enterprise and which run open-source Puppet packages, because the removal path differs. Confirm that your control repository, Hiera data and module versions are in version control so they can be restored independently of the server. The step is done when you have a written node list that a second engineer has reviewed.
Back up the whole /etc/puppetlabs tree
Before any package change, the operator copies the entire /etc/puppetlabs directory on every affected host to storage outside that host. OpenVox's install documentation strongly advises this backup first, because it holds configuration, SSL material and certificate authority data. Test that the archive can be read and that the restore procedure has been written down. The step is done when each host has a verified copy and a named owner for restoring it.
Run the PE uninstaller on each node
For Puppet Enterprise nodes, the operator runs the puppet-enterprise-uninstaller script on each node, as OpenVox's install documentation directs. Work through the servers and compilers in a planned order so that agents are not left without a usable server for longer than the change window allows. Puppet and OpenVox cannot be installed on the same system, so this removal must finish before OpenVox goes on that host. The step is done when the uninstaller reports completion and the host no longer runs Puppet services.
Enable the openvox8-release repository
On Debian or Ubuntu hosts, the operator enables the openvox8-release package from apt.voxpupuli.org. On Red Hat family hosts, the same package comes from yum.voxpupuli.org. This adds the Vox Pupuli package source to the host so the OpenVox packages can be installed. Confirm the repository is reachable from each network segment and that your mirror or proxy policy allows it. The step is done when the package manager lists OpenVox packages as available.
Install OpenVox server components and agents
The operator installs openvox-server, openvoxdb and openvoxdb-termini on the server hosts, and openvox-agent on every node, with openbolt on the workstations or hosts used for orchestration tasks. The OpenVox install documentation states that the packages replace legacy Puppet packages and keep existing configuration files. Review any configuration file prompts before accepting them, and keep the backup from the earlier step available. The step is done when the packages report successful installation and the services start.
Validate agents against the OpenVox server
Run the agent in test mode on a sample of nodes first, then on the full estate, and check that catalogs compile and apply without unexpected changes. Confirm that certificate signing works for nodes that were re-enrolled and that OpenVoxDB receives reports. Compare results with the baseline from the old environment, paying attention to modules that depend on Puppet-specific behavior. The step is done when agents on all in-scope nodes check in, catalogs apply, and the exceptions list is closed or accepted by the owner.
Confirm the license position and retire old packages
Record which Puppet Core or Enterprise subscriptions, if any, are still in force, and confirm with Perforce what entitlements remain before cancelling or reducing them. Keep the backup archives for the period your retention policy requires, and remove copies of the old packages from internal mirrors. Document the final node count and version of each component for audit evidence. The step is done when the change record, the retained backups and the licensing decision are approved by the owner.

Evidence auditors and change boards ask for during the switch

A switch away from Puppet packages touches every node, so the proof of what changed matters as much as the change itself. The cards below cover the records change boards and internal auditors usually request, and each one answers a different question: what was running, what was saved, what was removed, what was installed, whether nodes came back, and who approved it. DeployOpen can prepare and organize this evidence, but independent auditors and your own governance functions decide whether it is sufficient.

Node and package inventory

Record every node, its operating system, and the installed Puppet or agent package versions before the change, then record the same fields after. Keep the two snapshots side by side so reviewers can match each node to its before and after state. Include Puppet Enterprise components such as the console and orchestrator, since they are easy to miss. Export the inventory from your configuration management database or a scripted query so it can be reproduced later.

Pre-migration backup record

The OpenVox install guidance strongly advises backing up the whole /etc/puppetlabs tree before installing anything. Keep a record showing the backup time, the host, the checksum of the archive, and where it is stored, along with a tested restore procedure. A backup that has never been restored is weak evidence, so note who performed the restore test and what was confirmed.

Uninstaller and install logs

Each Puppet Enterprise node must run the puppet-enterprise-uninstaller script before OpenVox is installed. Retain the uninstaller output, the package manager transaction logs, and the output of the OpenVox package installs for every node. These logs show which legacy packages were removed and which OpenVox packages replaced them, which is the question a change board asks first when a node behaves differently after the switch.

Agent check-in results

After each node is migrated, capture proof that its agent completes a run and checks in to the server. Keep the run timestamps, the exit status, and any resource failures from the first few runs. Compare these results with the pre-change baseline so that any drift in compliance state is visible. A list of nodes that never checked in is as important as the list that did.

Change approvals tied to the license decision

Record the decision itself: why the organization moved from Puppet packages under the development EULA or licensed Puppet Core to OpenVox, who approved it, and what alternatives were considered. Link the approval to the change tickets, the inventory and the backup record so the chain runs from decision to outcome. Confirm with your procurement and legal teams how the license terms apply to your node count before the approval is signed.

Rollback and exception register

Keep a register of nodes that were delayed, rolled back, or excluded, with the reason, the owner, and the date of the final decision. Changes often fail on a small group of unusual nodes, so reviewers look for documented exceptions rather than silence. Each entry should point to the backup used for recovery and to the check-in results that closed the item.

What an open-source Puppet alternative does not replace automatically

An OpenVox move replaces the Puppet engine, not the whole Puppet Enterprise product. The packages cover the agent, the server, OpenVoxDB and OpenBolt, installed from the Vox Pupuli repositories as openvox-agent, openvox-server, openvoxdb, openvoxdb-termini and openbolt. The console, orchestrator, role-based access control (RBAC) and support that Enterprise provides on top of that engine must be sourced separately. Treat each of these as an open gap until your own team confirms how it is covered, because the answer depends on how many people use the console, how often you run orchestrated jobs and what your audit process requires.

The console is the first decision. Puppet Enterprise gives operators a web interface for node classification, reports and run status, and the OpenVox packages do not provide an equivalent. Options include reading reports directly from OpenVoxDB, adopting an open-source classifier and dashboard, or building small internal tools, and each carries its own maintenance cost. Orchestration works the same way: list the Enterprise jobs your runbooks depend on, such as on-demand runs or tasks across node groups, then decide whether OpenBolt, your CI pipeline or a scheduler will carry them. For RBAC, record who can change code, trigger runs, read reports and approve changes today, then map each permission to a control in the new setup, such as your Git platform's access model and server-side authorization. Confirm that mapping with your auditors before cutover.

Vendor support is the gap that tooling cannot close. Vox Pupuli is a community project, so do not assume a support contract exists. Ask the project and any provider you consider what they cover, and get the scope in writing, including which OpenVox versions, modules and integrations are included and what response times apply. Also inventory Enterprise-only components, such as proprietary modules and licensing reports, so none of them surprise you after cutover. The sibling comparison, Puppet Enterprise vs OpenVox, sets out the full feature breakdown, and your gap register should start from it.

Common questions about the Puppet EULA change

Can we migrate from Puppet Enterprise to OpenVox ourselves?

Yes, many teams do the move in-house, provided they have someone who knows their Puppet code and can work through the node-by-node steps. OpenVox's install documentation says Puppet and OpenVox cannot be installed on the same system, so each node is handled in turn: run the puppet-enterprise-uninstaller script, install the OpenVox packages, and confirm the agent checks in. The documentation advises backing up the whole /etc/puppetlabs tree first and says existing configuration files are kept. The harder work is usually the PE console, orchestration and RBAC, which OpenVox does not replace one-for-one, so plan how your team will cover those functions before you start.

What drives the cost of a Puppet to OpenVox migration?

The cost comes from labor and infrastructure, not from the OpenVox packages, which are published under CC BY-SA 4.0 and Apache 2.0. The main drivers are the number of nodes and servers, how heavily your Puppet code depends on Enterprise-only features, how many environments and certificate authorities you run, and how much of the PE console and orchestrator you need to replace. Recurring costs include the servers and PostgreSQL behind OpenVoxDB, and the internal or external support you arrange yourself. Ask for each of these as a separate line in any quote.

How does the 25-node threshold apply to our estate?

The development EULA covers new Puppet packages for up to 25 nodes, and above that a Puppet license is required. Count nodes as your current licensing terms define them, because the boundary between managed agents, servers and other endpoints matters. If your estate is near 25 nodes, confirm the count with Perforce before deciding, since growth or a short-term spike can change the answer. Once you exceed the threshold, the licensed Puppet Core or Enterprise option has to be priced against OpenVox's free packages plus your own operating costs.

What does the team have to provide for an outside engagement?

Most of the work depends on inputs only your team can supply. Expect to provide access to the Puppet servers and the node inventory, a current copy of your control repository and modules, a list of any PE console dependencies such as RBAC roles, scheduled tasks and orchestration jobs, and named owners who can approve changes in each environment. You will also need a maintenance window plan for node cutovers and a decision on where backups are stored. Ask the provider to list these inputs in the written scope so you can assign them before work starts.

How long does a Puppet to OpenVox migration take?

The duration depends on the node count, the number of Puppet environments, how much custom code you have, and how many change windows your organization allows. No duration is set by the OpenVox documentation, so treat any estimate you receive as an output of your own inventory rather than a general figure. Ask for a phased plan that separates the pilot, the server cutover, the agent rollout and the console replacement, with the dependencies between them. Engagements are typically fixed-scope, so the timeline should be agreed in writing before work starts.

What should we request in a written quote for this work?

A useful quote lists the scope by component: the migration of each server and agent, the OpenVoxDB and PostgreSQL setup, the replacement for the PE console and orchestration, backup and rollback steps, and documentation handover. It should name the deliverables, the client inputs, the assumptions about node count and code quality, and the acceptance criteria. Ask whether ongoing support, upgrades and testing are included or offered as a separate retainer. DeployOpen does not publish a price list, and a quote follows from the written scope, so the clearer your inventory, the more precise the quote.

Will OpenVox stay compatible with the Puppet code we already have?

OpenVox aims to stay compatible with downstream Puppet for as long as it can, and its install documentation says OpenVox 8.11 is functionally equivalent to Puppet with the same command names and configuration paths. That said, compatibility should be tested rather than assumed. Run your control repository and critical modules against a test OpenVox server, check any Enterprise-only functions or modules, and confirm the agent versions your nodes will run. Record the results so the team can explain any differences during cutover.

How DeployOpen plans and delivers the Puppet migration

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and that includes OpenVox replacing Puppet Enterprise or Puppet Core on your servers. We start from a written scope so the move from the Perforce packages to OpenVox is agreed on paper before any node changes.

How we scope

Inventory every Puppet server, agent, console and orchestrator, and record which nodes sit above the 25-node development EULA threshold.
Agree in writing which licensing path applies: Puppet Core, staying on existing packages, or migrating to OpenVox.
Define the migration boundary, including certificates, Hiera data, control repository code and any PE console replacement.

How we build

Build a staging copy of the Puppet estate and run the OpenVox agent and server against representative node groups.
Test catalog compilation, module behavior and reporting against your current results before any production node changes.
Install OpenVox packages from the Vox Pupuli repositories and keep configuration under version control in your environment.

How we hand over

Deliver runbooks for backing up the whole /etc/puppetlabs tree, running the PE uninstaller on each node, and rolling back.
Document the final architecture, including OpenVoxDB, its PostgreSQL dependency and the access controls around them.
Hand over a node-by-node migration record so your team can show which systems moved and when.

How we support

Offer ongoing support, upgrades and testing as a retainer after handover, scoped to the OpenVox versions you run.
Confirm the agreed upgrade path with your team before each OpenVox release is applied to production.
Ask any quote to state what recurs under the retainer and what is one-time migration work.