Dependabot vs Renovate: Seven Rounds on Setup, PR Noise, Security and Automerge

Round 1

Setup

Dependabot is built in to GitHub. Commit .github/dependabot.yml and it runs. Renovate needs an app install or self-hosting, then opens a "Configure Renovate" pull request for you to merge. That is a small step, but it is one more vendor to approve.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

Dependabot takes the round

Round 2

Pull request noise

This is the round that decides most switches. By default Dependabot opens one pull request per dependency, up to five open version updates at a time, unless you write your own groups. Renovate groups common dependencies out of the box through community presets, and allows 10 open and 2 new per hour by default.

Renovate also keeps a Dependency Dashboard: one issue listing every pending update, with an optional approval flow. Dependabot has no single issue like it.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"]
}

Renovate takes the round

Round 3

Scheduling

Dependabot takes a fixed interval, from daily to yearly, or a cron schedule per updates entry. Renovate sets schedules per dependency, per manager or globally, so you can hold one risky package to weekends and leave the rest alone.

One catch: a Renovate schedule is a window, not an alarm. On the hosted app Mend controls when the process starts, usually hourly, and a repo config cannot force an exact time.

Renovate, narrowly

Round 4

Reach

The docs list about 120 Renovate managers against 34 Dependabot ecosystem values. The units differ, because Renovate splits things Dependabot keeps under one value, so read that as a direction, not a ratio.

Platforms are the clearer gap. Renovate's platform list includes Azure DevOps, Bitbucket, Forgejo, Gitea, GitHub and GitLab. The official Dependabot is built for GitHub. On GitLab or Gitea, the fight is over before it starts.

Renovate takes the round

Round 5

Security fixes

Turn on Dependabot security updates and it tries to open a pull request for every open alert with an available patch, with no config file needed.

Renovate does raise security pull requests and lets them skip its limits and schedule. But on GitHub it reads those same alerts, so you must enable the dependency graph and Dependabot alerts first. Dependabot is in the corner of its opponent here.

Dependabot takes the round

Round 6

Waiting out bad releases

A fresh release may be a malicious one, so both bots can hold it back. Dependabot applies a default 3-day cooldown to version updates, and never to security updates. You can tune it by major, minor and patch on package managers that use semantic versioning.

Renovate calls this minimumReleaseAge and applies it per version. Its config:best-practices preset adds a three-day wait for npm. Dependabot has the safer default, Renovate the finer control.

Draw

Round 7

Automerge

Renovate has automerge built in: it waits for required tests, then merges. It is not instant. It merges one branch per target branch per run, and its docs suggest giving it about two hours.

Dependabot has no automerge setting of its own. GitHub's docs point to repository auto-merge or a GitHub Actions workflow that reads the update metadata and calls gh pr merge --auto. It works, but you now own those rules, so keep it to patch updates of dev dependencies until your tests have earned more.

Renovate takes the round

The judges' scorecard

Which corner is yours

Do not run both for version updates. GitHub says to disable an existing dependency integration before enabling Dependabot. You can keep Dependabot alerts on while Renovate does the updates.

Licensing rarely decides this: Renovate is AGPL and Dependabot core is MIT, and the Renovate docs note neither matters if you consume them as an app.

Common questions