Configure Renovate to Respond to GitLab Repository Actions

June 28, 2025

The typical GitLab use case is to use the Renovate runner project templates, or some variant, to run Renovate in a GitLab CI job on a schedule. If you're looking for an option to provide a more responsive experience without the overhead of self-hosting Renovate, this solution uses Cloudflare Workers, GitLab webhooks, and triggered GitLab pipelines to configure Renovate to respond to repository activity.

Renovate setup on GitLab #

The recommended GitLab setup, as detailed in the Renovate documentation, is to use the Renovate runner project templates, or some variant, to run Renovate in a GitLab CI job on a schedule. This is a good starting point, but lacks much of the experience that you get with the GitHub app or Renovate self-hosted, as can be seen in this Renovate version comparison.

If you're looking for an option to improve the experience, without the overhead of self-hosting, this solution using the GitLab Webhook Renovate Proxy handles the "responds to repo activity" case using Cloudflare Workers, GitLab webhooks, and triggered GitLab pipelines. Cloudflare Workers provide a lightweight, easy to deploy solution that in many cases can be used across large GitLab groups on their free tier (although you may want a paid tier to provide support or other services). Cloudflare Worker also have very short cold start times, so they can be scaled to zero with no activity and still provide a quick response. According to the last build, this Worker's startup time is approximately 12 ms.

The GitLab Webhook Renovate Proxy solution #

The GitLab Webhook Renovate Proxy is part of a bigger setup to make Renovate updates with GitLab CI respond to repository activity. It includes the following components:

GitLab Project: Any GitLab project that uses Renovate for dependency updates.
GitLab Webhook Renovate Proxy: A Cloudflare Worker that filters webhooks so that only authenticated, applicable events trigger a Renovate pipelines.
Renovate Runner: The project that runs Renovate pipelines using the Mend renovate-runner project (or a fork, mirror, etc).

The integrated system works as shown below. Webhooks are configured in GitLab to fire for appropriate events (for example, merge request and issue events). These webhooks are sent to the GitLab Webhook Renovate Proxy, which checks that the webhook is for an event that should run a Renovate pipeline, and if so sends a pipeline trigger request to the GitLab Renovate Runner project specifying that project as the target.

sequenceDiagram
  participant G as GitLab Project
  participant P as GitLab Webhook Renovate Proxy
  participant R as Renovate Runner

  G->>P: Webhook (Merge request open)
  G->>P: Webhook (Merge request merge)
  P->>R: Pipeline trigger request
  R->>R: Run pipeline for project
  G->>P: Webhook (Dependency Dashboard rebase branch)
  P->>R: Pipeline trigger request
  R->>R: Run pipeline for project

The GitLab Webhook Renovate Proxy triggers a Renovate pipeline for the following events:

Merge request merge
Merge request "Rebase this MR" checkbox
All Dependency Dashboard checkboxes

The proxy primarily uses the same information that Renovate itself uses to respond to these events - comments in the description for Renovate created merge requests and Dependency Dashboard issues. The GitLab Webhook Renovate Proxy does not constrain what Renovate updates, it simply determines if a Renovate pipeline should be triggered based on the webhook event. This provides a quick response to these events rather than having to wait for the next scheduled Renovate pipeline.

While the GitLab Webhook Renovate Proxy is written as Cloudflare Worker, it could easily be adapted to run in other similar environments (for example, Knative in a self-hosted environment).

System setup #

See the Setup Guide for detailed instructions on end-to-end setup of the GitLab Webhook Renovate Proxy. While it may seem complex, there are really just a lot of small steps, and the instructions are deliberately explicit for anyone unfamiliar with aspects of the process and to ensure that secrets (or potential secrets, for example project IDs for private project) are appropriately protected. For any problems, see the troubleshooting guide, or open an issue.

Note that like any service exposed to the Internet, the GitLab Webhook Renovate Proxy will likely receive requests scanning for known vulnerabilities (they'll be obvious in the logs). The Worker is designed with an authentication mechanism and rejects these requests, but the system alone is not designed to protect against any large scale denial-of-service attacks. While this has not been seen, if required Cloudflare has options for rate limiting and other protections.

Results #

This system has been in use with multiple gitlab.com groups for about 6 months. The groups have 50 - 75 projects with updates managed by Renovate. In most cases almost all project dependencies are as strictly versioned as practical, so there are over 800 total Renovate-managed dependencies across the groups. Most of the projects are also configured to rebase Renovate updates when behind the base branch to best align with the GitLab fast forward merge strategy that the projects primarily use. So, there are a lot of Renovate pipelines across the groups. Renovate is run on the default GitLab hosted runner (the small Linux x86-64 Kubernetes runner) as performance has been observed to be predominantly network bound, so a more capable runner adds limited benefit for the cost.

In general, the Renovate pipelines triggered by the GitLab Webhook Renovate Proxy run in 1 - 2 minutes total. Almost one minute is the image download itself. Given the various ecosystems that Renovate supports there is a lot in the image and it is fairly large (~400 MB compressed, ~1.3 GB uncompressed), and with frequent Renovate updates (many times per day) there is minimal caching (although the GitLab hosted runners are configured to use GCP's pull-through image cache, so it is used when applicable).

Overall, that puts the responsiveness of Renovate similar to the GitHub app for responding to repository changes (my best comparison point having never self-hosted Renovate Community/Enterprise). It's a huge usability improvements for cases where you're trying to process multiple Renovate updates against a single repository. While it does not have all of the optimizations that the GitHub app or Renovate self-hosted do, it's a good compromise for GitLab hosted projects that do not want the overhead of the self-hosted Renovate solution.