The README recommends the commercial product, and 8.10.0 and 7.34.0 shipped together

The first installation instruction recommends the paid product

The Installation section is three paragraphs and the first one is a sales pitch.

It says the best way to run Puppet is with Puppet Enterprise, which also includes orchestration features, a web console and professional support, and it links the PE documentation. The open source install is the second paragraph, and it is a link to the installation guide on the docs site. The third is a link to the Quick Start to Developing on Puppet guide for running from source as a tester or developer.

So an open source repository whose README opens its install section by recommending the commercial edition is telling you something about the intended path. It is not an argument that the open source version is bad, and the licensing section is unambiguous that Puppet is Apache licensed. It is a statement about where the company's support model sits.

The same shape appears in the Support section, which lists GitHub Issues, a Google Groups mailing list for the puppet-users group and a Puppet Community Slack, and then adds that long-term support including security patches and bug fixes is available for commercial customers, with a link to the Puppet Enterprise Support Lifecycle page.

Everything a free user needs to ask a question is there. Everything a free user needs to be safe for five years is not.

Two versions on one day is the backport policy being visible

The release record contains a detail that only makes sense if you read the Support section.

The three newest tags are 8.10.0, published on 2024-10-22, and 7.34.0, published on 2024-10-22 as well, with 8.9.0 before them on 2024-09-06.

Two releases on the same day, one on the 8 series and one on the 7 series, is the backport policy operating. The README describes it in three sentences: bug fixes and ongoing development occur in minor releases for the current major version, and security fixes are backported to a previous major version on a best-effort basis until the previous major version is no longer maintained.

The worked example in the README makes it concrete. If a security vulnerability is discovered in Puppet 8.1.1, the fix goes into the 8 series, most likely as 8.1.2, and maintainers then make a best effort to backport that fix onto the latest Puppet 7 release.

So 7.34.0 is the seventh series still receiving fixes, and 8.10.0 is the current series. The same day is the point: a single decision produced two artefacts.

Best-effort is the word to hold on to. It is not a commitment, and the README does not dress it up as one.

install.rb and conf/ are still in the tree beside rakelib/ and ext/

The repository layout is a museum of installation mechanisms, and that is the honest way to read it.

There is install.rb at the root, which is the Ruby installer script from the era when Puppet shipped as a tarball you ran through a Ruby script. There is conf/ for configuration, and ext/. There is rakelib/ for Rake tasks, and a Rakefile at the root. There is puppet.gemspec and a Gemfile, so the modern path is a gem.

Then the directories that tell you what the project actually is. lib/ is the implementation, spec/ is the unit tests, and acceptance/ is a separate tier of tests for the thing being managed rather than the code managing it. benchmarks/ is a performance directory, which is not a common thing to carry. api/ and references/ sit side by side.

There is also a Guardfile.example for file watching, .rubocop.yml with a .rubocop_todo.yml beside it, .yardopts and a yardoc/ directory for API documentation, man/ for manual pages, locales/ for translations, CODEOWNERS, a .mailmap, and .noexec.yaml.

The contribution guide is not in this repository

The Developing and Contributing section links three documents and two of them are in another repository.

For getting a system set up, it points at the Quickstart Guide in this repository's docs directory, and for more complete development documentation at the developer documents, also here. But the document that explains how to get changes merged in is the Contribution Documents, and that link goes to the puppetlabs/.github repository rather than to puppetlabs/puppet.

That is a deliberate split rather than an oversight. A shared contribution and governance repository across every Puppet project is a normal way to run an organisation with many related repositories, and it means the contribution rules are not versioned alongside the code they apply to.

For a contributor, the practical sequence is: read the quickstart in docs/ here, get the system building, then read the contribution documents in the other repository before opening a pull request.

The support section follows the same pattern. GitHub Issues here, the puppet-users mailing list, and a community Slack, all three named with links and none of them a per-project forum.

The README is forty lines and every task is a link

The single most useful thing about this README is what it declines to do.

It describes the product in one sentence: an automated administrative engine for Linux, Unix and Windows systems that performs administrative tasks such as adding users, installing packages and updating server configurations based on a centralized specification.

Then it links out. Documentation at the Puppet Docs site. The HTTP API Index. The installation guide. The PE documentation. The quickstart guide. The developer documents. The LICENSE file. GitHub Issues. A mailing list. A Slack workspace. The PE support lifecycle page.

There is not a single command in the file, no configuration example, no code block and no manifest snippet. A reader gets the shape of the thing and a list of places to read about it.

For a project that has been running since the previous decade, that is a defensible choice: the docs site is the canonical place and a README that duplicates it goes stale. The cost is that nothing in the repository tells you how to start, and the tree confirms it. There is a docs/ directory, but the README never describes what is in it beyond pointing at it.

The newest release is from October 2024 and main moved in August 2026

The gap between the release record and the branch is the last thing a reader should hold on to.

The three newest release tags are 8.10.0 and 7.34.0 from 2024-10-22, and 8.9.0 from 2024-09-06. The last push to the default branch, main, was on 2026-08-06.

So the last published artefact is close to two years older than the last commit. That is not a criticism of the project on its own, since a configuration management tool is not expected to release weekly, and the README explicitly recommends users stay up to date by upgrading to patch and minor releases as they become available.

What it does mean is that a reader has to choose a version deliberately. The README recommends newest-first, the tags go up to 8.10.0, and main is somewhere beyond that.

What the reader gets instead is two URLs and a sentence about where to read about installing it:

https://puppet.com/docs/puppet/latest/http_api/http_api_index.html
https://puppet.com/docs/puppet/latest/installing_and_upgrading.html

What the tree does carry is three example directories. They are examples/enc/, examples/hiera/ and examples/nagios/.

Editorial conclusion

Take Puppet when you want configuration management described centrally and applied across many machines, and you are prepared to run an agent on each of them. Leave it if you need long-term support, because the README says long-term support including security patches and bug fixes is available for commercial customers, and security fixes for a previous major version are backported on a best-effort basis only. Verify three things. Read the support lifecycle page before you commit to a version, because the policy described is a best-effort backport until the previous major version is no longer maintained. Check the release tags against the version you plan to run, since 8.10.0 and 7.34.0 were published on the same day while the last push to main was on 2026-08-06. And read install.rb and conf/ if you deploy from an archive rather than a package, because the repository still carries the old Ruby installer next to a rakelib of Rake tasks.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. puppetlabs/puppet on GitHub
4. README
5. Releases