If your team is on GitHub, has fewer than a handful of repos, and mostly wants security patches to show up without anyone configuring anything, Dependabot is enough and you should turn it on today. If you have more than a few repos, want updates grouped and automerged on a schedule you control, or host code anywhere other than GitHub, Renovate is the one that pays for its longer config file within the first month. The failure mode that pushes teams from the first to the second is always the same: a wall of forty single-dependency pull requests and a CI bill that doubled.
What does the PR flood actually look like?
The pattern is predictable. Someone enables Dependabot with the default config on a Node or Python service, and Monday morning brings one pull request per dependency: Bump @types/node from 22.14.0 to 22.15.1, Bump eslint from 9.24.0 to 9.25.0, and so on down the page. Each PR triggers the full CI pipeline. Each one also rebases when another one merges, so it triggers CI again. Then the second wave hits: the PRs started failing, not because the dependency broke anything, but because the workflow reads a secret.
That last one is the error that trips up nearly everyone. A pull_request workflow triggered by Dependabot runs with a read-only GITHUB_TOKEN and does not receive your repository secrets. The job logs show something like:
Error: Input required and not supplied: aws-access-key-id
or a test suite that hangs on a database URL that resolved to an empty string. Nothing is wrong with the dependency. The fix is either to store the secrets a second time as Dependabot secrets (Settings → Secrets → Dependabot) or to skip the secret-dependent steps when github.actor == 'dependabot[bot]'. Until you know that, every Dependabot PR is red, and a red PR is one nobody merges. The flood becomes a backlog.
The quotable version: the volume of dependency PRs is a configuration problem, but the red checks on them are a permissions problem, and the second one is the one that makes teams give up.
How does Dependabot handle grouping and automerge?
Dependabot has supported grouped updates for a while now (as of mid-2026 it is a stable, documented feature), and the config is short. This is the setup that turned forty PRs into three on a service I maintain:
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
day: "monday"
open-pull-requests-limit: 5
groups:
dev-dependencies:
dependency-type: "development"
update-types: ["minor", "patch"]
production-minor:
dependency-type: "production"
update-types: ["minor", "patch"]
ignore:
- dependency-name: "typescript"
update-types: ["version-update:semver-major"]
Majors stay as individual PRs, which is what you want; a major bump deserves its own review. Minors and patches arrive as one PR per group.
What Dependabot does not do is merge anything for you. Automerge is not a config option. You build it yourself with a workflow that inspects the PR and calls gh pr merge --auto:
# .github/workflows/dependabot-automerge.yml
name: Dependabot automerge
on: pull_request
permissions:
contents: write
pull-requests: write
jobs:
automerge:
if: github.actor == 'dependabot[bot]'
runs-on: ubuntu-latest
steps:
- uses: dependabot/fetch-metadata@v2
id: meta
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
- if: steps.meta.outputs.update-type != 'version-update:semver-major'
run: gh pr merge --auto --squash "$PR_URL"
env:
PR_URL: ${{ github.event.pull_request.html_url }}
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
That works, but notice what you own now: a workflow per repo, branch protection rules that require the checks you care about (otherwise --auto merges a PR whose tests never ran), and a rule that the automerge job itself can't be one of the required checks. It is not hard. It is just yours to maintain, in every repository, forever.
Dependabot's real strengths are that it is already there, it is free, it drives the security alerts you see in the repository's Security tab, and it needs zero infrastructure. Its real limitations are that it only exists inside GitHub, grouping is per-ecosystem-per-directory rather than global, there is no shared config across repos, and there is no lock file maintenance (refreshing transitive dependencies when nothing in your manifest changed).
Takeaway: Dependabot solves the volume problem with a ten-line groups block, but it hands the merge problem back to you as a workflow you write per repo.
How does Renovate handle the same problem?
Renovate is open source (maintained by Mend) and runs either as the hosted GitHub App or as a container you schedule yourself in CI. The point of it is that grouping, scheduling, and automerge are all first-class config, and the config is a preset you can extend from a central repo.
The equivalent of the Dependabot setup above, plus automerge, plus lock file refresh, is one file:
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["config:recommended"],
"schedule": ["before 6am on monday"],
"prConcurrentLimit": 5,
"lockFileMaintenance": { "enabled": true, "schedule": ["before 6am on monday"] },
"packageRules": [
{
"matchUpdateTypes": ["minor", "patch"],
"matchDepTypes": ["devDependencies"],
"groupName": "dev dependencies (non-major)",
"automerge": true
},
{
"matchUpdateTypes": ["patch"],
"matchDepTypes": ["dependencies"],
"groupName": "production patches",
"automerge": true
},
{
"matchUpdateTypes": ["major"],
"dependencyDashboardApproval": true
}
]
}
Three things in there have no Dependabot equivalent. lockFileMaintenance opens a PR that regenerates the lock file so transitive updates don't pile up silently. dependencyDashboardApproval means major bumps don't even become PRs until you tick a checkbox in the Dependency Dashboard issue, which is the single most effective anti-flood control I have used. And automerge: true respects your branch protection and required checks without a workflow file; Renovate waits for green and merges.
The limitations are real, though. The config surface is large, and when Renovate silently skips a dependency, working out which rule or preset caused it means reading the job log on the Mend dashboard or running it locally with LOG_LEVEL=debug. Version-range handling (rangeStrategy) has opinions that surprise people who pin everything. The hosted app runs on Mend's schedule, not yours, so "before 6am" is a window, not a guarantee. And self-hosting means owning a scheduled job with a token that can push to every repo, which is a credential you now have to rotate and scope carefully.
If you want grouped, scheduled, automerged updates across many repos without writing a workflow in each one, Renovate is the one that turns dependency hygiene into a single shared preset rather than per-repo YAML.
Dependabot vs Renovate: the decision table
| Question | Dependabot | Renovate |
|---|---|---|
| Setup effort | Minimal; one YAML in the repo | One JSON in the repo, plus app install or self-hosted runner |
| Platforms | GitHub only | GitHub, GitLab, Bitbucket, Azure DevOps, Gitea/Forgejo |
| Grouping | Per ecosystem and directory | Any rule combination, across ecosystems |
| Automerge | Build it yourself with Actions | Native, respects required checks |
| Lock file maintenance | No | Yes |
| Shared config across repos | No | Yes, via extends presets |
| Major-version gating |
ignore rules only |
Dashboard approval checkbox |
| Security alerts integration | Native to GitHub Security tab | Vulnerability alerts supported, but GitHub's alerts stay Dependabot's |
| Debugging "why was this skipped?" | Limited logs | Verbose logs, steep at first |
| Cost | Free, uses your Actions minutes for CI | Free (hosted app or self-hosted); CI minutes still yours |
One thing the table hides: both tools cost you CI minutes per PR, so grouping is a cost control as much as a sanity control. Five grouped PRs a week run the pipeline five times; forty singles run it forty times, then again on every rebase.
When is running both the right answer?
More often than you'd think. Dependabot security updates (the alert-driven ones, not the version updates) are worth leaving on even if Renovate handles everything else, because they are wired into GitHub's advisory database and show up in the Security tab where auditors and compliance tooling look. The trick is to disable Dependabot version updates by deleting dependabot.yml while keeping "Dependabot security updates" enabled in repository settings, so the two don't open duplicate PRs for the same bump. If you leave both fully on, you will get two PRs for every patch, which is a flood with extra steps.
Takeaway: keep Dependabot for the security-alert PRs GitHub already knows how to surface, and let Renovate own everything scheduled.
FAQ
Why do Dependabot PRs fail CI when the same code passes on my branch?
Workflows triggered by Dependabot run with a read-only token and no access to repository secrets. Add the secrets again under Dependabot secrets, or skip secret-dependent steps when the actor is dependabot[bot].
Can Dependabot automerge pull requests?
Not by itself. You need a GitHub Actions workflow that checks the update type with dependabot/fetch-metadata and enables auto-merge with gh pr merge --auto, plus branch protection that requires your test checks.
Is Renovate free to use?
The Renovate CLI is open source and free to self-host, and as of mid-2026 Mend offers a hosted GitHub App at no charge for standard use; check the current terms before relying on it for a large private org.
Bottom line
A solo developer or small team on GitHub with a few repos should enable Dependabot with a groups block today and not think about it again until majors pile up. A team with more than five or six repos, any monorepo, or code on GitLab or Azure DevOps should adopt Renovate, put the config in a shared preset repo, and gate majors behind the dashboard. Either way, the first thing to fix is the secrets-on-bot-PRs problem, because no grouping strategy helps when every PR is red. And whichever you pick, grouping is the setting that decides your CI bill.
Top comments (0)