Dependabot in 2026: The Configuration Deep Dive

Dependabot has quietly become a different product since 2024. It moved its compute onto GitHub Actions runners, gained a cooldown controller for "let new releases bake," picked up cron schedules, learned to span multiple directories and ecosystems in a single PR, replaced its reviewers field with CODEOWNERS, and retired the @dependabot merge comment commands.

If you last tuned your config two years ago, the old file will still run. It just no longer reflects how Dependabot works today.

This article is a current-state reference for developers who already know the basics. Every factual claim here is grounded in GitHub Docs, the GitHub changelog, or the dependabot-core repository.

GitHub Docs

Dependabot options reference - GitHub Docs

Detailed information for all the options you can use to customize how Dependabot maintains your repositories.

docs.github.com/en/code-security/reference/supply-chain-s...

(opens in new tab)

1. What Dependabot is, in 2026 terms#

Dependabot is three loosely-coupled products that share a YAML file:

1. Dependabot alerts — read-only notifications when a dependency in your dependency graph matches a GitHub Advisory Database entry. Enable them under Settings → Code security. See About Dependabot alerts.
2. Dependabot security updates — automated PRs that patch a vulnerable dependency to the nearest non-vulnerable version. They are triggered by alerts, not by your schedule, and they run without a dependabot.yml file. See About Dependabot security updates.
3. Dependabot version updates — scheduled, configurable PRs that bump dependencies even when no vulnerability exists. They do require a dependabot.yml file. See About Dependabot version updates.

All three now run as GitHub Actions workflows on Actions runners. The compute migration finished on June 23, 2025, when the legacy Dependabot service shut down, as GitHub noted in its compute migration announcement. That execution model matters because it changes what secrets are visible, where logs appear, and whether you can use self-hosted runners to reach internal registries.

A minimal dependabot.yml still looks the way it always has:

version: 2                          # Required. Always 2.
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

Everything else in this article is sugar on top of that skeleton.

2. The configuration deep dive#

2.1 commit-message — title shaping for every PR#

Dependabot derives the PR title from the commit message, so commit-message controls both. The three sub-fields are prefix, prefix-development, and include.

commit-message:
  prefix: "chore(deps)"            # all PRs unless prefix-development applies
  prefix-development: "chore(dev-deps)"
  include: "scope"                 # appends "deps" or "deps-dev" after the prefix

The options reference notes that prefix accepts up to 50 characters. Dependabot automatically inserts a colon after the prefix if the value ends in a letter, number, ), or ]. To prevent that, end the prefix with a trailing space. include currently accepts only the literal value scope, which makes Dependabot append deps: for production deps or deps-dev: for development deps, yielding conventional-commits-style titles such as chore(deps-dev): bump eslint from 9.0 to 9.1.

The prefix-development sub-field is supported only by bundler, composer, mix, maven, npm, pip, and uv — the ecosystems that have a distinct dev-vs-prod dependency concept. For Maven/Gradle or Docker, it has no effect.

One detail to remember: for grouped PRs, the branch and title are derived from the group identifier, not from the commit-message prefix alone. If you carefully crafted prefix: "chore(deps)" expecting it to appear in your group PR title, you'll still see the prefix, but the group name will dominate the rest of the title.

2.2 cooldown — let new releases bake (the headline 2025 feature)#

The cooldown option went generally available on July 1, 2025. It lets Dependabot delay a PR for a configurable number of days after a new version is published, which is useful when you want new releases to sit for a few days before they hit CI. At launch it covered every ecosystem except NuGet, and GitHub expanded support on July 29, 2025 to add NuGet and Helm.

The complete schema:

cooldown:
  default-days: 5                  # fallback for any update without a more specific rule
  semver-major-days: 30            # major bumps wait 30 days
  semver-minor-days: 7
  semver-patch-days: 3
  include:                         # max 150 entries; supports * wildcards
    - "*"
  exclude:                         # max 150 entries; takes precedence over include
    - "internal-*"
    - "@my-org/*"

The reference doc states the rules plainly: "If semver-major-days, semver-minor-days, or semver-patch-days are not defined, the default-days setting will take precedence." It also notes that "The exclude list always takes precedence over the include list."

A subtler behavior, confirmed in GitHub Community discussion #180877: Dependabot does not skip past unfinished cooldowns indefinitely. With default-days: 14 and a weekly schedule, Dependabot opens a PR for the newest version that has been published for at least 14 days, even if a newer release came out yesterday. The cooldown is a floor, not a freeze.

Per-SemVer-level cooldown requires a SemVer-aware ecosystem. The options reference enumerates which managers qualify; today the list includes Bazel, Bundler, Bun, Cargo, Composer, Devcontainers, Docker, Docker Compose, Dotnet SDK, Elm, GitHub Actions, Gitsubmodule, Gomod, Gradle, Helm, Hex, Julia, Maven, npm/Yarn, NuGet, OpenTofu, Pip, Pub, Swift, Terraform, and uv. For non-SemVer ecosystems, only default-days applies.

2.3 groups — one PR for many bumps#

Grouped version updates went GA on August 24, 2023. Grouped security updates and the applies-to toggle followed in 2024, reaching GA on March 28, 2024. Grouping is now the most reshaped area of Dependabot config.

groups:
  actions-minor-patch:
    patterns: ["*"]
    update-types: ["minor", "patch"]
  actions-major:
    patterns: ["*"]
    update-types: ["major"]

It's a textbook example: separate "safe to auto-merge" minor/patch updates from "needs human review" majors. Dependabot evaluates groups in order — "If a dependency matches more than one rule, it's included in the first group that it matches" — so put the more specific groups first.

The full group-rule schema:

The applies-to: security-updates value is essential and underused. Without it, a group rule has no effect on security PRs — each CVE produces its own PR by default. To consolidate, say, all Angular CVEs into one PR:

groups:
  angular-security:
    applies-to: security-updates
    patterns: ["@angular/*"]

Cross-directory grouping with group-by: dependency-name shipped on February 24, 2026. It is the natural partner for the directories key: one PR that bumps lodash across /service-a, /service-b, and /service-c instead of three. Constraints from the reference still apply: all directories must share the same ecosystem, it works for version updates only, and incompatible version constraints across directories will still produce separate PRs.

2.4 schedule — daily, weekly, monthly, or cron#

schedule.interval accepts seven values today: daily, weekly, monthly, quarterly, semiannually, yearly, or cron, which GitHub added on April 22, 2025. On GitHub Enterprise Server, quarterly, semiannually, and yearly require version 3.19 or later.

The semantics matter and are not what the names suggest:

• daily runs Monday through Friday only, not seven days a week.
• weekly defaults to Monday.
• monthly runs on the 1st.
• Each repo is assigned a randomized run time within the interval window, so two repos with identical configs will not fire simultaneously, as GitHub announced in 2021.

The full set of sub-fields:

schedule:
  interval: "weekly"
  day: "tuesday"                   # only meaningful with weekly
  time: "02:00"                    # 24-hour HH:MM
  timezone: "Asia/Tokyo"           # IANA tz database identifier; UTC by default

For cron, you specify cronjob instead of (or alongside) time:

schedule:
  interval: "cron"
  cronjob: "0 9 * * *"             # standard 5-field cron OR a natural expression
  timezone: "Europe/London"

The reference notes that natural expressions are accepted — cronjob: "every day at 5pm" is valid. Timezones go in the timezone field, never embedded in the cron string. A known limitation (dependabot-core #12246): step values in the day-of-week field, e.g. 0 8 * * 1/2 to mean "every other Monday," are silently treated as weekly Mondays.

2.5 rebase-strategy — let Dependabot keep up, or don't#

By default Dependabot rebases open PRs whenever the target branch moves, when you reopen a closed PR, when you change target-branch, or when a PR develops conflicts. The reference is explicit: "Dependabot default behavior is to rebase open pull requests when Dependabot detects any changes." You only see this key in a config file when you want to turn it off:

rebase-strategy: "disabled"

auto is the implicit default; you don't write it. When disabled, Dependabot stops rebasing — but there's a 30-day grace: "Pull requests that were open before you disable rebasing will continue to be rebased until 30 days after they were opened."

Choose disabled when rebasing repeatedly burns CI minutes on a busy default branch — a real cost on large monorepos — or when you'd rather close-and-reopen than have authors rebase under their feet. Stick with the default auto when you rely on auto-merge: a stale Dependabot PR with merge conflicts blocks the queue, so letting Dependabot rebase keeps the conveyor belt moving.

2.6 The reference config, annotated#

Put together, here's a modern Dependabot config:

version: 2

updates:
  # GitHub Actions dependencies
  - package-ecosystem: 'github-actions'
    directory: '/'
    schedule:
      interval: 'weekly'
      day: 'monday'
      time: '00:00'
      timezone: 'America/Los_Angeles'
    labels:
      - 'dependencies'
      - 'github-actions'
    commit-message:
      prefix: 'chore'
      include: 'scope'
    cooldown:
      default-days: 5
      semver-major-days: 30
      semver-minor-days: 7
      semver-patch-days: 3
    groups:
      actions-minor-patch:
        patterns:
          - '*'
        update-types:
          - 'minor'
          - 'patch'
      actions-security-minor-patch:
        applies-to: security-updates
        patterns:
          - '*'
        update-types:
          - 'minor'
          - 'patch'

  # NPM dependencies
  - package-ecosystem: 'npm'
    directories:
      - '/'
      - '/service-a/*'
      - '/service-b/*'
      - '/service-c/*'
    open-pull-requests-limit: 20
    schedule:
      interval: 'weekly'
      day: 'monday'
      time: '00:00'
      timezone: 'America/Los_Angeles'
    labels:
      - 'dependencies'
      - 'npm-packages'
    commit-message:
      prefix: 'chore'
      include: 'scope'
    cooldown:
      default-days: 5
      semver-major-days: 30
      semver-minor-days: 7
      semver-patch-days: 3
    groups:
      npm-minor-patch:
        patterns:
          - '*'
        update-types:
          - 'minor'
          - 'patch'
      npm-security-minor-patch:
        applies-to: security-updates
        patterns:
          - '*'
        update-types:
          - 'minor'
          - 'patch'

3. The features the headline missed#

3.1 open-pull-requests-limit — and the security-updates trick#

Default is 5 for version updates. Security updates have a separate, non-configurable internal limit of 10 open PRs.

3.2 allow and ignore — the filter pipeline#

allow filters in; ignore filters out; if a dependency matches both, it is ignored. Both accept dependency-name (globs), dependency-type, and update-types. ignore additionally accepts versions with ecosystem-specific range syntax (^1.0.0 for npm, ~> 2.0 for Bundler, [1.4,) for Maven, 7.* for NuGet).

allow:
  - dependency-name: "aws-*"
    dependency-type: "production"

ignore:
  - dependency-name: "express"
    versions: ["4.x", "5.x"]
  - dependency-name: "*"
    update-types: ["version-update:semver-major"]

The dependency-type values vary by ecosystem. direct works everywhere; indirect and all work only for bundler, pip, composer, cargo, gomod, and uv; production/development work only for the dev/prod-aware ecosystems (bundler, composer, mix, maven, npm, pip, uv).

The important limitation here is that "update-types only affects version updates, not security updates." If you write ignore: [{ dependency-name: "*", update-types: ["version-update:semver-major"] }] hoping to block major security upgrades, it will not work — Dependabot will still patch you to the next non-vulnerable major. Dependencies ignored via the @dependabot ignore PR comment are also stored centrally per package and stack on top of your dependabot.yml rules.

3.3 assignees, labels, milestone — and why reviewers is gone#

assignees: ["octocat", "user-name"]
labels:    ["npm dependencies", "triage-board"]
milestone: 4                       # numeric milestone ID, not the name

Assignees must have write access (or read access for org-owned repos). Labels default to dependencies plus an ecosystem label (npm, java, github-actions, submodules) plus SemVer labels if they exist in the repo. Specifying labels: overrides the defaults (SemVer labels still apply). labels: [] removes all of them. Undefined labels are silently ignored — Dependabot creates only the defaults.

GitHub retired the reviewers field on August 8, 2025. Use a CODEOWNERS file instead. GitHub published a migration action, dependabot/codeowner-migration-action. If your dependabot.yml still contains reviewers: blocks, Dependabot will quietly ignore them.

3.4 target-branch — the silent security-updates breaker#

target-branch: "develop"

Dependabot scans manifests on develop and opens PRs against it. The catch — and it surprises people — is that setting target-branch causes that ecosystem entry to stop influencing security PRs altogether, because "security updates always use the default branch for the repository." Every option marked with the security-shield icon in the reference (labels, assignees, milestone, commit-message, registries, etc.) is bypassed for security PRs whenever target-branch is set to anything other than the default branch. If you want security PRs governed by your config, leave target-branch alone.

3.5 versioning-strategy — which manifest edits Dependabot is allowed to make#

Five values, but not all ecosystems support all five:

Dependabot-core schema validation discussion #10677 confirms that pip rejects widen — its accepted values are exactly auto, increase, increase-if-necessary, and lockfile-only. npm/Yarn/pnpm/Bun, Composer, Bundler, and Mix accept all five. Cargo accepts auto and lockfile-only plus increase; increase-if-necessary for Cargo is still an open feature request in issue #4009. uv does not support versioning-strategy as of mid-2025, per issue #12162. Gradle, Maven, gomod, Docker, GitHub Actions, Terraform, and NuGet do not honor the field at all because they do not have a manifest-rewriting model that maps cleanly to these strategies. Python gained increase-if-necessary on October 24, 2022.

Like every option with a security-shield icon, versioning-strategy also governs security PRs — unless target-branch is set.

3.6 registries — private registries, two locations, one wildcard#

The pattern is two-step: define registries at the top level, then reference them by name (or use the "*" wildcard) inside an updates block.

version: 2
registries:
  gradle-artifactory:
    type: maven-repository
    url: https://acme.jfrog.io/artifactory/my-gradle-registry
    username: octocat
    password: ${{secrets.MY_ARTIFACTORY_PASSWORD}}
updates:
  - package-ecosystem: "gradle"
    directory: "/"
    registries:
      - gradle-artifactory          # or: registries: "*"
    schedule: { interval: "monthly" }

The currently supported type values are cargo-registry, composer-repository, docker-registry, git, goproxy-server, helm-registry, hex-organization, hex-repository, maven-repository, npm-registry, nuget-feed, pub-repository, python-index, rubygems-server, and terraform-registry. Authentication varies by type — most accept username/password, several accept token, hex-organization uses key, and the OIDC types take provider-specific fields.

replaces-base: true tells Dependabot to resolve dependencies from your registry instead of the ecosystem's public default. It's supported on docker-registry, maven-repository, npm-registry, and python-index — but not on nuget-feed. Two name-specific gotchas: for npm.pkg.github.com, omit any path component (use the bare URL); for Docker tags, match the repo path, not the tag.

OIDC authentication for Dependabot went GA at the repo level on February 3, 2026 and at the org level on April 14, 2026. Supported providers are AWS CodeArtifact (aws-region, account-id, role-name, domain, domain-owner), Azure DevOps Artifacts (tenant-id, client-id), and JFrog Artifactory (jfrog-oidc-provider-name). Google Artifact Registry is still not supported as of May 2026, though the April 14 changelog said Cloudsmith and GAR were planned within four weeks.

registries:
  nuget-azure-devops-oidc:
    type: nuget-feed
    url: https://pkgs.dev.azure.com/MY-ORG/MY-PROJECT/_packaging/MY-FEED/nuget/v3/index.json
    tenant-id: ${{secrets.AZURE_TENANT_ID}}
    client-id: ${{secrets.AZURE_CLIENT_ID}}

Org-level centralized registry configuration has been GA since July 22, 2025. It uses the same UI as code-scanning private registries, requires GitHub Advanced Security for private repos, and falls back from repo-level dependabot.yml credentials. GitHub enabled multiple registries per ecosystem at the org level on April 14, 2026.

There's also insecure-external-code-execution, supported for bundler, mix, and pip. When you reference any registry on an update entry, Dependabot automatically disables external code execution to defend against compromised packages. Override only when you understand the consequence: insecure-external-code-execution: "allow".

3.7 vendor — Bundler and gomod only#

vendor: true

Only supported by bundler and gomod. For gomod, vendored dependencies are maintained automatically — the field is implied. For bundler, set vendor: true to update files in vendor/cache alongside Gemfile.lock.

3.8 pull-request-branch-name.separator#

Default branch separator is /, producing names like dependabot/npm_and_yarn/next_js/acorn-6.4.1. Accepted values: "-", "_", "/". The hyphen must be quoted so YAML doesn't parse it as a list:

pull-request-branch-name:
  separator: "-"

3.9 enable-beta-ecosystems — still load-bearing in practice#

The current options reference says: "enable-beta-ecosystems: Not currently in use." Take this with a grain of salt. The dependabot-core contribution guide (NEW_ECOSYSTEMS.md) still gates new ecosystems on this flag during their beta window, and code paths like Helm::FileFetcher continue to check allow_beta_ecosystems? even after the ecosystem nominally went GA (issue #12121). If you're trying a brand-new ecosystem and getting a "not supported" error, set the flag at the top level and try again:

version: 2
enable-beta-ecosystems: true
updates: [...]

3.10 directories vs directory — and exclude-paths#

The plural directories form went into public beta on April 29, 2024 and gained wildcard and glob support on June 25, 2024.

# Single directory
- package-ecosystem: "composer"
  directory: "/"
  schedule: { interval: "weekly" }

# Many directories
- package-ecosystem: "bundler"
  directories: ["/frontend", "/backend", "/admin"]
  schedule: { interval: "weekly" }

# Wildcard / globstar
- package-ecosystem: "composer"
  directories: ["**/*", "/services/*"]
  schedule: { interval: "weekly" }

Use directory (singular) when you have exactly one path or want different settings per path. Use directories (plural) to apply one config to many paths or to glob across a monorepo. The two cannot collide: "all values are unique and there is no overlap in directories defined."

exclude-paths, which GitHub added on August 26, 2025, lets you skip manifests inside otherwise-matched directories — for example, directories: ["**/*"] plus exclude-paths: ["**/test-fixtures/**"]. Grouping only considers non-excluded manifests.

The natural pairing with groups.<name>.group-by: dependency-name (Feb 24, 2026) means a monorepo can now consolidate "bump lodash everywhere" into a single PR.

4. Platform changes you can't ignore#

4.1 Dependabot now runs on GitHub Actions#

This is the largest architectural change in Dependabot's history. The timeline:

• April 22, 2024 — Opt-in available on GHEC, Free, Pro, and Teams. GHES and Proxima were already on Actions. See the rollout note.
• May 2, 2024 — GA, plus self-hosted runner support. The headline benefit was simple: "Running Dependabot does not count towards GitHub Actions minutes — meaning that using Dependabot continues to be free for everyone." See the GA announcement.
• July 10, 2024 — Default rollout begins on accounts with Actions enabled.
• June 23, 2025 — Legacy compute shut down. Migration complete.

Further runner work followed: ARC (Actions Runner Controller) support went into public preview on April 30, 2025, and went GA together with Azure Virtual Network (vNet) support on May 27, 2025 — letting Dependabot run inside Kubernetes clusters and reach VPC-internal registries. Custom runner labels at the org level went GA on November 25, 2025; before that, self-hosted runners had to use the literal label dependabot.

The action that GitHub invokes for you is github/dependabot-action. You don't reference it in your own workflows — it's the orchestrator GitHub runs automatically. Logs appear in both the Actions tab and the Dependency Graph → Dependabot tab. Standard runners don't have static IPs; if your registry requires IP allowlisting, use self-hosted or larger runners.

4.2 New ecosystems, 2024–2026#

The two-year cadence has been brisk. The high-value adds:

uv deserves a callout: it shipped directly as GA in March 2025 without a public-beta changelog post, which is unusual for an ecosystem this prominent. Security updates for uv followed on December 16, 2025. Earlier 2024-era complaints about uv.lock not being regenerated were resolved as the ecosystem matured. Deno still does not have Dependabot support as of May 2026.

4.3 Auto-merge — the canonical 2026 pattern#

The recommended approach uses dependabot/fetch-metadata@v2 and gh pr merge --auto from the GitHub CLI. The canonical example lives in Automating Dependabot with GitHub Actions:

name: Dependabot auto-merge
on: pull_request
permissions:
  contents: write
  pull-requests: write
jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.event.pull_request.user.login == 'dependabot[bot]'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v2
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Enable auto-merge for Dependabot PRs
        if: steps.metadata.outputs.update-type == 'version-update:semver-patch'
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GH_TOKEN: ${{secrets.GITHUB_TOKEN}}

GitHub Docs

Automating Dependabot with GitHub Actions - GitHub Docs

Examples of how you can use GitHub Actions to automate common Dependabot related tasks.

docs.github.com/en/code-security/dependabot/working-with-...

(opens in new tab)

The fetch-metadata action exposes update-type, dependency-names, dependency-type, package-ecosystem, and directory as outputs — branch the auto-merge logic on these. Repo settings must have "Allow auto-merge" enabled, and (for approval-based flows) "Allow GitHub Actions to create and approve pull requests."

The comment commands (merge, squash, close, reopen) are gone. GitHub removed them on January 27, 2026 after deprecating them on October 6, 2025. On GHES they remain until 3.20. Use the UI, gh pr merge, or the REST API instead.

4.4 Dependabot secrets — separate from Actions secrets#

Dependabot secrets live at Settings → Secrets and variables → Dependabot and exist at repo or org level (org secrets can be scoped to specific repos). They are not forwarded to forks. They power ${{secrets.NAME}} references inside dependabot.yml's registries: block and inside Dependabot-triggered workflows.

4.5 Multi-ecosystem grouping and the multi-ecosystem-groups block#

GitHub took multi-ecosystem grouping to GA on July 1, 2025. A single PR can now bundle updates across multiple ecosystems — for example, a Docker base image and the Terraform provider pinned to it — in one atomic change. It is configured via a top-level multi-ecosystem-groups key referenced from each ecosystem's updates block.

4.6 Other 2025–2026 changes worth knowing#

• Dependabot proxy open-sourced (Feb 3, 2026, MIT license): the Go-based HTTP proxy that brokered registry auth is now public.
• Delegated alert dismissal (Dec 19, 2025): require a reviewer before closing a Dependabot alert.
• Audit log events for Dependabot config changes (Feb 10, 2026).
• Cross-org Dependabot access for internal repositories (May 11, 2026): enterprise-wide.
• Dependabot CLI: open-source tool for testing update jobs locally; now also surfaced through the GitHub MCP Server's dependabot toolset (May 2026 public preview).
• Failure pause threshold: Dependabot pauses scheduled jobs after 15 consecutive failures (reduced from 30) — surfaces problems sooner.

5. What to actually change in your dependabot.yml this quarter#

The Dependabot of 2026 rewards a few specific edits. Adopt cooldown immediately — even just default-days: 3 materially reduces exposure to compromised packages without slowing real updates. Migrate from reviewers to CODEOWNERS if you have not already; the field is gone. Replace any @dependabot merge comment automation with a proper auto-merge workflow using dependabot/fetch-metadata@v2. Split your groups config into separate minor or patch and major rules so you can auto-merge the safer ones. Audit target-branch usage too, because every entry with a non-default target-branch is silently exempting itself from your security-PR configuration. And if you have private registries with long-lived secrets, start the OIDC migration for AWS CodeArtifact, Azure DevOps Artifacts, or JFrog.

The real takeaway is simpler than the option list: Dependabot is no longer something you configure once and forget. It now sits on the same operational surface as the rest of your delivery pipeline, with runner choice, secret scope, merge policy, registry access, and CI behavior all shaping the outcome. The YAML still matters, but it is no longer the whole story. If you update your config with that model in mind, Dependabot becomes much easier to reason about. If you keep treating it like the 2024 version, the surprises will keep showing up. Go forth and update your configs (or at least put the story into a backlog 👻)