Renovate

What it does

Renovate scans a repository for outdated dependencies and opens pull requests to update them. It reads manifests across a wide range of ecosystems — npm, pip, Go modules, Maven, Gradle, Cargo, Docker tags, Terraform providers, GitHub Actions versions, Helm charts — which is where it pulls ahead of Dependabot's narrower coverage.

Created in 2017 and acquired by Mend.io in 2019, all three editions share the same core codebase.

Controlling the flood

Turning Renovate on with defaults against a mature repository produces a great many pull requests. The configuration surface exists to manage this, and using it is not optional.

Package rules group related updates so a dozen @types/* bumps arrive as one PR. Schedules restrict when PRs open, so updates land Monday morning rather than continuously. Auto-merge can take patch updates to dev dependencies straight through once CI passes, leaving humans to review only what carries risk. Stability days hold a release for a period before proposing it, which avoids adopting a version that gets yanked.

Getting this right takes iteration. The first configuration is usually too permissive, the second too restrictive, and a workable policy emerges after a few weeks. Teams that skip the tuning tend to conclude Renovate is noisy — which it is, unconfigured.

Editions

The Renovate CLI is free and open source, and the hosted Community edition is free. Mend Renovate Enterprise is paid and self-hosted, adding security checks, effort estimation for updates, granular control and support.

The practical split is that most teams run the free hosted app or the CLI in CI, and the enterprise edition targets organisations that need the bot inside their own network with reporting across many repositories.

In a monorepo

Monorepos need the most care. Renovate can detect multiple package manifests in one repository, but without rules scoping which paths it watches and how updates group, a large monorepo generates an unmanageable PR volume. Budget configuration time proportional to repository complexity.

A configuration worth starting from

A sane first renovate.json restricts rather than opens. Limit concurrent PRs so the bot cannot open thirty at once, schedule updates for a weekday morning, group development dependencies into a single PR, and enable auto-merge only for patch-level dev dependency updates where CI is trusted.

From there, loosen. Adding minor production dependencies after a few weeks of watching the bot behave is a smaller risk than starting permissive and trying to regain control once reviewers have stopped reading the PRs.

Dashboards and visibility

Renovate can maintain a dependency dashboard issue listing everything it would update, including items held back by configuration. That issue is more useful than it first appears: it is the honest inventory of how far behind a repository actually is, separate from the PRs currently open. Teams that keep PR volume low with aggressive scheduling need it, otherwise the backlog becomes invisible.

Similarly, rangeStrategy deserves a deliberate choice. Bumping declared ranges versus pinning exact versions produces very different lockfile churn, and the right answer differs between an application and a published library.