Dependabot

# Dependabot Configuration & Management

Overview

Dependabot is GitHub's built-in dependency management tool with three core capabilities:

1. **Dependabot Alerts** — Notify when dependencies have known vulnerabilities (CVEs)

2. **Dependabot Security Updates** — Auto-create PRs to fix vulnerable dependencies

3. **Dependabot Version Updates** — Auto-create PRs to keep dependencies current

All configuration lives in a **single file**: `.github/dependabot.yml` on the default branch. GitHub does **not** support multiple `dependabot.yml` files per repository.

Configuration Workflow

Follow this process when creating or optimizing a `dependabot.yml`:

Step 1: Detect All Ecosystems

Scan the repository for dependency manifests. Look for:

| Ecosystem | YAML Value | Manifest Files |

|---|---|---|

| npm/pnpm/yarn | `npm` | `package.json`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock` |

| pip/pipenv/poetry/uv | `pip` | `requirements.txt`, `Pipfile`, `pyproject.toml`, `setup.py` |

| Docker | `docker` | `Dockerfile` |

| Docker Compose | `docker-compose` | `docker-compose.yml` |

| GitHub Actions | `github-actions` | `.github/workflows/*.yml` |

| Go modules | `gomod` | `go.mod` |

| Bundler (Ruby) | `bundler` | `Gemfile` |

| Cargo (Rust) | `cargo` | `Cargo.toml` |

| Composer (PHP) | `composer` | `composer.json` |

| NuGet (.NET) | `nuget` | `*.csproj`, `packages.config` |

| .NET SDK | `dotnet-sdk` | `global.json` |

| Maven (Java) | `maven` | `pom.xml` |

| Gradle (Java) | `gradle` | `build.gradle` |

| Terraform | `terraform` | `*.tf` |

| OpenTofu | `opentofu` | `*.tf` |

| Helm | `helm` | `Chart.yaml` |

| Hex (Elixir) | `mix` | `mix.exs` |

| Swift | `swift` | `Package.swift` |

| Pub (Dart) | `pub` | `pubspec.yaml` |

| Bun | `bun` | `bun.lockb` |

| Dev Containers | `devcontainers` | `devcontainer.json` |

| Git Submodules | `gitsubmodule` | `.gitmodules` |

| Pre-commit | `pre-commit` | `.pre-commit-config.yaml` |

Note: pnpm and yarn both use the `npm` ecosystem value.

Step 2: Map Directory Locations

For each ecosystem, identify where manifests live. Use `directories` (plural) with glob patterns for monorepos:

directories:
  - "/"           # root
  - "/apps/*"     # all app subdirs
  - "/packages/*" # all package subdirs
  - "/lib-*"      # dirs starting with lib-
  - "**/*"        # recursive (all subdirs)

Important: `directory` (singular) does NOT support globs. Use `directories` (plural) for wildcards.

Step 3: Configure Each Ecosystem Entry

Every entry needs at minimum:

- package-ecosystem: "npm"
  directory: "/"
  schedule:
    interval: "weekly"

Step 4: Optimize with Grouping, Labels, and Scheduling

See sections below for each optimization technique.

Monorepo Strategies

Glob Patterns for Workspace Coverage

For monorepos with many packages, use glob patterns to avoid listing each directory:

- package-ecosystem: "npm"
  directories:
    - "/"
    - "/apps/*"
    - "/packages/*"
    - "/services/*"
  schedule:
    interval: "weekly"

Cross-Directory Grouping

Use `group-by: dependency-name` to create a single PR when the same dependency updates across multiple directories:

groups:
  monorepo-deps:
    group-by: dependency-name

This creates one PR per dependency across all specified directories, reducing CI costs and review burden.

Limitations:

- All directories must use the same package ecosystem

- Applies to version updates only

- Incompatible version constraints create separate PRs

Standalone Packages Outside Workspaces

If a directory has its own lockfile and is NOT part of the workspace (e.g., scripts in `.github/`), create a separate ecosystem entry for it.

Dependency Grouping

Reduce PR noise by grouping related dependencies into single PRs.

By Dependency Type

groups:
  dev-dependencies:
    dependency-type: "development"
    update-types: ["minor", "patch"]
  production-dependencies:
    dependency-type: "produ