Renovate Bot: 4 advanced tips and tricks – Part II

This is part two of a series that provides tips for advanced Renovate Bot users. It gives valuable tips for writing your own custom managers or custom data sources, explains why and how to self-host a Renovate Bot instance, and how to reduce friction when introducing Renovate to your teams.

Originally posted on 2023-09-17, updated on 2026-08-14.

Introduction to Renovate Bot

Renovate (Bot) is a CLI tool that regularly scans your Git repositories for outdated dependencies. If it finds any, it automatically creates a pull request (PR) that updates the dependency. I highly recommend my Renovate introduction article to get you started with the basics, my cheat sheet article for the first steps to tune your configuration, and part 1 of this article series.

This article is for Renovate users who have already worked with Renovate for a few days or weeks, and would like to know more about some of Renovate’s capabilities. It contains several lessons I learnt over several years of using it.

Tip 1: Write custom managers

Sometimes you want Renovate to update dependencies you defined in a file whose format is not supported by any of the bundled managers. As of 2026, Renovate offers two types of custom managers (docs): the custom regex manager (docs) and the JSONata manager (docs). They let you find updates in this situation. The official Renovate documentation is very good and includes many examples, so make sure to read it carefully. Here are a few tips to get you started:

• Use coding agents / LLMs to help you create these custom managers. Today, LLMs (like OpenAI’s GPT or Anthropic’s Claude Sonnet/Opus) get (even complex) regex or JSONata expressions right, on the first try. However, you need to ensure your coding agent has access to the current documentation. See this workshop task that demonstrates how to create a JSONata custom manager, including an example prompt and result.
• JSONata managers are recommended over regex managers if you want to find dependencies in structured files (JSON, YAML, and TOML are supported). While you could also use regex managers in structured files, regex patterns are rather “brittle”. They expect matched strings (and capture groups) to appear in a very specific order. Humans might (accidentally) violate the order (e.g., defining fields in a different order -> a yaml/json/toml parser would not complain, since it ignores field ordering), and the regex manager (silently) fails.
• Regex managers typically come in two flavors:
  • Either, they are specific to certain files and find only specific dependencies in those files. You encode that knowledge in the custom manager in renovate.json. See here for an example.
  • Or they are generic/dynamic; see here for an example. They can match multiple files, and multiple dependencies per file. This approach assumes that those file formats support comments (which is the case for, say, Dockerfiles). A typical approach is to place a “# renovate: datasource=... depName=...” comment above the line that declares the dependency.
• Whenever you specify a regex in renovate.json, e.g., in the setting managerFilePattern, beware that you need additional backslashes in the renovate.json file. For instance, if you want managerFilePattern to match the file “foo.bar“, a technically correct regex is “^foo\.bar$“, but you must use “^foo\\.bar$” in your renovate.json. This is because Renovate’s JSON parser consumes one of the two backslashes. Keep this in mind when copying strings between the regex helper app and your renovate.json file (or when checking your coding agent’s output).
• If you are wondering why regex managers support both depName and packageName: the difference is explained here.
• Syntax such as "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" (see the examples on the regex manager docs page) will make more sense once you read the templates docs page.

Tip 2: Write custom data sources

While Renovate’s bundled data sources cover pretty much any open (source) registry, you might be installing dependencies from closed/proprietary/niche registries. Renovate’s custom data sources (docs) let you configure that Renovate parses HTTP(S) URLs (or local files committed to your repo, using the file://<relative-path> syntax) and finds dependencies in them. Renovate supports different formats and also allows transforming the content with JSONata, if necessary. See e.g. here for an example that updates Grafana dashboards.

Like for tip #1, I highly recommend using coding agents / LLMs to help you create these custom data sources. Again, you need to ensure your coding agent has access to the current documentation, or risk hallucinated results.

Tip 3: Best practices for self-hosting

Even though you can avoid self-hosting Renovate if your code is on github.com, I still recommend self-hosting under any circumstances.

Self-hosting advantages

Self-hosting has the following advantages:

• You can specify your preferred execution frequency (in contrast, Mend’s official Renovate app may visit your repository only once every 12 hours, depending on the load on Mend’s platform)
• Improved reproducibility: you control which version of Renovate is running
• Improved security: you are not giving a third party (Mend) access to your code
• You can run post-upgrade tasks (discussed in part 1 of this series)

Self-hosting disadvantages

In practice, I found only two real disadvantages of self-hosting Renovate, but they only apply if Renovate scans many repositories (of several developer teams). In that scenario, a single Renovate run may take hours to process all repositories.

1. You need to build your own approach for scaling the execution of Renovate. This discussion has a few pointers. Alternatively, if you use Kubernetes, you can use the renovate-operator.
2. You need an approach for your developer teams to access the debug logs of your central Renovate instance (dev teams need those debug logs to diagnose issues themselves, without having to contact you, the central Renovate admin team). Granting access is easy if it’s (socially) accepted that every dev team may access the debug logs of any other team. But if you want isolated teams, you might need to build custom tooling that allows teams to access only their own Renovate debug logs. Note that renovate-operator supports this out of the box.

Recommended execution mode

For small projects, I generally recommend you use scheduled CI pipelines to execute Renovate (over other approaches, such as cron jobs), and that you run Renovate as Docker/OCI container. The advantages are:

• You most likely use some CI/CD platform anyway, so setting up a scheduled pipeline is little extra effort
• You get notifications in case of problems with Renovate (e.g., emails sent when a pipeline fails)
• You can easily inspect Renovate’s output log by clicking on executed pipeline instances in the CI/CD platform’s web UI
• You get a high level of reproducibility, given that you are pinning Renovate’s image version

If you self-host on GitLab, you can use Renovate’s official GitLab runner repository. In all other cases, you can either:

1. Run a container-based job (which most CI/CD platforms support), or
2. Run docker build … followed by docker run --rm … to locally build (but not push) and then run the image

Docker image variants

There are two official Renovate Docker image variants: the full image and the slim image, see the docs for details. Both Docker images are based on the containerbase project and let you install additional tools via the shell command “install-tool <tool-name> <tool-version>“, e.g. “install-tool node 20.0.0“. Please note that install-tool supports only specific tools; see here and here for a list. The slim Docker image only comes with a few tools installed. It is therefore smaller and used by default. The full image contains many more (but not all) tools. Both these images are based on this multi-stage Dockerfile that defines which concrete tools are pre-installed in the slim and full versions. Running the install-tool to install additional tools (before running the renovate CLI) may be useful in certain situations, e.g. if you run post-upgrade tasks that require such tools (like Helm or Terraform).

Recommended tunings to config.js

In your config.js I recommend the following additions:

module.exports = {
  endpoint: '...',
  // more stuff here
  onboardingConfigFileName: “renovate.jsonc”,
  extends: ["mergeConfidence:all-badges"], // see https://docs.renovatebot.com/merge-confidence/ 
};
Code language: JavaScript (javascript)

This configures that your Onboarding PR uses renovate.jsonc by default, which lets you add comments which won’t break during Renovate-initiated Config Migration PRs (in contrast, comments in renovate.json5 files will be removed). It also adds merge confidence badges, as recommended in the docs.

You can add many more repository-specific configuration options to config.js, when you think that they are a good default (and should therefore already be present in the Onboarding PR). See my cheat sheet for inspiration.

Tip 4: Preview Renovate’s PRs on a forked repository

If you introduce Renovate to your software development team (which may never have worked with such automated dependency tools before), it is a good idea to start with a copy of the affected repositories. The copy is your safe playground in which you build and tune the renovate.json configuration file, without the risk of generating inappropriate PRs. The dev team also gets a full preview of how Renovate’s PRs look, compared to the short list presented by Renovate’s Onboarding PR. Once your team agrees to use Renovate, you delete the repository copies again and configure Renovate to visit the real repositories.

To actually make a repository copy, you can either fork it (in this case, make sure to read Renovate’s fork processing docs), or you create a new Git repository, set it as an additional Git remote in your local clone of the source repository, and push the default branch of the source repository to the new repository’s remote.

Tip 5: Offer a practice workshop to your teams

If you want to introduce Renovate even more slowly than in tip #4, hold a workshop that gives your developers a glimpse into how Renovate works. This practice workshop should be on a small example code base with outdated dependencies in several languages. The workshop should teach your team how to onboard Renovate and apply several configuration tweaks. This way, your team gains Renovate experience in a safe, sandbox-like environment, without the risk of polluting your real repositories with undesired PRs.

I designed such a workshop already, see here. Feel free to use it as-is, or adapt it to your needs.

Conclusion

I hope the tips presented in this article help you get more out of Renovate. Especially tip #3 should help you with setting up your own Renovate instance, which has many advantages. You can find more tips and tricks in part 1 of this series.