Renovate vs Dependabot in 2026: 119 Managers vs 34, Both Wait 3 Days

I have run both bots on the same kind of repository, and the honest summary of Renovate vs Dependabot used to be short: Dependabot was the one you already had, Renovate was the one you switched to when the pull requests got too noisy. In 2026 that summary is out of date. Dependabot learned to group updates, to group across ecosystems, and as of July to wait three days before proposing a new release. Renovate kept adding managers and made its own release-age gate stricter by default. This post compares the two on the things that decide day-to-day pain (coverage, grouping, auto-merge, security updates, hosting) and on the newer question of whether a bot that auto-updates dependencies is a supply-chain risk in its own right.

What Renovate and Dependabot actually are in 2026

Both are bots that read your manifests and lock files, look up newer versions in registries, and open pull requests that bump them. The differences are in where they run and how much they let you configure.

Dependabot is built into GitHub. Version updates are configured in .github/dependabot.yml, security updates are toggled in repository settings and fed by Dependabot alerts, and the engine is the MIT-licensed dependabot-core (v0.404.0 at the time of writing). It runs on GitHub's infrastructure, and it only works on GitHub.

Renovate is an AGPL-3.0 open-source project maintained by Mend; release 44.225.1 shipped on 10 November 2026, and new patch releases land most days. You can run it three ways: the free Mend Renovate app on GitHub, Bitbucket Cloud or Azure DevOps; a self-hosted CLI or Docker image on any CI system; or the official GitHub Action. Configuration lives in renovate.json (or one of several alternative locations such as .github/renovate.json5) and can inherit from shareable presets.

That last point matters more than any feature table. Renovate's extends model means an organisation can publish one preset repository and have every repo inherit it. Dependabot has no inheritance: each repository carries its own YAML.

Renovate vs Dependabot: the feature comparison

Here is the comparison on current documentation, not on 2022 blog posts.

Area	Renovate (44.x)	Dependabot (github.com)	Source
Package managers	119 managers, plus regex and JSONata custom managers	34 package-ecosystem values	Renovate manager API, Dependabot options
Git platforms	GitHub, GitLab, Bitbucket Cloud and Server, Azure DevOps, Gitea, Forgejo, Gerrit, CodeCommit, SCM-Manager	GitHub only	Renovate platforms
Open PR limit (default)	prConcurrentLimit 10, prHourlyLimit 2	open-pull-requests-limit 5; security PRs fixed at 10	Renovate options, Dependabot options
Grouping	groupName in any packageRules match; monorepo groups in config:recommended	groups per ecosystem, group-by: dependency-name across directories, multi-ecosystem-groups	same
Release-age delay	minimumReleaseAge; config:best-practices sets 3 days for npm	3-day default cooldown since 14 July 2026	Renovate MRA, GitHub changelog
Auto-merge	Native: automerge, automergeType, platformAutomerge	None built in; use an Actions workflow with dependabot/fetch-metadata and gh pr merge --auto	Renovate automerge, GitHub docs
Overview of pending updates	Dependency Dashboard issue	Dependabot alerts and the dependency graph UI	Renovate dashboard
Shared config	Presets via extends	Per-repository file	Renovate docs
Licence	AGPL-3.0	MIT (dependabot-core)	GitHub repos

The manager count is the gap people feel first. Renovate understands things like Helm values files, Terraform providers and modules, Dockerfiles, Kubernetes manifests, Ansible Galaxy, asdf and mise tool versions, Gradle version catalogues and Bazel modules, and when it doesn't, a custom regex manager lets you teach it a pattern in a few lines. Dependabot's list has grown (Bazel, Conda, Deno, Julia, Nix flakes, OpenTofu, pre-commit, sbt and vcpkg are all there now), but if your stack includes a file format it doesn't recognise, there is no escape hatch.

Why people left Dependabot, and whether those reasons still hold

The best public evidence on this is a study of 1,823 GitHub projects and 502,752 Dependabot pull requests by He and colleagues, published in IEEE Transactions on Software Engineering. Developers were receptive: more than 70 percent of Dependabot PRs were merged, with a median merge lag of four hours. But 11.3 percent of the projects had dropped Dependabot. The reasons were notification fatigue, no grouped updates, package manager incompatibility, limited configuration and no auto-merge. Of the projects that moved to another form of automation, 86.5 percent picked Renovate.

Two of those five reasons are now mostly gone. Dependabot groups can bundle all minor and patch updates for an ecosystem into one PR, a group can apply to security updates with applies-to: security-updates, group-by: dependency-name merges the same bump across monorepo directories, and multi-ecosystem-groups can put, say, Docker and Terraform updates into a single weekly PR. Schedules now accept cron, quarterly, semiannually and yearly.

Auto-merge is the reason that still holds. Dependabot will open the PR; something else has to merge it. GitHub's documented pattern is a workflow that runs on Dependabot's PRs, reads the update type with dependabot/fetch-metadata, and calls gh pr merge --auto. That works, but it is code you own, it runs with a write token, and GitHub's own docs note that if your branch uses a merge queue the built-in GITHUB_TOKEN cannot enqueue the PR, so you need a PAT or a GitHub App token. Renovate does this natively, including merge queues, and refuses to auto-merge a branch with no status checks unless you set ignoreTests.

How do Renovate and Dependabot reduce PR noise?

Noise is the main way these bots fail. Nobody turns a dependency bot off because it is wrong; they turn it off because it opened 40 PRs on a Monday and the team learned to ignore all of them.

The Dependabot configuration that gets most of the way there is short:

# .github/dependabot.yml (github.com, November 2026)
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "06:00"
      timezone: "Europe/London"
    open-pull-requests-limit: 10
    cooldown:
      default-days: 3        # explicit, matches the new default
      semver-major-days: 14  # majors wait two weeks
    groups:
      npm-minor-patch:
        update-types: ["minor", "patch"]
        patterns: ["*"]
      npm-security:
        applies-to: security-updates
        patterns: ["*"]
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      actions:
        patterns: ["*"]

Renovate gives you more levers: schedule and a separate automergeSchedule, prHourlyLimit and prConcurrentLimit, groupName on any combination of matchers (matchUpdateTypes, matchDepTypes, matchManagers, matchPackageNames with globs or /regex/), minimumGroupSize to hold a group until several updates are ready, and dependencyDashboardApproval so that majors only get a PR when someone ticks a box. The default config:recommended preset already turns on the Dependency Dashboard and groups known monorepos (all @babel/* packages together, for example). In practice the biggest noise reduction in Renovate is auto-merge itself: when green patch updates merge without a human, the only PRs left are the ones worth reading.

There is a cost on the Renovate side too. More levers means more ways to misconfigure, and a Renovate config that extends three presets is harder to reason about than a 30-line YAML file. Renovate ships renovate-config-validator for this; my setup guide shows how to run it in CI.

Are automated dependency updates a supply-chain risk?

They can be. An update bot that proposes a release the minute it is published, combined with auto-merge, is a fast lane for whatever got published. That is not theoretical. CISA's alert of 23 September 2025 described the self-replicating Shai-Hulud worm compromising more than 500 npm packages through stolen maintainer credentials, and I covered the wider pattern in the worms learned to use your AI agent. GitHub's stated rationale for its new default is exactly this pattern: a malicious version ships, spreads, and gets caught quickly, so a short wait keeps you out of the blast radius.

Both bots now wait, by slightly different rules:

• Dependabot applies a default cooldown of three days to version updates on github.com from 14 July 2026, across every supported ecosystem, with no configuration. Security updates are exempt and open immediately. The cooldown block lets you change default-days, set per-SemVer-level days, and include or exclude up to 150 dependencies each. GitHub Enterprise Server gets the default in 3.23.
• Renovate has minimumReleaseAge. It is not on by default in config:recommended, but config:best-practices extends security:minimumReleaseAgeNpm, which waits 3 days for npm, and equivalent presets exist for PyPI and crates.io. Since Renovate 42 the default minimumReleaseAgeBehaviour is timestamp-required, so a release with no timestamp is treated as not yet old enough, and the default internalChecksFilter is strict, which means no branch at all until the age check passes. Security fixes bypass the age gate. Renovate also adds a 30-minute minimumReleaseAgeBuffer by default so that it doesn't propose a package whose companion binaries were published a few minutes later and still sit inside pnpm's own cooldown.

Neither delay is a malware scanner. It is a bet that someone else will notice first. I think it is a good bet for transitive-heavy ecosystems like npm, and it costs almost nothing, but it doesn't replace pinned lock files, an SCA scanner and the controls in what DevSecOps means in 2026.

The bot's own access is the other risk. A self-hosted Renovate needs a token with write access to contents, pull requests, issues and workflows on every repository it manages. The Mend app holds that for you. Dependabot's write path is GitHub itself, but the auto-merge workflow you add is yours, and the common mistake is triggering it on pull_request_target and then checking out PR code. The GitHub Actions security post covers why that pattern keeps getting exploited.

Mend-hosted vs self-hosted Renovate

For most GitHub teams the Mend Renovate Community Cloud is the right default. It is free for unlimited public and private repositories. The limits are what you would expect from free: one concurrent job per organisation, active repositories scheduled every four hours, a 1 vCPU and 3 GB runner, and a 30-minute job timeout. The paid Enterprise Cloud runs hourly with 16 concurrent jobs. Mend updates the hosted Renovate version manually, so it can lag a few hours to a week behind the open-source release.

The four-hour cadence interacts with auto-merge in a way that surprises people. Renovate only auto-merges one branch per target branch per run when it does the merging itself, because each merge changes the base for the rest. With the default platformAutomerge: true, GitHub's native auto-merge does the merging once checks pass, so this is less of a bottleneck, but a narrow schedule window plus four-hourly runs can still mean a day before a group lands.

Self-host when you need a platform the app doesn't cover (GitLab, Gitea, Bitbucket Server), private registries reachable only from your network, a faster cadence, or full control of the token. The official GitHub Action (v46.3.13) runs the Renovate container on a schedule, and Renovate's docs recommend a GitHub App installation token over a personal access token. Installation tokens expire after an hour, which is a feature.

Which should you choose: Renovate or Dependabot?

Pick Dependabot if you are GitHub-only, your ecosystems are in its list, and you want something that works with no extra app or token. With groups and the new cooldown, a small team with one or two languages will be fine, and security updates are wired straight into the alerts your security team already reads.

Pick Renovate if any of these is true: you are not only on GitHub; your repos contain Helm charts, Terraform modules, Dockerfiles in odd places, or tool version files Dependabot can't parse; you want one organisation-wide preset instead of 200 copies of YAML; or you want auto-merge without writing and securing a workflow. The trade is a steeper configuration curve, and an AGPL-3.0 licence that your legal team may want to read if you plan to modify Renovate and offer it to others over a network.

Running both is a reasonable middle ground that many teams land on: Dependabot alerts on for visibility, Renovate for the PRs. Renovate can read GitHub's vulnerability alerts if the app has Dependabot alerts: read, and it can also query OSV with osvVulnerabilityAlerts. Just don't let both open version-update PRs on the same files.

FAQ

Is Renovate better than Dependabot?

For coverage and control, yes: 119 managers against 34 ecosystems, any Git platform, shared presets and native auto-merge. For simplicity on GitHub, Dependabot is better, because it is already there and needs no extra app or token. The 2026 gap is smaller than older comparisons suggest, since Dependabot gained grouping and a default cooldown.

Does Dependabot support auto-merge?

Not on its own. GitHub documents a workflow that uses dependabot/fetch-metadata to read the update type and gh pr merge --auto to enable GitHub's auto-merge, which then merges when branch protection checks pass. Renovate has auto-merge built in.

What is Renovate minimumReleaseAge?

It is the number of days or hours Renovate waits after a version is published before proposing it. While the version is too new, Renovate holds the branch or marks a renovate/stability-days check as pending. config:best-practices sets it to 3 days for npm; security fixes skip it.

Is Mend Renovate free?

The Mend Renovate Community Cloud is free for unlimited public and private repositories on GitHub, Bitbucket Cloud and Azure DevOps, with one concurrent job per organisation and runs every four hours. Self-hosting the open-source CLI is also free; you pay only for the compute it runs on.

This quarter, on any repository I care about, I would move to Renovate with config:best-practices, auto-merge only non-major updates of packages past 1.0 behind required checks, and keep majors behind a dashboard approval. Where a team is GitHub-only and happy with Dependabot, I would leave it, add an explicit cooldown block so the delay is documented rather than implicit, and audit the auto-merge workflow's trigger and token. The step-by-step version of the Renovate setup is in How to Set Up Renovate With Safe Auto-Merge.

Related: GitHub Actions Security in 2026: 76 Hijacked Tags and the Fixes That Work, Vulnerability Management in 2026: 48,185 CVEs, a Triaged NVD, EPSS v5 and The Worms Learned to Use Your AI Agent: A Year of npm Supply-Chain Attacks.