# Dependabot production-operations guide: separate alerts, security updates, and version updates into the 'three pillars' to keep dependencies automatically and safely up to date > An implementation guide to operating GitHub's Dependabot at production quality. Faithful to the official documentation (as of June 2026), it explains — with copy-pasteable real code and a project viewpoint — the differences and proper use of the three pillars (Dependabot alerts / security updates / version updates), how to enable them, practical dependabot.yml settings, where it runs (Actions runners) and billing, auto-merge and grouping, and operations design with an SLA. - Published: 2026-06-28 - Author: 友田 陽大 - Tags: Dependabot, GitHub Actions, サプライチェーンセキュリティ, 依存関係管理, DevSecOps, セキュリティ - URL: https://tomodahinata.com/en/blog/dependabot-production-guide - Category: Dependabot & dependency automation ## Key points - Dependabot is not a single feature but three pillars: 'alerts (detecting vulnerabilities),' 'security updates (PRs that fix vulnerabilities),' and 'version updates (PRs that bring stale deps up to date).' Separating these three in your head first is the starting point of operations. - Alerts and security updates are turned ON in repository settings. Version updates only run once you commit dependabot.yml. Conflate them and you'll surely get stuck on 'why don't PRs come.' - Dependabot updates run on GitHub Actions runners, but on standard runners (GitHub-hosted / self-hosted) they don't consume billed Actions minutes = effectively free. Reach registries inside a private network with a self-hosted runner. - Curb the PR flood structurally with 'groups (bundle into PRs),' 'cooldown (wait right after a release),' and 'open-pull-requests-limit.' auto-merge safely auto-merges only patch/minor with GitHub Actions and fetch-metadata. - Introducing the tool ≠ operations. Who reviews, what is auto-merged, how majors are inventoried, how stale PRs are reduced — only once you decide the SLA and exception rules does supply-chain technical debt stop growing. --- 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](https://docs.github.com/en/code-security/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](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-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](/blog/dependabot-yml-configuration-complete-guide) - Vulnerability-response operations → [Dependabot alerts / security updates / vulnerability management guide](/blog/dependabot-security-updates-alerts-vulnerability-management-guide) - Auto-merge → [auto-merge × GitHub Actions automation guide](/blog/dependabot-auto-merge-github-actions-automation-guide) - Tool selection → [Dependabot vs. Renovate selection guide](/blog/dependabot-vs-renovate-comparison-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. | Feature | What it does | What enables it | Is dependabot.yml needed | | --- | --- | --- | --- | | **Dependabot alerts** | notifies when a dependency in the dependency graph has a **known vulnerability**. Doesn't change code | turn ON in the repository/organization **security settings** | not needed | | **Dependabot security updates** | among alerts, **automatically opens PRs** that fix **those with an existing patch** | turn ON in security settings (alerts are a prerequisite) | not needed (if present, you can tune behavior) | | **Dependabot version updates** | regardless of vulnerabilities, opens **PRs** that keep **stale deps following the latest** | only runs once you **commit `dependabot.yml`** | **required** | 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. ```text [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. | Your situation | Recommended pillars | | --- | --- | | I just don't want to miss vulnerabilities | alerts + security updates | | I want to follow the latest libraries periodically | + version updates (dependabot.yml) | | Too many PRs and review doesn't keep up | groups + cooldown + open-pull-requests-limit + auto-merge | | A Git platform other than GitHub, or 90+ package managers | [also evaluate Renovate](/blog/dependabot-vs-renovate-comparison-guide) | --- ## 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](https://github.com/advisories) 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. ```yaml # .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](/blog/dependabot-yml-configuration-complete-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. ```yaml 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](/blog/dependabot-yml-configuration-complete-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. ```yaml 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). ```yaml # .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](/blog/dependabot-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](/blog/dependabot-security-updates-alerts-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](/blog/web-application-vulnerability-assessment-owasp-zap-sast-dast-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](/blog/dependabot-vs-renovate-comparison-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.