Dependabot production-operations guide: separate alerts, security updates, and version updates into the 'three pillars' to keep dependencies automatically and safely up to date

From the moment you npm install, hundreds to thousands of packages written by others hang off your repository. When a known vulnerability is found in one of them, how many days later will you notice, and how many days later can you fix it? Leaving dependencies alone is a supply-chain risk that quietly piles up, and at the same time technical debt.

Dependabot automates this problem GitHub-natively and, what's more, with no extra billing on standard runners. It detects vulnerabilities, automatically opens fix PRs, and keeps stale dependencies following the latest — many articles write this far. But what works in production is what's beyond that: "separating the three pillars," "curbing the PR flood," and "operations design with an SLA."

Rules for this article: feature names, config keys, and behavior are based on the GitHub official documentation (as of June 2026). Dependabot adds features fast, and even at writing time new options like cooldown, directories (glob), and multi-ecosystem-groups are increasing. Before production rollout, always confirm the latest behavior in the official options reference. The code is arranged in a production-durable form, but registry credentials assume Dependabot secrets (never hardcode in the repository).

This article is the pillar (big picture) of this cluster. The details dig in to dedicated guides.

• All options in the config file → the complete dependabot.yml configuration guide
• Vulnerability-response operations → Dependabot alerts / security updates / vulnerability management guide
• Auto-merge → auto-merge × GitHub Actions automation guide
• Tool selection → Dependabot vs. Renovate selection guide

0. Most important: Dependabot is the "three pillars"

For 90% of people who stumble on Dependabot, the cause is thinking it's a single feature. In reality it's the collective name for three features of different character, and the way to enable them, the purpose, and the dependence on the config file all differ. Let's separate them first.

In the official words, version updates are "automatic PRs that keep dependencies up to date even without vulnerabilities," and security updates are "PRs that fix only the vulnerabilities that have a patch." Alerts are detection, security updates are fixing, version updates are freshness maintenance — remember it with these three words.

[GitHub Advisory DB] × [dependency graph]
        └─▶ Dependabot alerts (detect / notify)
                └─▶ Dependabot security updates (PRs that fix vulnerabilities with a patch)

[.github/dependabot.yml]
        └─▶ Dependabot version updates (PRs that bring stale deps up to date)

A common snag: "I turned on the security settings, but PRs for new library versions don't come." That's normal. New-version following (version updates) doesn't run without dependabot.yml. Conversely, "I placed dependabot.yml but vulnerabilities are left alone" is mostly just alerts/security updates being OFF.

1. Which to use in which situation (decision-making)

The three pillars aren't exclusive; using them stacked is the basic. Here are minimal setups by project stage.

• First, in all repositories: turn ON alerts + security updates. This is the minimum defensive line of "don't leave vulnerabilities alone," works without a config file and in a few clicks. Whether OSS or internal, start here.
• Actively developed repositories: add version updates (dependabot.yml) to the above. When stale dependencies pile up, you fall into a state of "the major version drifted too far to fix" the moment a vulnerability appears. The more you keep following in small steps, the easier emergency response becomes.
• Monorepo / many services: run version updates while minimizing noise with groups, cooldown, and directories. Do this sloppily and PRs become a flood, and in the end no one looks (= it becomes a dead letter). It needs design.

2. Enable it in the shortest path

2.1 Alerts + security updates (no config file)

In the repository's Settings → Advanced Security (or Code security), turn ON the following in order.

1. Dependency graph — the foundation for GitHub to grasp what you depend on. ON by default in many repositories.
2. Dependabot alerts — matches the dependency graph × the GitHub Advisory Database and detects vulnerabilities.
3. Dependabot security updates — among alerts, automatically opens PRs that fix those with a patch.

If you want to apply it to the entire organization at once, you can roll it out to all repositories as a default from the organization's Global settings (Advanced Security). If you also want it auto-applied to new repositories, configuring it here is the right answer.

Prerequisites (official): for security updates to run, you need four things — the dependency graph is enabled, alerts are enabled, a supported ecosystem, and the dependency is listed in a manifest or lockfile. Pitfalls like "package-lock.json being .gitignore'd so it falls out of the update target" originate here.

2.2 Version updates (commit dependabot.yml)

Place .github/dependabot.yml at the repository root and version updates start running. The minimal setup is as follows.

# .github/dependabot.yml
version: 2
updates:
  # アプリの依存（npm / yarn / pnpm）
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

  # GitHub Actions のワークフローで使うアクション自体も更新対象にする
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

version: 2 is required (the current schema). Each updates entry represents "which ecosystem's, which directory, at which frequency" to update. Including github-actions is strongly recommended — the versions of the actions used in workflows (especially hash-pinning) are a legitimate supply chain too, and leaving this alone means you can't notice a compromise via CI.

All options in the config file (groups, cooldown, ignore, registries, monorepo directories, etc.) are covered in the complete dependabot.yml configuration guide.

3. Where it runs and how billing works

This is a point much misunderstood despite swaying the cost feel. The official current state (as of June 2026) is this.

• Dependabot updates run on GitHub Actions runners (already GA).
• However, on standard GitHub-hosted runners and on self-hosted runners, Dependabot updates don't consume billed Actions minutes. Whether public or private, they're usable effectively for free.
• Only when running on a larger runner are you billed at the normal rate.
• The main reason to choose a self-hosted runner is network reachability. When you want to update dependencies of a private registry unreachable from outside, such as inside a VPC, run Dependabot on a self-hosted runner placed in your internal network.

From a cost-optimization viewpoint: think of it separately as "Dependabot is free, but your CI (tests, build) that runs triggered by Dependabot's PRs consumes Actions minutes as usual." When PRs become a flood, what's consumed is not only human review time but CI minutes. That's exactly why the next chapter's noise suppression works not just for quality but also for optimizing the bill.

4. Curb the PR flood structurally (so operations don't become a dead letter)

The biggest reason Dependabot adoption fails is not technology but "too many PRs so no one looks anymore." This can be solved structurally with settings.

4.1 groups: bundle related updates into one PR

Using groups, you can bundle multiple dependency updates into one PR. In addition to the standards of grouping @types/* or grouping test-related deps, the operation of bundling patch/minor to lower review load works.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      # 型定義はまとめて1PRに
      types:
        patterns: ["@types/*"]
      # その他の patch / minor は1PRに束ねる（major は個別のまま）
      minor-and-patch:
        update-types: ["minor", "patch"]

groups can be applied not only to version updates but also to security updates with applies-to: security-updates, and in a monorepo, cross-directory bundling is also possible with group-by: dependency-name. For details, go to the complete configuration guide.

4.2 cooldown: avoid the "accident lot" right after a release

cooldown (a relatively new option) is a feature that waits a certain number of days after a new version comes out before opening a PR. It's a buffer to avoid stepping on a version withdrawn right after release, or a freshly-out regression.

    cooldown:
      default-days: 7        # 既定で7日寝かせる
      semver-major-days: 30  # major はさらに慎重に30日

4.3 open-pull-requests-limit: the cap on simultaneously open PRs

The default number of simultaneously open version-update PRs is 5. Too many or too few is hard to operate, so adjust to your team's review throughput. The security-update cap is fixed at 10 (unchangeable) — GitHub's philosophy of "don't let vulnerability fixes pile up" shows here.

5. auto-merge: bring in automatically only the safe ones

Even with noise curbed, the review load remains. So the standard division of labor is to auto-merge "updates with a low chance of breaking (patch/minor)" on the condition of CI passing, and have humans focus on majors and substantive updates.

Using GitHub Actions and dependabot/fetch-metadata, branch on the update type (minimal example).

# .github/workflows/dependabot-auto-merge.yml
name: Dependabot auto-merge
on: pull_request

permissions:
  contents: write
  pull-requests: write

jobs:
  auto-merge:
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      - name: Fetch Dependabot metadata
        id: meta
        uses: dependabot/fetch-metadata@v3
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"

      # patch / minor のみ自動マージ（major は人間がレビュー）
      - name: Enable auto-merge for patch & minor
        if: steps.meta.outputs.update-type == 'version-update:semver-patch' || steps.meta.outputs.update-type == 'version-update:semver-minor'
        run: gh pr merge --auto --merge "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

--auto is an instruction that reserves "merge once all required checks turn green." If tests fail, it won't auto-merge = CI becomes the safety valve.

There's an important security premise here. The GITHUB_TOKEN of a pull_request workflow that Dependabot triggers is read-only by default and can't access ordinary Actions secrets (a design to prevent a compromised dependency from stealing secrets). So, as above, explicitly set permissions on the workflow side to grant write. Avoid dangerous patterns like casually using pull_request_target or checking out and running the PR's code. The token model, the difference between pull_request and pull_request_target, combining with group PRs/cooldown, and combining with required checks are handled in detail in the auto-merge × GitHub Actions automation guide.

6. Vulnerability-response operations (don't end at detection)

Alerts are merely detection. Value emerges only once "detect → triage → fix → close" starts turning as an operation.

• The contents of an alert: a link to the affected file, the vulnerability details and severity, and (if any) the fixed version. Prioritize by severity and crush from Critical/High.
• auto-triage rules: a mechanism to prevent alert fatigue. In addition to GitHub's presets (e.g., auto-dismissing low-impact alerts of npm dev dependencies that hardly affect production), you can make custom rules by severity, scope (dev/prod), package name, CWE, etc. Rules are applied before notification, so auto-dismissed ones don't even fire a notification = less noise.
• grouped security updates: bundle multiple vulnerability fixes into one PR per ecosystem to reduce the steps of response (with constraints: no cross-ecosystem consolidation, no mixing with version updates).
• Automating the close: when a Dependabot security-update PR is merged, the corresponding alert is automatically closed. No accidents of forgetting to close it by hand.

The SLA of "which severity to fix within how many business days," the handling of dev dependencies, the dismissal criteria for false positives — verbalizing this is the heart of operations design. The concrete design is dug into in the alerts / security updates / vulnerability management guide.

What Dependabot looks at is the vulnerabilities of dependencies (SCA: Software Composition Analysis). Vulnerabilities in the code you wrote (SQLi, XSS, SSRF, broken authorization, etc.) are out of scope; that's the domain of SAST/DAST. The two are complementary (reference: practical web-application vulnerability assessment guide).

7. Production-operations checklist (SRP "operations design")

Tool adoption and operations design are different things. If you call yourself world-class, document this.

• Alerts + security updates ON in all repositories (enforced by organization defaults)
• Active repositories enable version updates with dependabot.yml (including the github-actions ecosystem)
• Define an SLA: spell out "Critical within N business days, High within M business days"
• PR-noise measures: set groups + cooldown + open-pull-requests-limit
• auto-merge for CI-conditional auto-merge of patch/minor, majors reviewed by humans
• Define the approval flow of dependency-update PRs with CODEOWNERS / required reviews
• Enforce required status checks (tests, types, lint, build) with branch protection and make them the safety valve of auto-merge
• Inventory: once a quarter, review stagnant major PRs and ignore'd dependencies (so a pickled ignore doesn't become new debt)
• Private registries with Dependabot secrets + registries; for unreachable networks, a self-hosted runner
• Observability: dashboard the count of unaddressed alerts, the elapsed days of the oldest alert, and the average dwell time of PRs (alerts can be exported via the REST API)

8. Common pitfalls

• "PRs don't come" = mostly a misunderstanding of settings. Version updates need dependabot.yml; vulnerability fixes are a settings toggle. Also check the path and indentation (YAML) of .github/dependabot.yml.
• .gitignore'ing the lockfile → tends to fall out of the security-update target. Commit the manifest/lockfile.
• open-pull-requests-limit too small → updates clog and modernization doesn't progress. Conversely, too large is a flood.
• Applying auto-merge to majors too → bringing in breaking changes unattended causes accidents. Limiting to patch/minor is the iron rule.
• auto-merge without required checks → auto-merge with no safety valve is just Russian roulette. Pair it with branch protection.
• Pickling ignore → if you ignore with "I don't want to bump it now" and forget, there's no escape when a vulnerability appears. Make it an inventory target.
• Thinking Dependabot is SAST → it looks at dependency vulnerabilities, not your own code's vulnerabilities. Don't mistake the role.

9. FAQ

Q. Is Dependabot paid? A. No. On standard runners it doesn't consume billed Actions minutes and is effectively free, both public and private. Only when running on a larger runner are you billed at the normal rate. Note that your CI that runs triggered by Dependabot's PRs consumes Actions minutes as usual.

Q. I turned on alerts but PRs for new versions don't come. A. That's normal. New-version following (version updates) only runs once you commit .github/dependabot.yml. It's a separate feature from alerts/security updates.

Q. Too many PRs and review doesn't keep up. A. Curb noise with groups (bundle) + cooldown (let it sit) + open-pull-requests-limit (cap), and CI-conditionally auto-merge patch/minor with auto-merge. Humans focus on majors.

Q. Can I update dependencies of a private registry too? A. You can. Pass credentials with registries and Dependabot secrets. For a registry inside a network unreachable from outside, run Dependabot on a self-hosted runner.

Q. Which is better, Renovate? A. If you emphasize GitHub-centric, zero-config, native security integration, Dependabot; if you need grouping flexibility, multiple Git platforms, 90+ package managers, and fine-grained scheduling, Renovate. For details, the Dependabot vs. Renovate selection guide.

Conclusion

Dependabot is not a "set it and forget it" tool but a mechanism that delivers value only once you understand the three pillars separately, curb the PR flood structurally, and operate with an SLA. It's one of the few automations that can reduce technical debt and supply-chain risk at the same time, so first turn on alerts + security updates in all repositories, and for active development, version updates + auto-merge. For the details, please head to this cluster's dedicated guides.