Teams using Puppet may need to distribute private configuration modules or keep a local source for modules downloaded from elsewhere. The puppet-forge-server package behind this historical chart provides a private module store and an approximation of the Puppet Forge APIs. It is a distribution service for infrastructure code, not Puppet’s public module website itself. Before relying on it for rebuilds, verify the actual client compatibility and preserve the module archives and metadata on which those clients depend.
Current guidance
The incubator/puppet-forge chart identifies the former unibet/puppet-forge-server project, whose repository now resolves under kindredgroup. The upstream implements a private module store and approximate Forge v1/v3 proxies, explicitly allowing behavioral differences from the official service. It is not the public Puppet Forge itself or a general-purpose artifact registry.
The README names older Puppet client generations and Ruby build dependencies. Current Puppet/r10k compatibility, supported Ruby versions and security maintenance were not established by this review, so the entry remains unverified. Before adoption, obtain a supported combination or prove the required client/API behavior in an isolated package-distribution environment.
For an existing instance, preserve locally published module archives, checksums, version metadata, proxy configuration and access controls. Test dependency resolution, cached and uncached downloads, upstream outages and authentication with the actual deployment clients. A replacement package service must implement the expected Forge API rather than merely host tarballs. Keep a read-only copy of existing modules during migration so rebuilding infrastructure does not depend on disappearing cached artifacts.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
Distribute locally developed Puppet modules and proxy to the official Puppet Forge server.
Container for running the puppet_forge_server project from Github. This project allows one to serve locally developed Puppet forge modules and proxy requests to an upstream Puppet forge server (typically the official server run by Puppetlabs).
Puppet Forge Server provides an approximated implementation of both v1 and v3 APIs, but behavioral deviations from the official implementation might occur.
Puppet 2, 3 and 4, as well as librarian-puppet, are supported.
Server Architecture
The code is structured with MVC in mind to allow easier maintenance and readability
API (view)
API classes (actually modules only) are used to extend Sinatra application classes. Every module corresponds to official API endpoint and used to present received model data in fashion required by the given API version.
App (controller)
Every App class is a Sinatra application class and is responsible for mapping API endpoints, querying backends for requested data and providing the results using API (view) modules.
Models
Puppet module metadata json representation is used as a main business model
Backends
Backend classes are providing the means of fetching required data and creating model instances.
How to use this container
The container, when invoked with no arguments, will start the Puppet forge server at port 8080 with local Puppet forge modules locate in /puppet/modules. If a volume mount is not specified to /puppet/modules, then all modules are kept within the container and the modules will be purged upon restarting the container. In addition, the log files for the service are kept in /puppet/logs.
If any arguments are provided after the container name and begin with a dash, then the arguments are provided as arguments to the Puppet forge server. Otherwise, the arguments are executed as a command within the context of the container.
In addition, there are a couple of meta-commands that the container will respond to. If readme, info, or help (all case-insensitive) are specified as the first argument, then this README file will be displayed. Also if the argument is the version, then the current Puppet forge server version is printed.
Sources & further reading
Spotted something that needs another look?
Help improve this page →