Best Practices

Renovate Bot Configuration Recipes for 2026

Renovate is the more powerful dependency-update bot, and its config surface is large. Here are the recipes worth knowing and the defaults worth overriding.

Karan Patel
Staff Engineer
6 min read

Renovate is what you choose when Dependabot is not enough. The configuration surface is larger, the supported ecosystems are broader, and the rule language lets you express policies that would take a custom GitHub Action to implement otherwise. The trade-off is that the default config is too permissive for most security-conscious teams, and getting Renovate dialed in correctly takes some up-front work.

This post collects the configuration recipes worth knowing in 2026. The assumption is that you have Renovate running and want to know what to tune.

What does a sane base config look like?

Renovate's config:base preset is the starting point, but it is tuned for open source projects, not for production engineering organizations. The fork that most teams want is something closer to config:recommended plus a handful of overrides. The most important override is rangeStrategy: pin, which converts caret and tilde ranges in package.json and similar files into pinned versions. Pinning is non-negotiable for security in 2026; floating ranges are how the event-stream and ua-parser-js incidents propagated to thousands of downstream consumers within hours.

Combine pinning with lockFileMaintenance set to weekly, which keeps package-lock.json and equivalents fresh without churning the manifest. Set prConcurrentLimit to a number that matches your team's review velocity, typically between four and ten, and prHourlyLimit to two or three to prevent the bot from flooding the queue when an upstream major release lands. The schedule field should be set to a business-hours window in your team's timezone, because a Renovate PR that lands at 2am is a Renovate PR that gets stale.

How should you configure digest pinning for Docker images?

Renovate's killer feature relative to Dependabot is real digest pinning for container images. Setting pinDigests: true causes Renovate to expand FROM node:20-alpine to FROM node:20-alpine@sha256:... and to open a PR whenever the upstream image is rebuilt under the same tag. This is the only reliable way to detect base image security rebuilds in real time, and it eliminates the silent-update failure mode where a critical base patch lands but your build still uses the old layers.

The catch is that digest pinning increases PR volume noticeably, because popular base images are rebuilt frequently. Tune this by grouping digest updates with packageRules that match updateTypes: ["digest"] and routing them to a single weekly PR for non-critical images. Keep critical base images, the ones in your zero-trust image baseline, on their own group with daily updates. The 2024 incident where a popular Alpine-based image had a critical OpenSSL CVE in its underlying base demonstrated why this matters: teams with digest pinning got a PR within hours; teams on tag-only pinning had to discover the issue out-of-band.

What about the dependency dashboard?

Renovate's dependency dashboard, enabled with dependencyDashboard: true, creates a single GitHub issue that lists every pending and rate-limited update. This is the central operational view for the bot, and it is the right place to triage from. Most teams ignore it, then complain that Renovate is slow or that PRs are not appearing; nine times out of ten the dashboard shows that the limits are hit and the bot is queuing correctly.

The dashboard is also where you approve major version updates if you have set dependencyDashboardApproval: true for a package group. Major version bumps should require explicit approval rather than auto-PR creation, because they almost always require code changes and a developer who is not ready to do those changes will just close the PR. Routing majors through the dashboard turns them into a deliberate planning step rather than a stream of unwanted notifications.

How do you express supply chain guardrails as Renovate rules?

The packageRules field is where the real configuration happens. A useful pattern is a rule that delays any new dependency or any major version bump by a minimum age, expressed through minimumReleaseAge: "7 days". This implements the quarantine window that catches most malicious npm releases. Set a longer window, fourteen or thirty days, for packages from maintainers not on your trust list, and a shorter window for first-party packages.

Another useful rule is matchPackagePatterns combined with enabled: false for packages you explicitly do not want updated automatically, typically frameworks where the upgrade requires manual migration. The 2018 event-stream takeover, where a malicious maintainer added the flatmap-stream dependency, would have been caught by a rule that flagged any new transitive dependency from a maintainer not on the trust list. Renovate's matchNewValue matcher lets you write that rule today.

What about handling Renovate's own updates?

Renovate runs as either a self-hosted bot or as the Mend-hosted service. In either case, the bot itself is a piece of infrastructure that updates frequently, and the update path is its own supply chain risk. Self-hosted deployments should pin the Renovate image to a specific digest, update it through a deliberate review process, and never auto-update the bot from upstream. The bot has commit privileges across your repository fleet, and a compromised Renovate would be among the worst possible supply chain incidents.

The hosted version, Mend Renovate, removes the operational burden but introduces a third-party dependency on Mend's infrastructure. Either model is defensible, but the choice should be deliberate. For high-security environments, self-hosted on infrastructure you control, with the bot's GitHub App permissions scoped tightly, is the safer option. Restrict the app to repositories that need it; do not install it organization-wide just because the install flow makes that easy.

How Safeguard Helps

Safeguard integrates with Renovate by analyzing every proposed dependency update before the PR opens. Reachability analysis runs against the proposed change to tell you whether the new version actually fixes a CVE that affects your service, so the bot's output is sorted by real risk rather than by version number. Griffin AI evaluates the upstream maintainer's TPRM score and recent activity, flagging updates from accounts with anomalous behavior for human review. Our zero-day feed integrates with Renovate's quarantine windows, automatically lengthening the delay for packages with active intelligence indicators. Policy gates in CI re-validate the final merge against your zero-CVE image baseline, catching regressions that slip past the bot's heuristics. The combination turns Renovate from a notification stream into an enforceable supply chain control.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.