DevOps
Renovate: Automated Dependency Updates Done Right
July 20268 min read
Photo by Brickset on flickr
Renovate is an open-source bot that scans a repository's manifest files and opens pull requests whenever a newer version of a dependency is available. Unlike manual updates, it runs on a schedule you define, checks every dependency continuously, and can automatically merge low-risk updates once your tests pass, removing the need for someone to remember to check for outdated packages.
A single pull request per dependency does not scale once a repository has dozens of packages, since reviewers end up approving many near-identical diffs. Grouping with packageRules and groupName bundles related packages, such as an entire tooling ecosystem or a framework with its type definitions, into one pull request, making review faster and reducing the chance that a partial update leaves mismatched versions in place.
Scope automerge to low-risk update types using packageRules that match on depType and updateType, for example enabling automerge only for patch and minor updates to devDependencies once CI passes. Reserve major version updates and runtime dependency changes for manual review, since semantic versioning only signals intent rather than guaranteeing safety, and enable platformAutomerge so your hosting platform's native merge respects existing branch protection rules.
Yes, the lockFileMaintenance option tells Renovate to periodically regenerate the lockfile on its own schedule, which picks up transitive dependency updates and security patches that would otherwise sit untouched until the next direct dependency bump. Running it weekly, separate from the main update schedule, keeps each lockfile refresh as a small and easy to review pull request.
Set an explicit weekly schedule combined with prConcurrentLimit and prHourlyLimit to control the pace of new pull requests, group related packages so several updates arrive as one diff, and use Renovate's dependency dashboard issue to track everything pending in one place. Rate-limiting major version updates with their own schedule also keeps rare, higher-risk changes from being buried among routine minor updates.
Photo by Brickset on flickr
Key Takeaway
Renovate keeps dependencies current by opening scheduled pull requests, but the default config quickly becomes noisy. Setting an explicit schedule and PR limits, grouping related packages, scoping automerge by risk, and running lockFileMaintenance weekly turns Renovate into a quiet, trustworthy pipeline instead of a source of alert fatigue.
Every repository eventually accumulates dozens of dependencies, and every one of them eventually needs an update. Left alone, that turns into a pile of security warnings, breaking changes nobody noticed, and a lockfile that has not been touched in months. Renovate solves this by opening pull requests for outdated dependencies on a schedule you control, but the default configuration is rarely the configuration you actually want.
This guide walks through the Renovate settings that matter most in practice: grouping related packages so reviewers are not drowning in single-package pull requests, choosing safe automerge rules, scheduling updates so they do not collide with releases, and keeping lockfiles fresh without extra manual work. The examples come from real production repository configurations, not the bare defaults.
Renovate ships with a recommended preset that covers most defaults reasonably well, but three settings are worth setting explicitly from day one: timezone, schedule, and pull request limits. Without an explicit schedule, Renovate will open pull requests at any time, which means your team wakes up to a wall of notifications. Setting a weekly window keeps updates predictable, and capping concurrent and hourly pull requests prevents Renovate from overwhelming your CI runners the moment it onboards a new repository. The timezone setting matters more than it looks, since schedule strings like before six on Monday are evaluated against it, and a mismatched timezone silently shifts every window by several hours, confusing anyone trying to reason about when pull requests will actually appear.
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["config:recommended"],
"timezone": "Asia/Jakarta",
"schedule": ["before 6am on monday"],
"labels": ["dependencies"],
"prConcurrentLimit": 5,
"prHourlyLimit": 2,
"lockFileMaintenance": {
"enabled": true,
"schedule": ["before 6am on monday"]
}
}Set prConcurrentLimit and prHourlyLimit even on small repositories. The first onboarding run on a repo with a stale lockfile can otherwise open thirty or more pull requests in a single pass, which floods CI and makes review impossible.
By default, Renovate opens one pull request per dependency. That is precise, but it does not scale past a handful of packages. The fix is packageRules with a groupName, which bundles related dependencies into a single pull request. Group packages that are released together or that share a blast radius, so a reviewer can reason about the whole group in one pass rather than approving fifteen near-identical diffs.
{
"packageRules": [
{
"description": "Group all ESLint packages together",
"matchPackageNames": ["eslint", "eslint-config-*", "eslint-plugin-*"],
"groupName": "eslint"
},
{
"description": "Group Next.js and React together, they ship in lockstep",
"matchPackageNames": ["next", "react", "react-dom", "@types/react", "@types/react-dom"],
"groupName": "next-react"
},
{
"description": "Weekly digest for everything else",
"matchPackagePatterns": ["*"],
"groupName": "all non-major dependencies",
"matchUpdateTypes": ["minor", "patch"]
}
]
}Automerge is where Renovate earns its keep, but only if the rules match the actual risk of each update type. Patch and minor updates to development tooling are usually safe to merge automatically once tests pass, because semantic versioning promises backward compatibility and the blast radius if something breaks is limited to your build pipeline. Major updates and anything touching runtime dependencies deserve a human in the loop, since semantic versioning only promises intent, not guaranteed safety. The table below reflects a starting point that most repositories can adopt without much customization, though teams with unusually thorough integration test coverage can reasonably push automerge further into the minor and even major update categories over time.
| Update type | Typical risk | Recommendation |
|---|---|---|
| Patch (devDependencies) | Low | Automerge once CI passes |
| Minor (runtime dependencies) | Moderate | Automerge with a short soak window, or require one approval |
| Major (any dependency) | High | Never automerge, label for manual review |
Automerge only reflects the confidence of your own test suite. If your tests do not exercise the code paths a dependency actually touches, automerge will happily merge a broken update the moment the build turns green.
Renovate supports two automerge mechanisms. With automergeType set to pr, Renovate opens a normal pull request, waits for required checks to pass, then merges it itself. With platformAutomerge enabled, the merge is instead handled by the hosting platform's native automerge feature, which respects branch protection rules and plays nicely with required reviewers. Most teams should prefer platform automerge once their CI checks are trustworthy, since it keeps a single audit trail in the platform's own merge history.
{
"packageRules": [
{
"description": "Automerge devDependencies minor/patch after CI passes",
"matchDepTypes": ["devDependencies"],
"matchUpdateTypes": ["minor", "patch"],
"automerge": true,
"automergeType": "pr",
"platformAutomerge": true
},
{
"description": "Never automerge majors, always require manual review",
"matchUpdateTypes": ["major"],
"automerge": false,
"labels": ["dependencies", "needs-review"]
}
]
}Even when no dependency version in your manifest changes, transitive dependencies drift over time as upstream packages publish new patch releases. lockFileMaintenance tells Renovate to periodically regenerate the lockfile on its own schedule, catching transitive updates and security patches that would otherwise sit untouched until the next direct dependency bump. Running it on a weekly schedule, separate from your regular update schedule, keeps the diff small and easy to review. This matters most for teams relying on lockfile audits or vulnerability scanners, since a transitive dependency with a known advisory can sit in a lockfile for months if nothing ever prompts Renovate to touch that part of the dependency tree.
Combining lockFileMaintenance with a weekly schedule and its own groupName keeps lockfile refreshes as a single small, predictable pull request instead of an enormous diff that appears once a quarter.
The biggest failure mode with Renovate is not misconfiguration, it is neglect. A pull request backlog that nobody reviews trains the team to ignore Renovate entirely, defeating the purpose. A few habits keep the signal-to-noise ratio high months after the initial setup.
Renovate's own onboarding pull request includes a preview of every configuration it would apply. Read it carefully before merging, since it is the cheapest opportunity to catch a grouping or schedule mistake before it generates real pull requests.
None of these settings are exotic. Grouping, scoped automerge rules, an explicit schedule, and lockfile maintenance are all documented defaults that most teams simply never bother to tune. The payoff is a dependency pipeline that quietly keeps a repository current without turning into a second job for whoever reviews pull requests. Start with the baseline configuration in this guide, watch how the first month of pull requests behaves, and adjust the grouping and automerge rules based on what actually shows up rather than guessing in advance.