Thirty servers ought to be an equipment problem. At Jewelers Mutual, they had become a calendar problem. Creating an environment meant four to six weeks of manual building, configuring and checking. The insurer needed applications delivered faster, without hiring an ever larger supporting cast. Its machines were waiting for people to finish agreeing about the machines.
The company brought in Zivra, a Puppet channel partner. Together they created the configurations needed to support its applications. In Puppet’s published case study, Jewelers Mutual reports getting that environment-building process down to under a day. The revealing part is what they made repeatable: the decisions that had previously accompanied every build.
- Define the intended state. Puppet expresses infrastructure configuration as code.
- Keep checking. Managed systems can be brought back into line when configurations drift.
- Make the work shareable. Reviews, modules and reporting reduce dependence on individual memory.
- Read the current bargain. Vendor-supported Puppet Core is proprietary; its open-source ancestry is a separate matter.
Thirty servers, and a queue of people
Jewelers Mutual’s difficulty was familiar to anyone who has watched a simple request acquire a procession of specialists. Infrastructure had to be created, tested and eventually decommissioned. Manually assembled environments required people to check them. Faster application delivery therefore demanded more than faster hardware.
Puppet’s intervention was to give those environments a reusable definition. That is a useful distinction for a buyer: automation requires an agreed configuration before it can save anyone from configuring. Zivra’s implementation work belongs in the story alongside the software. The customer result reflects both.
It would be tempting to treat the shorter build as the whole achievement. But an environment can be identical at birth and accumulate peculiarities afterward. Someone changes a setting to fix an incident. Someone installs a different package. The next person inherits a system whose biography is longer than its documentation.
The machine that remembers
Luke Kanies had been a system administrator and consultant before founding Puppet in 2005. He wanted better tools for managing complicated IT systems. That origin matters. Puppet’s subject is the ordinary, repetitive work of keeping infrastructure intelligible - work that becomes expensive when each machine gets its own private explanation.
Its central idea is desired state. Describe the packages, files, services and other managed resources that should exist, then let the software work toward that configuration. The declaration supplies a durable reference point. On subsequent runs, Puppet can identify differences and correct managed resources rather than relying on somebody to remember yesterday’s intervention.
Repeatability has a rather ungainly technical name: idempotence. Applied to a well-written configuration, repeating the operation should converge on the same intended result. The attraction is easy to understand. A company should be able to insist on the same operating policy twice without accidentally obtaining two different systems.
Ten thousand servers need a shared memory
KPN, the Dutch telecommunications and IT provider, offers a second view of the problem. Its customers expected consistent service across a diverse estate. Manual processes and internal silos were becoming obstacles to delivery and to demonstrating compliance.
KPN’s published case study describes managing 10,000 servers, with 7,500 Puppet nodes, 33 Puppet servers and 251 modules. Those numbers describe different parts of the installation; they are not interchangeable. GitHub held the code, Splunk supplied visibility, and Puppet Enterprise automated configurations. KPN called its delivery pipeline the App Factory.
“We believed this would help for us and our customers to innovate faster.”
Andreas Knol / Technical Product Manager, KPN
The lesson is in the arrangement. Code needs somewhere to live. Changes need to be visible. Enforcement needs a definition to enforce. KPN reports application delivery pipelines available in as little as ten minutes, but the broader achievement was coordinating those responsibilities across many systems.
The catalogue has grown teeth
Perforce Puppet now sells several layers of this proposition. Puppet Core provides vendor-supported builds and configuration automation. Puppet Enterprise adds the console, role-based access and workflows that help groups manage a large estate. Enterprise Advanced extends the offering with features including advanced patching, vulnerability remediation, compliance enforcement and infrastructure insights.
The security products bring assessment and enforcement closer together. Supported CIS Benchmarks and DISA STIG baselines give teams configurations to assess against and enforce. Reporting supplies evidence of managed activity. For an operations team, that can mean less work reconstructing what happened when an auditor arrives.
There is also a useful concession to the world as it exists. Puppet Edge extends automation to network and edge devices through agentless tasks. Its Playbook Runner can execute Ansible playbooks. Existing automation can therefore become part of a Puppet workflow without a ceremonial bonfire of the old scripts.
Infra Assistant, introduced for Enterprise Advanced in June 2025, makes Puppet data accessible through natural-language questions. Code Assist helps generate Puppet code, tasks and plans using environment context. These are opt-in capabilities with access controls. The query assistant exposes the underlying Puppet Query Language so a user can inspect how a question was translated.
In February 2026, Perforce announced ISO 42001 certification covering Infra Assistant and Code Assist among other products. This concerns the management of AI. It is useful governance context, rather than a promise that every generated configuration will suit every production system.
Free code, paid certainty
Puppet’s commercial history explains the current catalogue. A $42 million funding round in 2018, led by Cisco Investments, supported product expansion and international growth. In 2020, it announced $40 million in financing from funds managed by BlackRock. Perforce completed its acquisition in May 2022; the transaction terms were confidential.
Puppet gave Perforce infrastructure operations capabilities alongside its broader software delivery portfolio. The old startup became part of a larger commercial software business. Its open-source heritage remained important to its identity, but the terms of vendor participation subsequently changed.
In November 2024, Puppet announced plans to move new vendor binaries and packages into controlled repositories, citing security, stability and investment priorities. The February 2025 Core release made the distinction explicit: Core is proprietary, and Perforce no longer maintains open-source Puppet. The earlier Apache-licensed code remains available. Vox Pupuli’s OpenVox provides a community fork intended to preserve downstream compatibility.
Customers now choose between different responsibilities as well as different features. Puppet’s commercial tiers use custom quotations. Core’s developer access has an EULA and a limited node allowance for testing and development. A free trial arrangement should be read with its actual permitted use in mind.
Choose the recurring argument
Puppet fits particularly well where long-lived systems, multiple operating systems and recurring policy requirements produce repeated configuration work. Its customers include insurers, telecoms operators and other organizations with complicated infrastructure. The company advertises an ecosystem reaching more than 40,000 organizations; that figure should not be mistaken for a paid subscription count.
Ansible, Chef, Salt and CFEngine offer alternatives in configuration automation. OpenVox matters to teams wanting a community-maintained Puppet lineage. Terraform often occupies an adjacent job: provisioning resources that Puppet subsequently configures at the operating-system and application layers. A sensible comparison begins with the work to be done.
My reading of the customer results is practical: start with an environment your team keeps rebuilding. Agree on its configuration, put that definition under version control, and review changes together. Puppet’s no-op mode can show planned activity without changing nodes; staging gives the team somewhere to investigate consequences before production.
The licence is only one cost. Someone must own the code, maintain modules, handle exceptions and keep the platform supported. A small estate with little recurring work may offer less to amortize that effort across. And an incorrect policy, efficiently enforced, is still incorrect. Automation makes the quality of the shared decision more consequential.
That is why the six-week server is such a good place to begin. The machine was only the visible object. Around it sat a collection of decisions, checks and memories. Puppet’s useful wager is that an organization can write those decisions down precisely enough to stop negotiating them every time it needs another server.