DEV Community: voxpupuli

How to keep your Puppet modules up to date with Renovate

Robert Waffen — Wed, 25 Mar 2026 16:14:50 +0000

Managing a Puppet control repository with a growing list of dependencies can quickly become a challenge.
Keeping everything up to date manually?
That’s not just tedious — it’s also error-prone.

Modules are updated frequently, sometimes daily.
With a long list of dependencies, it’s easy to miss important updates.
And let’s be honest: humans are not exactly known for perfect consistency when it comes to repetitive tasks.

So why not let a bot handle it?

Why Renovate?

Renovate is designed to take over exactly this kind of work.
It continuously scans your repositories, detects dependency updates, and automatically creates merge requests for you — including changelogs.

Instead of manually checking versions, you simply review and merge PRs.
Much cleaner.
Much safer.

Assumptions

Before we get started, this setup assumes:

Your repositories are hosted on GitLab
You are using GitLab CI with runners
You can run container-based jobs

Setting Up Renovate

Create a Renovate Runner Repository

Create a dedicated repository in GitLab, for example: renovate-runner

Inside this repository, create a config.js file:

module.exports = {
  autodiscover: false,
  dependencyDashboard: true,
  // We only enable the puppet manager here
  // see all managers: https://docs.renovatebot.com/modules/manager/
  enabledManagers: ['puppet'],
  // GitLab API - update with your instance URL
  endpoint: 'https://gitlab.example.com/api/v4/',
  extends: ['config:base', ':semanticCommits', ':semanticCommitTypeAll(chore)'],
  labels: ['renovate', 'dependencies'],
  platform: 'gitlab',
  prCreation: "immediate",
  prHourlyLimit: 20,
  repositories: ['puppet/control-repo'],
  requireConfig: true,
  reviewers: ['@rwaffen'],
  token: process.env.RENOVATE_TOKEN
};

This configuration will create one merge request per dependency update.

If you prefer grouped updates, you can extend it like this:

packageRules: [
  {
    matchManagers: ["puppet"],
    groupName: "{{manager}}",
  }
]

Add GitLab CI Configuration

Create a .gitlab-ci.yml:

---
run_renovate:
  image:
    name: ghcr.io/voxpupuli/renovate:latest
    entrypoint: [""]
  resource_group: production
  script:
    - renovate $RENOVATE_EXTRA_FLAGS
  only:
    - schedules
    - triggers
    - web
  # variables:
  #   LOG_LEVEL: debug

Running Renovate

With everything in place, you can trigger a pipeline in your renovate-runner repository.

Once started, Renovate will take over and handle the full update cycle for you:

It launches the Renovate container
Authenticates using your configured token
Scans the defined repositories
Detects dependency files such as Puppetfile
Resolves current versions and checks for new releases or tags
Creates merge requests whenever updates are available

At this point, your role shifts from maintainer to reviewer:
you simply go through the generated merge requests and decide what to merge.

To make this process truly hands-off, you should also configure a scheduled pipeline in GitLab.
This ensures Renovate runs regularly and keeps your dependencies continuously up to date — without any manual triggering.

Authentication: `RENOVATE_TOKEN`

Renovate requires a Personal Access Token (RENOVATE_TOKEN) to interact with your repositories.

Required permissions:

api
write_repository

It is highly recommended to create this as a group access token, so Renovate can access all relevant repositories — especially important if your Puppetfile includes Git-based modules.

Choosing the Right Container Image

Renovate provides official container images, but they come with some trade-offs:

Large size
Based on Ubuntu
Higher number of known vulnerabilities (CVEs)

Vox Pupuli provides a leaner alternative:

Smaller footprint
Based on Alpine
Significantly fewer vulnerabilities

IMAGE                                 ID             DISK USAGE   CONTENT SIZE   EXTRA
ghcr.io/renovatebot/renovate:latest   0334065a0093       1.87GB          416MB
ghcr.io/voxpupuli/renovate:latest     e354b2af781c        726MB          132MB

Vulnerability Scan (grype)

grype ghcr.io/renovatebot/renovate:latest

 ✔ Scanned for vulnerabilities     [297 vulnerability matches]
   ├── by severity: 1 critical, 10 high, 971 medium, 137 low, 15 negligible
   └── by status:   14 fixed, 1120 not-fixed, 837 ignored

grype ghcr.io/voxpupuli/renovate:latest

 ✔ Scanned for vulnerabilities     [19 vulnerability matches]
   ├── by severity: 0 critical, 15 high, 4 medium, 0 low, 0 negligible
   └── by status:   13 fixed, 6 not-fixed, 0 ignored

Final Thoughts

With Renovate in place, dependency management becomes predictable and automated.
Instead of chasing updates manually, you get a steady stream of structured merge requests — complete with context and changelogs.
In other words: less chaos, more control.

All the Vox Pupuli containers

Robert Waffen — Mon, 24 Mar 2025 09:43:36 +0000

You may have heard about our (now deprecated) puppetserver/puppetdb container images?
But did you know that we have a lot more containers available?
We have the brand new OpenVox containers, which replace the old puppetserver and puppetdb containers, and even some more.

OpenVox containers

openvoxserver

openvoxserver is a drop-in replacement for the old voxpupuli/puppetserver container.

openvoxdb

openvoxdb is a drop-in replacement for the old voxpupuli/puppetdb container.

openvoxagent

openvoxagent is a drop-in replacement for the old puppet/puppet-agent container. It is mostly used for testing purposes, as of now.

Vox Pupuli containers

voxbox

voxbox is a container that contains a lot of tools that are useful for OpenVox/Puppet development and testing.
It includes tools like puppet-lint, modulesync, onceover, facter, yamllint, rubocop and the Vox Pupuli testing gems.

r10k

r10k is a container that contains r10k, a tool to manage OpenVox/Puppet environments.

semantic-release

semantic-release is a container that contains the semantic-release tool, which is used to automatically release new versions of software projects.

commitlint

commitlint is a container that contains the commitlint tool, which is used to lint commit messages.

See also: commitlint and conventional commits

puppet-catalog-diff-viewer

puppet-catalog-diff-viewer is a container that contains the puppet-catalog-diff-viewer tool, which is used to visualize the differences between two OpenVox/Puppet catalogs.

puppetboard

puppetboard is a container that contains the puppetboard tool, which is a web interface for OpenVoxDB/PuppetDB.

Conclusion

So you see, we have a lot of containers available.
If you have any questions or suggestions, feel free to reach out to us on GitHub or on our other Channels
If you need help with any of the containers, feel free to open an issue on the respective GitHub repository.
Some examples of how to use the containers can be found in the CRAFTY repository.

New container names for puppetserver and puppetdb

Robert Waffen — Fri, 02 Aug 2024 12:57:37 +0000

Beginning of today we are also releasing our puppetserver and puppetdb containers with shorter names.

The current names are: voxpupuli/container-puppetserver and voxpupuli/container-puppetdb.

The new, shorter names are: voxpupuli/puppetserver and voxpupuli/puppetdb.

The content is exactly the same, only the name has changed. Only new tags will be pushed to the new names. The old names will also be updated.

We plan to deprecate the old names in 6 months (2025-02), so please update your scripts and configurations to use the new names.

Vox Pupuli election results

Ben Ford — Thu, 23 Mar 2023 02:32:02 +0000

Well, [[checks watch]] would ya look at that. It's March 23, UTC, and that means that it's time to close the Vox Pupuli elections. Not only that but as it turns out, we had precisely five nominations which is the number of open positions. Y'all are making my job as the elections officer way too easy this time around!

Martin was the first to submit a nomination, and as promised we'll be sending him a brand spankin' fresh hoodie as soon as we've got the new design finalized.

Let's get to it and meet your new PMC members!

No surprise to anyone, first up is Tim Muesel, known as bastelfreak to many. One of the most prolific contributors in the Puppet community, Tim's tireless energy is an inspiration to all of us. Read his nomination.

Next up is Romain Tartière, also known as smortex. Romain has been maintaining the FreeBSD Puppet port for so long that he's seen three major Puppet versions go EOL. Read his nomination.

Then we have Robert Waffen, also known as rwaffen. Robert came to the Puppet community and then to Vox Pupuli in the same way that many do--by exploration and debugging and little fixes and then realizing just how much of an impact all his little fixes cumulatively added up to. We're grateful to have Robert and people like him with us. Read his nomination.

Sebastian Rakel is active in both the Vox Pupuli and the Arch Linux communities. Not only is he a diligent pull request reviewer, but he also knows how to make communities valuable for all of us. Read his nomination.

Ewoud Kohl van Wijngaarden, also known as ekohl, is one of the most knowledgeable people in the Puppet community. Not only that, but he's very helpful and always ready to share that expertise. I always pay extra attention to his PR reviews. Read his nomination.

What's next?

Over the next few days, the new PMC officers will be onboarded and the website updated. They'll select also select members to fill a couple specialized roles.

The security officer is the point of contact for external or internal security issues. This person has a published gpg key, and will be the main point of contact for CVE numbers and such
The communications officer is the main point of contact for external and internal publicity and marketing efforts and requests.