Dependabot vs Renovate: A Technical Comparison

Quick verdict: Dependabot is a GitHub-hosted service you configure with a short YAML file. Renovate is an open-source job you can run anywhere, with more than 200 documented configuration options and native support for GitLab, Bitbucket, Azure DevOps, and Gitea. GitHub-only teams that want updates running the same afternoon tend to prefer Dependabot. Monorepos, non-GitHub platforms, and version strings outside manifest files push teams to Renovate. Both are free, but Renovate's free hosted tier allows one concurrent job on a four-hour cycle.

Most of what ranks for this comparison is out of date. Dependabot shipped grouped updates in August 2023, minimum package age in July 2025, and a default three-day cooldown in July 2026. Renovate renamed enough configuration options that copy-pasting a two-year-old renovate.json snippet now produces invalid config.

This page is written against both tools as they stand in August 2026, with the ship date attached to anything that changed recently.

What Dependabot and Renovate actually are

Both tools do the same job: watch your manifests, notice when a dependency is behind or vulnerable, and open a pull request. They arrived at that job from opposite directions.

Dependabot

Dependabot started as an independent service and was acquired by GitHub in 2019. GitHub rebuilt it into the platform in 2021, and that rebuild is worth knowing about because it removed native automerge, telling users to "use third-party solutions" instead. Nearly every complaint about Dependabot automerge traces back to that decision.

It is three separate things that people tend to talk about as one:

Dependabot Alerts notify you when the GitHub Advisory Database flags a dependency in your dependency graph. Alerting only, no PRs.

Dependabot Security Updates open a PR when an advisory fires, targeting the minimum version that resolves it.

Dependabot Version Updates open PRs on a schedule to keep dependencies current, vulnerability or not.

The split matters operationally. Alerts and security updates turn on at the repository or organization level with no config file. Version updates need a dependabot.yml committed to the repo. GitHub's organization-level security configurations cover alerts and security updates but still omit version updates, so update policy remains per-repository YAML in August 2026.

Renovate

Renovate was created by Rhys Arkins as an independent open-source project. The repository dates to December 2016 and the first npm release, renovate@1.0.4, went out on 11 January 2017. WhiteSource acquired it on 13 November 2019, and WhiteSource renamed itself Mend in May 2022. Renovate was not built by Mend, which is worth stating because the independent-origin history explains the tool's configuration philosophy.

The self-hosted code is AGPL-3.0-only. Mend's naming has churned, and practitioner posts use the old names heavily. As of August 2026:

• Mend Renovate CLI is the open-source project (npm, Docker, GitHub Action, GitLab pipeline)
• Mend Renovate Community Cloud and Community (OSS) Cloud are the free hosted apps
• Mend Renovate Enterprise Cloud and Enterprise Self-hosted are the paid products

"Renovate Pro" and "Mend Renovate Server" are both retired names for what is now Enterprise Self-hosted.

The philosophical split

Dependabot optimizes for teams who want dependency updates running by the end of the afternoon. Renovate optimizes for teams who want to express a policy once and apply it across 400 repositories.

That tension defines the decision, and it cuts both ways. Renovate's configuration surface is the reason platform teams pick it and the reason small teams bounce off it.

How each tool works

Dependabot's model

Dependabot matches advisories from the GitHub Advisory Database against the dependency graph GitHub already builds from your manifests and lock files. Security updates and version updates then run as jobs on GitHub-hosted infrastructure.

It does not run your package manager the way you would locally. For Maven, GitHub's docs state plainly that "Dependabot doesn't run Maven." For Gradle, it invokes Gradle only for the wrapper. This keeps update jobs fast and predictable, and it is the reason transitive dependency handling is uneven across ecosystems. For non-npm ecosystems, Dependabot cannot fix a transitive vulnerability when the parent package also needs updating.

Configuration is a single dependabot.yml with one block per ecosystem and directory. The plural directories key has been generally available since June 2024, which resolved most of the monorepo config repetition people still complain about. Every widely-cited dependabot-core issue on that topic is now closed.

Renovate's model

Renovate runs as a job, either on Mend's hosted infrastructure or on yours. Each run clones the repo, extracts dependencies through one of its 100+ manager modules, looks up versions, and writes branches.

Configuration layers in four passes: built-in defaults, then inherited presets, then repository config, then packageRules. That layering is what makes org-wide policy practical. You publish one preset repository, every other repo extends it, and changing the preset changes 400 repos at once.

The layering is also where teams get hurt. packageRules merge per-option rather than last-wins or deep-merge, and that behavior has generated years of confusion threads. renovatebot/renovate carries 11,749 discussions against 960 open issues, and a dedicated config-help repository accumulated 885 issues before being archived. The expressiveness is real and so is the support burden it creates.

One default worth knowing: dependencyDashboard is false in the raw defaults. It is on because config:recommended enables it, not because the base config does.

What Renovate can express that Dependabot cannot

This is the concrete part of the configurability argument, verified against the current dependabot.yml reference rather than old commentary:

• No automerge key exists in dependabot.yml at all
• No custom managers. Dependabot cannot be pointed at an arbitrary file with a regex
• No post-update commands. Nothing equivalent to postUpgradeTasks
• No extends. No preset inheritance, so policy is copied per repository
• No cron. Schedules pick from fixed intervals rather than expressions
• 6 matching dimensions in groups against 19 in Renovate's packageRules
• A single target-branch per ecosystem block

None of these is fatal on its own. Together they explain why teams past a certain repository count migrate.

Ecosystem and package manager coverage

Renovate ships over 100 manager modules. Dependabot supports 38 named managers across 33 package-ecosystem values. The gap is real but smaller than the raw numbers suggest, because Renovate splits ecosystems into more granular managers than Dependabot does.

Second tier, briefly. Terraform and Helm both work in both tools, with Dependabot's helm-registry notably not supporting OCI. Composer, Bundler, Swift PM and pub are supported by both, with Dependabot supporting Bundler vendoring and restricting Swift to git registries.

Two corrections to claims that circulate widely. Dependabot does update Kubernetes manifests and Helm charts, so "Dependabot can't do Kubernetes" is wrong. And six ecosystems shipped between February 2025 and June 2026 (Docker Compose, Conda, pre-commit, Nix, sbt, Deno), which invalidates most pre-2025 gap lists.

Custom managers

Renovate's customManagers (with customType, which replaced the old "regex manager" concept) point a regex at any file and extract a version string. Dockerfiles with pinned tool versions, CI configs, Terraform modules, Kubernetes manifests. If a version number lives in a file, Renovate can update it.

Dependabot has no user-definable equivalent. Issue #1290 was closed in July 2020 with "we don't expect to have the bandwidth." It does ship hard-coded updaters for specific non-manifest files (pre-commit rev:, rust-toolchain, vcpkg baselines, flake.lock, devcontainer Features), so the honest framing is that Dependabot covers the common cases GitHub chose and Renovate lets you cover yours.

Docker digest pinning deserves a note. Renovate's pinDigests is documented and stable. Dependabot merged a digest pinning PR in February 2026 behind an experiment flag, with no documentation and no changelog entry. Treat it as unconfirmed rather than absent.

PR behavior, noise, and update intelligence

Nobody has measured PR volume

Every number circulating about how many PRs each tool opens per week is unsourced. The "3 to 5x reduction" figure traces to vendor content. Three academic studies were checked while researching this page and none measures it.

The mechanism is worth explaining even without a number. Both tools size their output by how many advisories and releases match your manifest ranges. Grouping, schedules and cooldowns change when and how the queue arrives. They do not change what is in it.

Open PR limits

Dependabot defaults to five open version-update PRs per ecosystem. Security PRs have a separate limit of 10 and do not count against the version limit. When the limit is reached, Dependabot defers: "no further PRs are raised until some are merged or closed." Nothing is silently dropped, which contradicts a common criticism.

Renovate defaults to prConcurrentLimit: 10 and prHourlyLimit: 2. On defaults it opens two PRs an hour, so the "Renovate floods you with hundreds of PRs" claim is also wrong unless someone raised the limits.

Cooldown, and the fact that flipped

This is the single most out-of-date claim in every comparison currently ranking.

Renovate's minimumReleaseAge (formerly stabilityDays) waits N days after a release before proposing it, which reduces exposure to yanked or compromised versions. It has always been the standard example of Renovate doing something Dependabot could not.

Dependabot shipped cooldown on 1 July 2025. On 14 July 2026 it became the default at three days, with no configuration required. Security updates are exempt, so critical fixes are not delayed. It reaches GitHub Enterprise Server in 3.23.

Renovate's minimumReleaseAge still defaults to null. On out-of-the-box behavior, Dependabot is now the more conservative of the two. Renovate's remaining advantage is granularity: you can set a different release age per packageRule, where Dependabot's cooldown is per-ecosystem.

Automerge

Dependabot has no automerge key. The documented path is GitHub's repository-level auto-merge combined with the dependabot/fetch-metadata action and gh pr merge --auto in a workflow. dependabot-core issue #1973 has been open since June 2020 with 105 thumbs-up and activity through March 2026.

That workflow works, and plenty of teams run it. It is a different operational shape from Renovate's automerge, where conditions live in the same config as everything else and you can automerge patch updates for one package group while requiring review for another. With Dependabot you are writing and maintaining a GitHub Actions workflow, which also means handling the pull_request_target security considerations that come with reading metadata from fork PRs.

Merge Confidence

Renovate's Merge Confidence badges show adoption and test-pass signals from Mend's data. The gating is three layers deep and usually described wrong:

• Badges are free everywhere and on by default via config:recommended
• packageRules.matchConfidence, which lets you automerge based on confidence, requires a paid Mend API key
• Merge Confidence Workflows require Community (OSS) Cloud or Enterprise Cloud

So the free Community tier gets display, not decisioning. Dependabot's nearest analogue is its compatibility score, which one independent study measured as unavailable for 83% of updates.

Security update context

Dependabot surfaces advisories in the GitHub security tab with CVSS, affected ranges and advisory links, and its security PRs target the minimum version that resolves the advisory.

Renovate's vulnerabilityAlerts carries supportedPlatforms: ['github'] and is fed by GitHub's own Dependabot alert feed. Off GitHub, Renovate falls back to osvVulnerabilityAlerts, which defaults to false, is flagged experimental, covers direct dependencies only, and spans 10 datasources. Its vulnerabilityFixStrategy accepts lowest or highest and defaults to lowest, so minimum-patch remediation is not a Dependabot differentiator either.

Configuration depth

The mechanics are above. What matters here is what the depth difference costs in both directions.

The same policy, written both ways

Take one common request: group npm patch updates, run them weekly, automerge them. Here is how far each config gets.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5
    groups:
      npm-patch:
        patterns:
          - "*"
        update-types:
          - "patch"
    # automerge: no equivalent key exists

{
  "extends": ["config:recommended"],
  "packageRules": [
    {
      "matchManagers": ["npm"],
      "matchUpdateTypes": ["patch"],
      "groupName": "npm patch",
      "schedule": ["* * * * 1"],
      "automerge": true
    }
  ]
}

The Dependabot file does everything except the last word of the request. Grouping and scheduling are fine. Automerge has no key, so you enable auto-merge on the repository and add a workflow:

# .github/workflows/dependabot-automerge.yml
      - uses: dependabot/fetch-metadata@v2
        id: meta
      - if: steps.meta.outputs.update-type == 'version-update:semver-patch'
        run: gh pr merge --auto --squash "$PR_URL"

That is the whole configurability argument in one scenario. Dependabot gets there, but half the policy ends up in YAML and half in a workflow you own, test and keep working.

What only Renovate can express

Shared presets are the capability platform teams cite most. One preset repository, extends in every other repo, and dependency policy for the whole organization changes in one commit. Dependabot's per-repo model is why tools like github/evergreen exist to bulk-push dependabot.yml files across an organization.

Beyond that: cron scheduling with timezone support, branch and commit message templating, postUpgradeTasks for regenerating lock files or running formatters after an update, and customManagers for arbitrary files.

What Dependabot users still ask for

Checked against the GitHub changelog, because several long-standing requests have shipped. These remain open, with reaction counts as of August 2026:

• Manual per-dependency trigger (217 reactions)
• Config validation before merge (138)
• Multiple schedule and update-type combinations (136)
• PR body templates (82)

Two things people still list as gaps have shipped and should not be cited: branch name customization landed on 4 August 2026, closing an issue open since 2018, and organization-wide private registries shipped in April 2026 even though the tracking issue remains open.

One capability moved backwards. reviewers was retired from dependabot.yml on 27 May 2025, in favor of CODEOWNERS. CODEOWNERS cannot express "these reviewers, but only for bot PRs," so that is a real loss for teams who used it.

The other direction

Renovate's complexity is not just a talking point, and the evidence is structural rather than anecdotal. The discussions-to-issues ratio on the repository, the archived config-help repo with 885 issues, and maintainer clarifications about packageRules merging spread across eight-plus threads from 2021 to 2025 all point the same way.

There is a subtler cost. Renovate's option names have churned: stabilityDays, matchPackagePatterns, baseBranches, fileMatch and regexManagers are all gone. Most Renovate config snippets published on the web are now syntactically invalid, so the tutorial you find is likely to fail before you learn why.

Onboarding itself is one line. config:recommended plus the automatic onboarding PR gets you running. The complexity arrives at the tuning stage, not day one.

Platform support, workflow, and scale

Where each one runs

Dependabot as a managed service is GitHub only, including GitHub Enterprise Server and Cloud.

The engine is a different story. dependabot-core has been MIT licensed since May 2024, and its README documents opening PRs against GitHub, GitHub Enterprise, Azure DevOps, GitLab, Bitbucket and AWS CodeCommit. Community projects wrap it for GitLab. "Dependabot is GitHub only" is true of the product, not the code.

Renovate supports GitHub, GitLab, Bitbucket Cloud and Data Center, Azure DevOps, Gitea, Forgejo, Gerrit and others. The feature gaps are documented in Renovate's own FAQ and there are two that matter:

The Dependency Dashboard is unsupported on Azure, Bitbucket, Bitbucket Server, Gerrit and SCM-Manager. Since the dashboard is the primary workflow surface for most Renovate teams, this is a bigger deal than it sounds.

The Mend hosted app supports GitHub and Bitbucket Cloud only. GitLab, Azure DevOps, Gitea, Forgejo, Bitbucket Server and SCM-Manager teams must self-host. For a GitLab team evaluating Renovate, that deployment fact matters more than any feature comparison, because it turns a hosted app into infrastructure you run.

Free tier limits

Mend's hosted Renovate is free for unlimited public and private repositories. The constraint is compute, not repository count:

One concurrent job on a four-hour cycle with a thirty-minute timeout is the real ceiling on the free tier. Mend does not document what happens when the concurrency limit is hit, and practitioners have not established it either.

At scale

Self-hosted Renovate scales, with work. A team running 500+ GitLab repositories hit GitLab's one-hour CI timeout in a single job, tried parallel matrix jobs and hit GitLab's 200-job cap, then batched repositories into groups of five and got the pipeline to roughly 15 minutes. Another running 12,000 repositories on self-hosted GitLab went from over 24 hours to about four using dynamic child pipelines. Renovate Community Edition has been reported breaking around 6,800 repositories with a SQLite variable-limit error.

There is no comparable published account of Dependabot at scale, because Dependabot's execution is GitHub's problem. There is no pipeline for anyone to tune or write about.

Security and supply chain

Vulnerability data

Both tools converge on GHSA when running on GitHub. Dependabot uses the GitHub Advisory Database directly. Renovate's vulnerabilityAlerts reads GitHub's Dependabot alert feed, so on GitHub the underlying data is the same. Off GitHub, Renovate's coverage narrows to OSV, direct dependencies only.

For malicious packages, Dependabot shipped GA malware alerts across eight ecosystems on 28 July 2026. Renovate's equivalent is experimental and off by default.

Transitive dependencies

Neither tool is good at this, and Renovate's maintainer says so directly. In January 2025, rarkins wrote that "Renovate is not the right tool for transitive vulnerabilities." The transitiveRemediation option no longer exists. A discussion accepting the feature was opened in April 2026 and remains unimplemented.

Dependabot's npm path can update a direct dependency to pull in a fixed transitive. For non-npm ecosystems it cannot when the parent also needs updating.

Both tools execute untrusted code

This gets framed as a Renovate problem. It is a property of the category.

Renovate's postUpgradeTasks runs arbitrary commands after an update, and lock file regeneration runs package manager lifecycle scripts. postUpgradeTasks is self-hosted only and gated by an allowedCommands allowlist that a self-hosted admin must populate, so the hosted app does not expose it. Compass Security published research on exploiting Renovate in 2025, and six command-injection advisories have been filed against it.

Dependabot's insecure-external-code-execution setting governs the same class of behavior, defaulting to deny for ecosystems where running install scripts is optional. Its jobs run in GitHub-managed containers.

The underlying problem is identical. To compute an update, you sometimes have to run code from the thing you are updating.

The compounding factor is automerge. A compromised release can be proposed within minutes of publication and merged before anyone looks at it, which is the scenario GitHub cited when it explained why Dependabot now waits three days by default. It implicates both tools equally, and it is the strongest argument for setting minimumReleaseAge on the Renovate side rather than leaving it at null.

Cost, criticisms, and when to pick which

What each actually costs

Dependabot is free. Alerts, security updates, version updates and the dependency graph are free on private repositories across all GitHub plans, and GitHub does not bill for Dependabot's own update jobs on standard runners.

The paid boundary is governance, not the tool. Dependency review, the security overview including its Dependabot view, and custom auto-triage rules require GitHub Code Security at $30 per committer per month, following the Advanced Security SKU split in April 2025. GitHub-curated auto-triage presets are free; writing your own is not.

Renovate self-hosted is free under AGPL-3.0-only, with the operating cost of running it. Mend's hosted free tiers are covered above.

The real cost difference is CI minutes. Every PR triggers a pipeline, automerge triggers another, and auto-rebasing triggers more. A Renovate discussion documents 10 automergeable PRs producing 10 pipeline runs where 8 were redundant. GitHub's hosted Linux 2-core rate is $0.006 per minute as of January 2026, and self-hosted runners in private repositories now carry a $0.002 per minute platform charge as of March 2026.

Nobody has published a measured comparison of grouped versus ungrouped CI spend. The line item is real even though no public number exists to size it.

Is Dependabot still maintained?

This comes up constantly on Hacker News and the answer is yes. Look at what shipped: minimum package age (July 2025), six new ecosystems including Nix, Deno, Conda and sbt (February 2025 to June 2026), GA malware alerts (July 2026), a default three-day cooldown (July 2026), and pull-request-branch-name customization (August 2026), which closed a request open since 2018.

The limit both tools share

Neither tool evaluates whether a vulnerable dependency is reachable in your code.

GitHub is explicit that this was a design decision. Its auto-triage rules match on severity, EPSS, dependency scope, package name, CVE ID, ecosystem and manifest location, and GitHub says it deliberately did not index on reachability, preferring "a rich set of complex, contextual alert metadata." Its npm devDependency auto-dismissal is scope-based, dismissing alerts with "limited effects, such as long-running builds or tests." That is a heuristic about where a package sits, not about whether your code calls it.

Renovate is the same. Across its entire configuration reference, vulnerabilityAlerts and osvVulnerabilityAlerts are the only vulnerability-aware options, and there is no reachability or call-graph option at all.

Filippo Valsorda documented what this looks like in practice in February 2026. After he published a security fix for filippo.io/edwards25519, Wycheproof was flagged despite importing only the unaffected filippo.io/edwards25519/field subpackage. He replaced Dependabot with govulncheck, which does symbol-level filtering.

The published research points the same direction, with caveats worth stating. An ASE 2022 study of 100 JavaScript projects found 59% of declared runtime dependencies were not used in production. Zapata et al. at ICSME 2018 found "up to 73.3%" of outdated clients were safe from the vulnerability they had inherited, from manual inspection of 60 client projects across three cases. Both are npm-centric and neither is a general reachability rate. The direction is consistent even if the magnitude is not settled.

Konvu's own measurements land in the same place. Forking Metabase and enabling Dependabot produced 53 alerts, 26 of them high severity, and zero that survived exploitability analysis: the vulnerable code was unreachable, blocked by configuration, or missing the attacker-controlled input the exploit needs. Across Konvu's repositories, Dependabot opened 44 CVE alerts in Q4 2025 and 182 in Q1 2026, a 314% jump in one quarter. Three of those 182 were exploitable. Those are alert counts rather than PR counts, and a single team's repositories are not a benchmark, but they show what the advisory-driven model produces once volume picks up.

Choosing

Small team on GitHub. Dependabot. Alerts and security updates turn on with a checkbox, and the three-day cooldown now protects you by default. Renovate's config:recommended is close behind, but you are taking on a much larger configuration surface to save writing config you were not going to write anyway.

Platform team, 100+ repositories. Renovate. Shared presets are the reason, and it is not close. Copying dependabot.yml across 200 repositories and keeping them consistent is the problem extends solves.

Not on GitHub. Renovate, but check the deployment path first. If you are on GitLab or Azure DevOps, the Mend hosted app does not support you and you are self-hosting. On Azure, Bitbucket Server and Gerrit you also lose the Dependency Dashboard.

Complex monorepos. Renovate, mainly for customManagers and per-package-group rules. Dependabot's directories key closed most of the config repetition gap, so this is narrower than it was two years ago.

Aggressive automation. Renovate. Automerge conditions live in the same config as everything else rather than in a GitHub Actions workflow you maintain.

Air-gapped or regulated. Dependabot on GHES works but needs GitHub Connect for advisory data, self-hosted runners for updates, and is unsupported on clustered enterprises. Air-gapped mode means preloading the dependabot-updater and dependabot-proxy images and redoing that on every minor upgrade. Self-hosted Renovate is the more tractable option when nothing can call home.

Running both

The common pattern is Dependabot alerts plus Renovate version updates. Two mechanics people get wrong:

Setting open-pull-requests-limit: 0 does not stop Dependabot security PRs, because security PRs are exempt from that limit. The lever is the repository Settings toggle for security updates.

And you must leave Dependabot alerts enabled, because Renovate's vulnerabilityAlerts is fed by that alert feed on GitHub. Turning alerts off to quiet Dependabot also blinds Renovate.

When both tools own the same ecosystems, they open duplicate PRs. That is a real and current problem, with 2026 examples across several public repositories.

One migration note: Renovate does not read or convert an existing dependabot.yml. Issue #21081 has been open since March 2023 with no linked PRs. No config translation tooling exists in either direction.

Bottom line

Dependabot is a good default that got materially better in 2025 and 2026 while its reputation stood still. Renovate is more capable and asks more of you, and its free hosted tier has a compute ceiling nobody mentions.

Pick Dependabot if you are on GitHub and want this working today. Pick Renovate if you manage enough repositories that policy inheritance matters, or you are not on GitHub, or you need to update version strings that do not live in a manifest.

What neither tool decides is which of the resulting PRs matters. Both size their queue by advisories matching a version range, so the volume tracks the advisory feed rather than your risk. Cooldowns, grouping and schedules change when the queue arrives, not what is in it. The judgment call about which handful of findings to open first is still yours.

If that triage step is where your team is losing time, that's the problem Konvu solves.

Related comparisons

• SCA vs SAST: What dependency scanning catches that source code analysis cannot, and why 77-90% of your codebase is third-party.
• Snyk vs Semgrep: The commercial step up from free update bots, with independent benchmark data and real pricing.
• Checkmarx vs Black Duck: Enterprise SCA depth, license compliance and SBOM reporting beyond what an update bot provides.