Skip to content

How to get started with renovatebot

Warning

Our use of renovatebot is in an early stage. Feedback is welcome via the GitLab project.

Renovatebot is an automated process which will raise Merge Requests in your GitLab projects to keep your dependencies fresh. It is very configurable but the default configuration has been designed to fulfil the needs of a typical DevOps project.

This how-to guide covers how to opt in to having renovatebot scan your projects and what to expect.

Optionally, configure CODEOWNERS for your project

Renovatebot can auto-assign Merge Requests to people in your project but you need to add a CODEOWNERS file first.

Merge the on-boarding Merge Request

All projects should have an onboarding Merge Request from renovatebot (example) which will configure your project to use the default renovatebot configuration.

Merge this Merge Request to enable renovatebot for your project.

Note

Since 10 Aug 2026, the default configuration enables the "moderate" level of automerge: digest pinning, lock file maintenance, patch and minor version updates are approved and merged automatically if CI passes. See how to enable automerge to choose a different level or disable automerge.

Alternatively, if you can't find the onboarding MR, add the following to renovate.json at the root of your repository:

renovate.json
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "local>uis/devops/renovate-config"
  ]
}

Expect new releases to wait three days

Since 13 Oct 2026, the default configuration includes the minimumReleaseAge preset. Renovatebot won't propose a release until it has been public for three days, which gives registries and maintainers time to pull a compromised release before it reaches your project. This was agreed in the minimum release age ADR.

With the weekday schedule, an MR for a new release can take up to about six days to appear.

The wait only applies where the registry reports a release date. The preset also exempts these sources, so they arrive at the next run as before:

  • images in our GitLab container registry, including the Docker Hardened Image mirrors
  • GitLab tags, releases and packages from gitlab.developers.cam.ac.uk
  • our own Maven artefacts (uk.ac.cam and hr-integration)
  • copier template updates

Lock file maintenance passes the age on to npm. Poetry lock files will get it once renovatebot runs Renovate 44.34.0 or later, but it's on Renovate 43 as of 13 Oct 2026, so they aren't gated yet. Yarn, pnpm and uv lock files need a setting in each repository. See how to use package managers securely and the appendix of the ADR.

Take an urgent update early

To take a release before the three days are up, for example a security fix, check your repository's Dependency Dashboard issue. If the update is listed under "Pending Status Checks", tick its checkbox, and Renovatebot creates the MR the next time it runs, even outside the weekday schedule. Otherwise, update the dependency in your own MR.

Minor and patch updates to packages at 1.0.0 or later usually won't be listed. They're grouped into the "all non-major dependencies" MR, and Renovatebot leaves a pending update out of that MR, with no checkbox, while other updates in the group are ready.

Turn the wait off for a repository

Set minimumReleaseAge to null in renovate.json, and say why in description:

renovate.json
{
  "extends": [
    "local>uis/devops/renovate-config"
  ],
  "minimumReleaseAge": null,
  "description": "No release age gate: <reason>"
}

Summary

In this guide you learned how to add your GitLab group to the renovatebot allowlist, merge the on-boarding Merge Request, and what the three-day wait for new releases means for your project.

Next steps