Why Dependabot Is Not Enough (And What Actually Works)

Dependabot is the most widely used dependency update tool — and the most widely ignored. In February 2026, security researcher Filippo Valsorda called it a “noise machine” and recommended teams turn it off entirely. He’s right about the problem. But turning it off isn’t the answer — replacing it is.

The Dependabot promise

When GitHub acquired Dependabot in 2019 and made it free for every repository, the pitch was compelling: automated security updates, automated version updates, easy-to-review pull requests. Enable it once, and your dependencies stay current forever.

Developers expected a “set it and forget it” experience. Turn on Dependabot, merge PRs as they come in, never worry about outdated packages again. For a while, it seemed to work. Dependabot dutifully opened PRs for every new version of every dependency in your lockfile. The GitHub UI showed a reassuring green checkmark: “Dependabot is active.”

But active and effective are not the same thing. The gap between what Dependabot promises and what it delivers has become one of the most significant pain points in modern JavaScript development.

The reality — 5 problems every team faces

Problem 1 — PR noise

Dependabot opens a pull request for every single update, for every single dependency. A typical Node.js project with 50 direct dependencies and 300+ transitive ones receives 15–30 Dependabot PRs per month. Some teams report 50+ PRs per month across their repositories.

Each PR demands a review: read the diff, check CI, decide whether it’s safe to merge. Multiply that by 20 PRs per month across 5 repositories, and you have a developer spending several hours per week just triaging version bumps.

The inevitable response is PR fatigue. Teams start ignoring Dependabot PRs. The PRs pile up — 10 open, then 20, then 50. Eventually the Dependabot backlog becomes a source of guilt and anxiety rather than a useful automation. According to GitHub’s own Octoverse data, over 80% of Dependabot PRs remain unmerged after 30 days. The tool designed to keep dependencies current is generating noise that prevents developers from keeping dependencies current.

Problem 2 — broken CI on major updates

Dependabot bumps the version number in package.json and updates the lockfile. That is the entire PR. For patch and minor updates, this usually works. For major version upgrades — Express 4 to 5, React 18 to 19, ESLint 8 to 9 — the PR almost always breaks CI.

The reason is simple: major versions contain breaking changes by definition. The API has changed, imports have moved, configuration formats have been restructured. Bumping the version number without updating the code that depends on it is like buying a new engine for your car and expecting it to bolt in without modification.

Across npm ecosystem projects, 40–60% of major version PRs fail CI. The developer must read the changelog, understand the breaking changes, modify the code, and push fixes to the Dependabot branch. This manual work defeats the purpose of automation and often takes 2–4 hours per major update.

Problem 3 — no code transformation

The fundamental limitation of Dependabot is that it modifies exactly one thing: the version number. When a package renames a function, changes an import path, restructures its configuration format, or removes a deprecated API, Dependabot does nothing about it.

The PR is literally one line changed: "express": "^4.18.2" becomes "express": "^5.0.1". The 8 files in your codebase that use app.del() (renamed to app.delete() in Express 5), the 12 route definitions using deprecated wildcard syntax, and the 3 middleware configurations that changed format — Dependabot touches none of them. The developer must do all the migration work manually.

Problem 4 — one PR per package, no coordination

Modern npm packages rarely exist in isolation. A React update requires coordinated changes to react, react-dom, @types/react, @types/react-dom, and often eslint-plugin-react-hooks. Tailwind CSS updates need to coordinate with tailwindcss, @tailwindcss/forms, @tailwindcss/typography, and the PostCSS plugin.

Dependabot opens separate PRs for each package. Merging react@19 without simultaneously updating react-dom@19 produces a version mismatch that breaks your application. Merging @types/react@19 before the runtime packages results in type errors across every component file. There is no concept of atomic, coordinated updates. The developer must manually identify which PRs belong together and merge them in the correct order.

Problem 5 — no build or test verification

Dependabot opens the PR and walks away. It does not run your build. It does not run your tests. It has no idea whether the update works or breaks everything.

Yes, your CI pipeline catches failures — after the PR is created. If CI fails, the PR sits there with a red badge, joining the growing pile of failed Dependabot PRs that nobody has time to fix. According to surveys of engineering teams managing 10+ npm repositories, the average team has 12–20 open Dependabot PRs with failed CI at any given time. These are not updates. They are noise.

What Filippo Valsorda got right

In February 2026, security researcher and former Google cryptographer Filippo Valsorda published “Turn Dependabot Off,” a widely-shared blog post that argued Dependabot actively harms most teams. His core arguments:

• Dependabot creates more work than it saves for most teams. The time spent reviewing, fixing, and merging Dependabot PRs exceeds the time it would take to batch-update dependencies manually on a schedule.
• The noise makes developers ignore ALL updates, including security-critical ones. When you have 40 open Dependabot PRs, the one that fixes a critical CVE is buried alongside 39 minor version bumps.
• Auto-merge is dangerous because major version bumps can introduce subtle runtime behavior changes that tests do not catch. Silent breakage is worse than loud breakage.

Filippo correctly identified the symptoms. Dependabot’s approach — blind version bumps without code transformation or verification — is fundamentally broken. The tool automates the one step that was already easy (finding the new version number) and leaves you with the hard part (making your code work with it).

But his solution — turn it off entirely — leaves teams without automated updates at all. That means manual dependency audits on a schedule, manual changelog reading, manual code migration, and the inevitable drift toward dependency debt. A team that turns off Dependabot without replacing it is a team that will be 18 months behind within a year.

The right answer is not less automation. It is better automation.

The missing piece — actual code transformation

Think about what the ideal dependency update tool would do. Not what current tools do, but what you actually need:

1. Update the version in package.json — Dependabot does this.
2. Read the migration guide and understand the breaking changes — nobody does this automatically.
3. Fix the code — rename functions, update import paths, restructure configurations — nobody does this.
4. Run the build to verify the code compiles — nobody does this before opening a PR.
5. Run the tests to verify nothing broke — nobody does this before opening a PR.
6. Open a PR only if everything passes — nobody does this. They open the PR and hope.

Dependabot handles step 1. Steps 2 through 6 are left entirely to the developer. This is why dependency updates are the largest category of preventable engineering toil in most organizations. The version bump is 5% of the work. The transformation, verification, and validation are the other 95%.

This is exactly what ovvoc does. Every step, from version detection to verified PR, is fully automated. Ovvoc does not open a PR and hope for the best. It opens a PR that has already been built, tested, and verified in an isolated environment.

How ovvoc replaces the PR flood with tested updates

Ovvoc’s pipeline follows a strict sequence: Clone → Update → Transform → Build → Test → PR (or Report). Every update goes through every stage. No exceptions, no shortcuts.

For each of the 5 Dependabot problems, here is how ovvoc solves it:

PR noise → only signal, never noise

Ovvoc only opens a PR when the build passes and all tests pass. If an update breaks anything, you receive a failure report — not a broken PR that clutters your repository. The result: every PR ovvoc opens is ready to merge. No red CI badges, no manual fixes, no noise. Teams using ovvoc report going from 20+ open Dependabot PRs to zero unresolved dependency PRs.

Broken CI → PRs that already pass

Ovvoc runs your build and your tests inside an ephemeral container before creating the PR. If Express 5 changes your route syntax, ovvoc transforms the code first, runs the build, runs the tests, and only then opens the PR. The PR your team reviews has already been verified. CI runs confirm what ovvoc already proved.

No code transformation → 25 categories, 190+ rules

Ovvoc ships with 190+ AST transform rules across 35 packages covering all 25 categories of npm dependency updates. From simple function renames (Category 7) to complex paradigm shifts like React class-to-hooks migration (Category 14), ovvoc transforms your code at the syntax tree level — precisely, deterministically, and without touching unrelated code. For updates that require AI assistance, ovvoc uses narrowly-scoped AI with budget controls and circuit breakers. Learn more about how this works on our breaking changes page.

No coordination → atomic multi-package updates

Ovvoc uses coordination groups to update related packages atomically. React, react-dom, and @types/react update together in a single PR. Tailwind and its plugins update together. ESLint and its ecosystem update together. No version mismatches, no merge order dependencies, no manual coordination. Ovvoc ships with pre-built coordination groups for the most common package ecosystems and lets you define custom groups for your project-specific dependencies.

No verification → full build + test suite, every time

Every ovvoc job runs in an ephemeral Docker container with your project’s exact environment — correct Node.js version, correct package manager, full dependency tree. The container is destroyed after the job completes. Your code never persists on ovvoc’s infrastructure. And every update gets a full build and complete test suite run before any PR is opened. If tests fail, ovvoc attempts AI-assisted repair up to 3 times. If the fix still fails, you get a detailed failure report — never a broken PR.

Real numbers — Express 4 to 5

Here is the same update handled two different ways:

Dependabot approach: Dependabot opens a PR bumping express from 4.18.2 to 5.0.1. CI runs and fails in 3 minutes. The PR sits with a red badge. A developer eventually picks it up, spends 30 minutes reading the Express 5 migration guide, identifies 8 breaking changes across 12 files, spends 2–3 hours making the fixes, pushes the changes, waits for CI, fixes 2 more issues CI catches, pushes again. Total time: 3–4 hours of developer time spread across 1–2 days.

Ovvoc approach: Ovvoc detects the Express 5.0.1 release, fetches the migration guide from expressjs.com, classifies 8 breaking changes across categories 7, 8, 10, and 11, applies all 8 AST transforms in a single pass, runs the build, runs all 43 tests, and opens a verified PR. Total time: 49 seconds. The developer reviews the PR, sees the detailed diff and category breakdown, and merges. Five minutes of review instead of four hours of manual work.

The choice is not between Dependabot and nothing. It is between fixing 15 PRs per month manually and reviewing 15 PRs per month that already work. See the public showcase for more real pipeline runs across open-source projects.

Frequently asked questions

Should I turn off Dependabot?

If you switch to ovvoc, yes. Ovvoc handles everything Dependabot does — security updates, version updates, PR creation — plus breaking change transformation, build verification, and test validation. Running both creates duplicate PRs and unnecessary noise. See our detailed Dependabot comparison for a side-by-side feature analysis.

Is Renovate better than Dependabot?

Renovate offers significantly more configuration than Dependabot — grouped updates, custom schedules, automerge rules, regex managers. It is a better version bumping tool. But it has the same core limitation: no code transformation. When a major version introduces breaking changes, Renovate bumps the version and your CI fails, just like Dependabot. The PR still requires manual code fixes. See our Renovate comparison for a detailed analysis.

Can ovvoc handle security updates?

Yes. Ovvoc integrates npm audit and detects CVEs during the analysis phase. Security patches that require no code changes are applied immediately. Security patches that require a major version bump with breaking changes are handled with full code transformation — the exact scenario where Dependabot fails. Your security updates arrive as verified, tested PRs, not as broken CI that someone needs to fix manually.

What if ovvoc cannot fix a breaking change?

You get a detailed failure report instead of a broken PR. The report includes the exact build or test errors, the transforms that were attempted, the relevant sections of the migration guide, and guidance on what needs manual attention. This is strictly better than what Dependabot offers — where a broken PR sits with a red CI badge and no explanation of what went wrong or how to fix it. Learn more on our zero-breakage guarantee page.

Dependabot was a good start. But starting is not finishing. Ovvoc finishes the job.

See how ovvoc compares to Dependabot and Renovate. Learn how we handle breaking changes and read how to fix npm breaking changes automatically.