What is Renovate bot, and how to run automated dependency updates with checks that actually run

What is Renovate bot? Its own README answers in one line: “an automated dependency update tool.” It scans a repository’s package files, looks up registries for newer versions and raises pull requests to update them. What its docs leave to you decides whether it helps: whether each pull request runs the full CI, who reviews it, and which updates may merge without a person.

What is Renovate bot, and what automated dependency updates are

Renovate bot is an open-source tool that keeps dependencies current, usually in 5 steps: it clones the repository, extracts dependencies from the package files, checks the registries for newer versions, applies any grouping rules and raises a pull request per update or group. It never runs your tests. Your CI does that.

This control is one piece of DevOps for startups: the release path from one repository to a small team. Renovate is open source under the AGPL-3.0 license and is maintained by Mend. The repository lists GitHub, GitLab, Bitbucket, Azure DevOps, Gitea and Forgejo among its platforms, says it supports “over 90 different package managers”, and offers three ways to run it: Mend’s cloud-hosted app, a self-hosted install, or the CLI through npx renovate, a GitHub Action or a GitLab runner.

The table follows the steps Renovate usually performs, as set out in how Renovate works, in its docs (Renovate 44.132.5 at the time of writing). The right-hand column is my reading of the docs, not a line from them, except where a row says otherwise.

Dependabot is GitHub’s built-in tool for the same job: its security updates raise pull requests for dependencies with known vulnerabilities, and its version updates raise pull requests to keep dependencies up to date. So automated dependency updates are two things, a bot that proposes and a pipeline that judges, and the second one is the control.

What goes wrong without it

A generated app starts on the versions its builder chose the day it was made, and nothing moves them until someone asks. That is a sensible default for a prototype. My June and July 2026 audits scored the Dependencies and Supply Chain pillar at an average of 34.5 out of 100, across the 20 of 21 third-party apps where it applied (not applicable was excluded, not scored as zero), which put it 2nd of 12 pillars counting from the weakest. Those 21 apps are a set I chose to look at, not a random sample, so the number describes them and is no rate for AI-built apps in general.

Five situations cover the range, from no bot at all to a bot nobody keeps up with.

The third row deserves a closer look, because it hides inside a green tick. On GitHub, workflow runs triggered by Dependabot from push or pull_request events “receive a read-only GITHUB_TOKEN and do not have access to any secrets that are normally available”, per GitHub’s page on Dependabot and GitHub Actions. My reading of what that does to a typical test job: a step that reads secrets.DATABASE_URL gets an empty value, and a pipeline written to skip integration tests when the variable is missing reports success on whatever is left.

The flood row is why the pull requests still need an owner; that argument, with GitHub’s own wording, sits in ongoing developer support for an app. When an update has already broken production, recovery comes first: a dependency update broke my app walks through it. Finding and fixing packages with known vulnerabilities is a separate job, done with the npm audit command.

How to set it up: Renovate, Dependabot, and the rules around them

Automated dependency updates are set up in 3 decisions: which bot proposes the updates, which checks every update pull request must pass, and which classes of update may merge without a person. Installing the bot is the quick part. The second and third decisions are the control.

The steps below follow GitHub’s and Renovate’s documentation as read on 4 October 2026; the configuration files are illustrations to adapt, not drop-in files. I’d allow an afternoon or so to set up either bot on one repository, most of it spent on the checks rather than the install.

Renovate, Dependabot, or neither

Dependabot and Renovate differ in 3 ways that matter to a small team. Dependabot is built into GitHub and switched on from the repository’s settings. Renovate runs on GitHub, GitLab, Bitbucket and Azure DevOps, ships ready-made update groups and per-dependency schedules, and has automerge built in. With no test suite, neither helps until CI exists.

Renovate’s docs carry Renovate’s own bot comparison, which says it is “trying to be as objective as possible”; read it as one side’s view. The table below takes each cell from the tool’s own docs.

Renovate’s comparison page is not consistent on one point: its table lists Dependabot on “GitHub and Azure DevOps”, while its text says “The official Dependabot program only works on GitHub.” For a team on GitHub the difference does not matter.

When to pick which, in my reading: one GitHub repository and a wish for the least setup points to Dependabot; several repositories, a host other than GitHub, tight grouping and scheduling, or a monorepo points to Renovate. Neither is a real answer for an app with no tests, because a bot adds noise until CI exists, so build the pipeline first, following CI/CD best practices for one repository, and, as my working rule, update dependencies yourself about monthly until then. Of the other Dependabot alternatives, Snyk, Socket, Endor Labs and Trivy are security scanners first, in my reading; for proposing update pull requests that pass through checks, the two bots above cover the job.

How to set up Dependabot

Dependabot is set up in 6 steps: enable it under the repository’s Advanced Security settings, add one entry per ecosystem to .github/dependabot.yml, pick a weekly schedule, group minor and patch updates, cap open pull requests, and store the test secrets as Dependabot secrets so CI really runs.

The first step needs only the browser: open the repository’s Settings, click Advanced Security in the “Security and quality” section of the sidebar, then click Enable for Dependabot alerts, Dependabot security updates and Dependabot version updates. Enabling version updates opens a starter dependabot.yml in the .github directory for you to edit, and GitHub turns on the dependency graph if it was off.

1. 01 Enable alerts, security updates and version updates under Settings, Advanced Security
2. 02 Add one updates entry per ecosystem and directory: npm at the root, github-actions, and docker if the repository has a Dockerfile
3. 03 Set a weekly schedule on a day someone will look at the pull requests
4. 04 Group minor and patch updates of development dependencies into one pull request
5. 05 Set open-pull-requests-limit so the queue stays readable
6. 06 Name a reviewer in a CODEOWNERS file, then copy the secrets your tests need into Dependabot secrets

Every key in the file below comes from the dependabot.yml options reference; the group name and the day are my choices.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "tuesday"
    open-pull-requests-limit: 5
    groups:
      dev-minor-and-patch:
        dependency-type: "development"
        update-types: ["minor", "patch"]
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Without the open-pull-requests-limit line, Dependabot stops at five open version-update pull requests anyway, and security updates never count toward the cap. The reviewers key that older guides show was removed in August 2025; GitHub points to code owners instead.

The last step is the one the quickstart leaves out. When Dependabot triggers a workflow, “the only secrets available to the workflow are Dependabot secrets”, so a test job that reads secrets.DATABASE_URL needs a Dependabot secret with the same name; it is referenced with exactly the same syntax. Point it at a test database, never production. Then confirm the checks that must pass apply to Dependabot’s pull requests, which the merge policy below and the verify list further down cover.

How to set up Renovate: the app, the onboarding pull request and renovate.json

Renovate starts from the Mend Renovate app on GitHub: open github.com/apps/renovate, click Install and pick the one repository. The Community Cloud plan is free for public and private repositories. Renovate then opens a “Configure Renovate” pull request containing a renovate.json with suggested defaults, and “will not make any changes to your repository or raise any further Pull Requests until after you merge the onboarding Pull Request.”

1. 01 Install the Mend Renovate app on the one repository
2. 02 Edit renovate.json on the onboarding branch before you merge it
3. 03 Keep config:recommended in extends; it turns on the Dependency Dashboard and the recommended groups
4. 04 Add a schedule, one group for non-major development dependencies, a prConcurrentLimit and lockFileMaintenance
5. 05 Add a minimumReleaseAge for npm so a brand-new release waits before it is proposed
6. 06 Leave major updates as single pull requests with no automerge, and use the Dependency Dashboard issue as the to-do list

Every option name below is in Renovate’s configuration options; the schedule and the limit are my choices.

{
  "extends": ["config:recommended"],
  "schedule": ["* 0-4 * * 1"],
  "prConcurrentLimit": 5,
  "lockFileMaintenance": { "enabled": true },
  "packageRules": [
    { "matchDatasources": ["npm"], "minimumReleaseAge": "3 days" },
    {
      "matchDepTypes": ["devDependencies"],
      "matchUpdateTypes": ["patch", "minor"],
      "groupName": "devDependencies (non-major)",
      "automerge": true
    }
  ]
}

Read it top down. The cron schedule lets Renovate create branches before 5am on Mondays, and Renovate’s docs advise a window of at least 3 to 4 hours so a run lands inside it. Without prConcurrentLimit the default is 10 open pull requests. lockFileMaintenance is off by default; turned on, it deletes the lockfile, lets the package manager write a fresh one, and opens that as its own pull request, by default before 4am on Monday. The npm rule copies Renovate’s own example of 3 days, which its docs tie to the fact that npm packages under 72 hours old can be unpublished from the registry. The group rule is the only automerge in the file, and it covers patch and minor updates of development dependencies, the first class of the policy below.

Whether Renovate’s pull requests get the repository’s Actions secrets is a fair question after the Dependabot section. The Mend app asks for write access to code “for creating branches”, so its pull requests come from branches inside your repository, not from a fork, and forks are the case where GitHub withholds secrets. Neither Renovate’s docs nor GitHub’s say in so many words which secrets a Renovate pull request’s workflow run receives, so check 2 of the verify list settles it on your repository.

What may merge by itself, and what needs a person

A dependency merge policy, in my working rule, has 5 classes. Patch and minor updates of development dependencies may merge themselves on a green pipeline. Production patches need tests that cover the critical flows. Production minors need a reviewer. Majors need a person and a preview. Security updates follow the same rules, first.

The policy is my working rule, not a vendor default, and the “who reviews” column assumes a team of one to three engineers.

The preview build in the major row assumes you know what preview deployments are and have one per pull request. Renovate’s docs make a similar split: automerge “often works well for devDependencies” and “can work for production dependencies too, but your project should have good test coverage”, while “most people would want to leave major dependency updates to a human to review first”.

A public incident shows why the waiting period and a lean CI job matter even with a perfect policy. GitHub’s advisory on ua-parser-js, published on 22 October 2021, says the npm package “had three versions published with malicious code”, 0.7.29, 0.8.0 and 1.0.0, with 0.7.30, 0.8.1 and 1.0.1 as the patched versions; CISA’s alert of the same day names the same versions. The advisory adds: “Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer.” The lesson I take from it, which is my reading and not the advisory’s: a green pipeline cannot tell a malicious release from a good one, so two settings limit the damage. One is a waiting period before a brand-new version is proposed, which helps only when an advisory lands inside it. The other is a CI job that holds no more secrets than its tests need, because a CI runner that installs the package is one of those computers.

A policy only binds if something enforces it. Each plan condition below comes from GitHub’s page on protected branches and its rulesets and auto-merge pages; setting up GitHub branch protection itself is its own job.

Two lines in that table carry the risk. A required check passes when the job is skipped, so a test job with an if: that skips it for bots still lets the merge through. And Renovate’s docs warn that with platform automerge and no status check selected in the branch rule, “GitHub might automerge PRs with failing tests!” On a free plan with a private repository, the checks still run and report, but nothing blocks the merge button: the policy becomes the owner’s rule, and Dependabot auto-merge through GitHub is not the route, in my reading of the two plan conditions.

If main deploys on every merge, know what a rollback plan is before the first automerge lands; a risky major upgrade can also ship dark behind a flag, and in my view open source feature flags are enough for that on a small app. Each update pull request also costs a CI run and often a preview build, and previews and build limits differ by host, which Railway vs Vercel compares alongside the other common hosts.

SBOM formats: SPDX and CycloneDX, and what an SBOM lists

SBOM stands for software bill of materials, which CISA describes as “a nested inventory, a list of ingredients that make up software components.” Two formats lead: SPDX, hosted by the Linux Foundation with roots in license compliance, and CycloneDX, from OWASP and security-focused from its first version. CISA says to accept either; GitHub exports SPDX from the dependency graph.

An update bot can only update what a file declares, and an SBOM is that declared list written down. The comparison of SPDX vs CycloneDX below takes each cell from the SPDX overview, the CycloneDX specification overview and CISA’s 2026 guidance, which CISA’s SBOM page links.

My verdict, for a small SaaS: the fields matter more than the format, and the cheapest route is the one the platform already gives you. On GitHub, open Insights, click Dependency graph, then click Export SBOM at the top right of the Dependencies tab; the file is in SPDX format and lists versions, package identifiers, licenses, transitive paths and copyright information. The export works on private repositories as long as the dependency graph is on, and enabling Dependabot turns it on. The CycloneDX entry on GitHub’s page goes the other way: an action that uploads a CycloneDX SBOM to the dependency submission API.

The most useful software bill of materials template is CISA’s list of minimum data fields. The 2026 Minimum Elements, published on 29 July 2026 by CISA, the NSA, the FBI and international partners, replaced the NTIA list of 2021, and replaced its “Supplier Name” field with “Component Producer”. The 17 fields are below, with one made-up package filled in as an illustration.

Whether a buyer requires an SBOM, what a reviewer accepts and how to generate one per stack belong with license scanning, which works from the same component list.

How to verify it

Update pull requests are verified in 6 checks: produce a real one, compare its checks with a human pull request’s, prove a failing test turns the pipeline red, confirm the review rule applies to the bot, confirm majors never merge themselves, and confirm the deploy that followed went through the normal pipeline.

Those checks verify update PRs run the full CI, not a thinner copy of it.

Deliverable 7.9 in the Production Hardening Sprint, Automated dependency updates, is verified the same way: we verify an update proposal triggers the appropriate CI checks and review requirements. Each check below says what you see on GitHub with a private repository, on any plan unless the check says otherwise.

1. 01 Produce a real update pull request. Renovate: tick a box on the Dependency Dashboard issue. Dependabot: use an open Dependabot pull request or wait for the scheduled run, then look under Insights, Dependency graph, Dependabot. Pass: a bot pull request exists
2. 02 Open its Checks tab beside a recent human pull request's. Pass: every job the human pull request ran (lint, typecheck, build, unit and integration tests) appears and succeeded. Fail: a job is missing or skipped, or its log shows a secret or variable it could not read
3. 03 On a scratch branch off main, open a human pull request that breaks one test. Pass: that job turns red, and where branch protection or a ruleset applies the merge box also shows the merge blocked. Close it unmerged and delete the branch
4. 04 Confirm the review rule. Pass: where required reviews apply, the bot's pull request cannot merge without approval unless its class is on the automerge list; on a plan without them, a written policy and a named reviewer on each merged production update
5. 05 Confirm automerge stays in its lane. Pass: the automerge rules in renovate.json or the auto-merge workflow match the policy table, and open major or production updates are still open, not merged
6. 06 Confirm the deploy after a merged update. Pass: it went through the normal pipeline and the app's smoke check passed

Check 2 matters most, because a skipped job satisfies a required check on GitHub, so the merge box alone cannot tell a full run from a hollow one. Check 3 proves the jobs can fail; check 2 then proves the bot’s pull request runs those same jobs. If no major or production update exists yet for check 5, the config rule is the evidence until one arrives.

Evidence to keep: the URLs of the two Checks tabs, the red scratch run, the commit that added the bot’s config file, and the date. Re-run all six after any change to the workflows or the bot’s configuration.

Where the sprint does this

In the Production Hardening Sprint, deliverable 7.9 is to configure Renovate, Dependabot, or an equivalent to propose dependency updates with checks. It builds on deliverable 7.3, pull-request CI, which runs linting, type checks, builds, and tests on every pull request, and sits beside deliverable 3.5, dependency remediation, where we audit dependencies, upgrade or remove known-vulnerable packages, and remove unused packages. The production readiness report, deliverable 13.1, delivers the result for every scope item, the work completed, and its verification evidence. The app’s current framework and hosting setup are the starting point; components are refactored or replaced where the production work requires it. Hosting, paid tools, and API usage remain in your accounts. Each deliverable and its verify line is in the published scope, area 7.

Common questions about Renovate and Dependabot

Is renovate bot free?

Yes. Renovate is open source under the AGPL-3.0 license, and Mend’s hosted Community Cloud plan is free, “available for all across an unlimited number of public and private repositories.” Self-hosting the CLI costs only the machine it runs on. Mend also sells a paid Enterprise tier.

Is it possible to run Renovate locally?

Yes, as a preview. The CLI is the npm package renovate, which runs anywhere Node.js does, even through npx, and renovate --platform=local runs it against the current directory as a dry run that defaults to dryRun=lookup. The local platform is flagged as experimental and cannot create branches, so it shows what Renovate would propose without opening anything.

How often does dependabot run?

Version updates run on the schedule.interval you set per ecosystem: daily runs every weekday, weekly runs once a week (Monday by default), and monthly runs on the first of the month, with quarterly, semiannually, yearly and cron also offered. Security updates do not wait for the schedule: Dependabot tries to fix a vulnerable dependency when a Dependabot alert is raised.

How to manually trigger renovate bot?

On the hosted app, tick a checkbox on the Dependency Dashboard issue: Mend’s cloud queues a Renovate job “when actions are triggered from the Renovate PRs or Dashboard issue.” The dashboard’s checkboxes can also force a pull request that a schedule or a rate limit held back, and the checkbox on an update pull request asks for a rebase. Self-hosted, run the CLI.

What is the minimum package age in Renovate?

There is none by default. The option is minimumReleaseAge, which makes Renovate wait a set time after a release before suggesting it, and its entry lists no default value; the security:minimumReleaseAgeNpm preset, which config:best-practices includes, waits until an npm package is three days old. My working rule is a few days, so an advisory has time to appear before the update is proposed; it catches nothing by itself, and Renovate’s docs say security updates bypass the wait.