Renovate vs Dependabot, and when neither is enough

Updated 2026-11-03

Dependabot is the updater built into GitHub: alerts from the GitHub Advisory Database, security pull requests to the minimum patched version, and version pull requests when you commit a dependabot.yml. Renovate is a separate app or job, with a dependency dashboard and grouped pull requests, on GitHub and on other hosts. Merging is a separate policy: Renovate supports automerge, and GitHub can automerge Dependabot pull requests when configured.

Both tools open pull requests that change dependency files. That is the whole overlap. The differences that decide which one to turn on are documented by GitHub and by Renovate’s comparison. Read those pages if this one and the product disagree later. A generated app on GitHub usually wants Dependabot first, because it is already there.

Turn on Dependabot alerts and security updates

Dependabot has three pieces, and GitHub’s docs treat them as separate switches.

Security updates do not wait for a dependabot.yml. GitHub’s security-updates page says Dependabot tries to open a pull request for every open alert that has a patch, unless you turn that off and use auto-triage rules to choose which alerts get a pull request. The pull request targets the minimum patched version, not the newest release, and it is linked to the alert. If the graph cannot be updated without a break Dependabot cannot resolve, the alert gets an error instead of a pull request. That error is the same situation as npm audit fix doing nothing: the patched version does not fit. You still have to override or bump a parent.

Dependabot security updates are available for public and private repositories on GitHub. A missing control may reflect your permissions or organization policy; it does not establish that a paid code-security plan is required. Do not describe that as “Dependabot found nothing”.

Add version updates only where you will review them

Version updates are the pull requests for packages that are merely old. GitHub’s version-updates page says you enable them by committing dependabot.yml. Dependabot looks at the manifests that file lists, decides from the semantic version whether a newer release counts, and opens a pull request. You are supposed to read the changelog it quotes and see that your checks passed before you merge.

By default, version updates wait three days after a release. That cooldown does not apply to security updates. You can change it with the cooldown option. Leave the wait in place on a generated app. The three days are when a bad release gets unpublished or a regression gets reported. Security updates still arrive immediately.

version: 2
updates:
  - package-ecosystem: npm
    directory: "/"
    schedule:
      interval: weekly
    cooldown:
      default-days: 3

Point directory at the folder that contains package.json. A Lovable export is often the repository root. A monorepo is not. Dependabot’s options reference uses package-ecosystem: npm for npm, pnpm, and Yarn. Confirm the pull request touches the lockfile you commit. A pull request that edits package.json and leaves pnpm-lock.yaml stale fails the next frozen install. GitHub documents one exception: a pnpm 12 lockfile written as two YAML documents is invisible to the dependency graph, so alerts and security updates are not created for it, while version updates still run. That case is in Dependabot’s supported ecosystems.

Groups are available, and GitHub can group some updates on its own, but you configure the groups you care about. If you want “all the eslint packages in one pull request” without writing that list, that is the Renovate reason below. If you will not review version pull requests, do not enable them. Alerts plus security updates are the smaller switch.

Install Renovate when you need grouping or another host

Renovate is not part of GitHub. You install the Renovate GitHub App or you run it yourself. Renovate’s comparison page lists official hosts that include Azure, Bitbucket, Forgejo, Gitea, GitHub, and GitLab. Dependabot’s hosted product is GitHub and, for the version-updates engine, Azure DevOps. If the repository is not on one of those, Dependabot is the wrong tool.

On GitHub, the practical differences Renovate documents:

• A Dependency Dashboard issue is on by default. It lists pending updates in one place. Dependabot does not have an equivalent.
• Community presets group related packages into one pull request. Dependabot can group, and you write the groups.
• Schedule is “as often as it is allowed”, which you then narrow. Dependabot’s schedule is the interval in the yaml, from daily through yearly, or a cron expression.
• The config file is renovate.json, renovate.json5, or a package.json key, not dependabot.yml.

Running both on the same repository, with both allowed to open version pull requests, produces two pull requests for one release. Pick one for version bumps. You can keep Dependabot alerts on while Renovate opens the pull requests. That is the next section, and it is the combination Renovate documents, not a mistake.

Let security pull requests skip the queue

Renovate’s vulnerabilityAlerts option reads GitHub vulnerability alerts and adjusts its pull requests. Its GitHub App also needs read permission for Dependabot alerts. The option’s docs say this works only if the dependency graph and Dependabot alerts are enabled. Follow GitHub’s settings path: repository, Settings, Advanced Security, Dependabot alerts.

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

Vulnerability fixes bypass repository-wide scheduling and rate limits by default. To bound concurrency without disabling fixes, set prConcurrentLimit or branchConcurrentLimit inside vulnerabilityAlerts. Those fixes have a separate concurrency budget; the normal schedule and hourly limits still do not apply.

Renovate also has an experimental OSV vulnerability summary. Its docs say OSV-based alerts in that summary cover direct dependencies, and that the summary is independent of osvVulnerabilityAlerts. Do not treat an empty OSV list as a clean bill for transitive packages. Dependabot alerts, which read the lockfile, are the wider of the two on GitHub.

Add a check for what neither bot can see

A merged bump can break the app in ways no advisory describes. Next.js 15 to 16 is a major with a migration guide, not a patch. A bot that opens it has done its job by opening it. You still follow the upgrade checklist before you merge. The same is true of a major of your UI kit, your database client, or React. Working an alert that is already open, including when to dismiss it, is handling GitHub security alerts.

Neither bot runs your product. Configure the pull request to run the same build you trust locally:

npm ci
npm test
npm run build

Use the install command that matches the lockfile. A red check is a reason to close the pull request. A green check is a reason to read the changelog and review the diff. Renovate automerge and GitHub’s Dependabot automerge workflow are available when you deliberately configure them. Require the checks that matter before enabling either. Auto-merge of patch updates is a later choice, after you have seen a week of green builds. Auto-merge of major updates is how a Lovable app wakes up restyled and unsigned-in.

There is a third gap. Alerts and pull requests only exist after the repository is on a host that runs the bot, and only for the ecosystems you configured. A public repo you have not enrolled, a lockfile in a folder you did not list, or a zip you downloaded and never pushed has none of this. The report form on this page reads a public GitHub repository’s npm, pnpm, or yarn lockfile without waiting for a bot to be installed. It does not open a pull request. It compares supported direct dependencies and checks resolved versions for advisories, with coverage limits shown in the report. Review any incomplete checks before using its findings as a maintenance brief.

For weekly upkeep, you can manually create a recurring dependency-review task with Denly’s task schedules after connecting a project and runner. Configure its instructions and review gates before enabling it. The public report form below creates a report; it does not create a schedule or a pull request.

Commands and product behavior on this page were checked against the vendor documentation linked here on 3 November 2026. Those products change their screens. If a label has moved, follow the linked page rather than a memory of this one.

Read next

npm audit fix is not working: why, and what to do instead · Upgrade Next.js 15 to 16: a practical checklist