Renovate: Automated Dependency Updates Done Right

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.

Starting from a sane baseline

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"]
  }
}

Grouping updates so reviews make sense

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.

• Group tooling packages that share a config format, such as all ESLint plugins and configs, since they tend to break together when a major version lands.
• Group framework packages that ship in lockstep, such as a frontend framework alongside its official type definitions, so a version mismatch never sneaks into a partial update.
• Group all remaining minor and patch updates into a single weekly digest, reserving major updates for their own ungrouped pull requests that get closer scrutiny.

{
  "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"]
    }
  ]
}

Choosing safe automerge rules

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.

Wiring up automerge safely

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"]
    }
  ]
}

1. Confirm your CI pipeline runs the same checks for dependency pull requests as it does for regular pull requests, otherwise automerge is validating nothing.
2. Scope automerge with packageRules matching depType and updateType, rather than a single global automerge flag, so majors and runtime packages stay excluded.
3. Give Renovate roughly two hours of buffer before expecting a merge, since it needs the branch to be up to date with the base branch and the checks to have already finished.

Keeping lockfiles fresh with lockFileMaintenance

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.

Taming pull request noise long term

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.

• Review and merge grouped patch and minor pull requests weekly, even if only skimming the changelog links Renovate includes in the pull request body.
• Use dependency dashboard issues, which Renovate can maintain automatically, as a single place to see every pending update instead of scanning a long pull request list.
• Rate-limit major version pull requests with a separate schedule so they arrive less frequently and get dedicated attention instead of being buried among routine minor updates.
• Periodically prune packageRules that reference dependencies you no longer use, since stale rules silently stop matching anything and clutter the configuration file.

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.