How to enable Dependabot version updates

Outdated dependencies are one of the most common ways vulnerabilities slip into production. A single unpatched npm package or Python library can sit quietly in your codebase for months until it becomes the entry point for an attacker. The good news is that GitHub ships a built-in fix: Dependabot. This guide walks you through how to enable Dependabot version updates on any repository, from writing your first dependabot.yml configuration to verifying that pull requests are actually showing up. By the end, you'll have automated dependency updates running on a schedule you control, catching outdated packages before they become security incidents, without needing a third-party tool or a manual audit process.

Dependabot version updates are different from Dependabot security updates, which only fire when GitHub's advisory database flags a known vulnerability. Version updates run continuously, keeping every dependency in your manifest close to its latest release — which is exactly what shrinks your exposure window in the first place.

Step 1: Understand What Dependabot Version Updates Actually Do

Before touching any config, it helps to know what you're turning on. Dependabot version updates scan your dependency manifests (package.json, requirements.txt, go.mod, Gemfile, pom.xml, and dozens of others) on a schedule you define, compare installed versions against what's published in the relevant registry, and open pull requests to bump outdated packages. This is distinct from security-only alerts: version updates keep you current proactively, rather than reactively waiting for a CVE to be disclosed against something you're already running. Teams that only rely on security updates tend to accumulate a large amount of version drift, which makes every future upgrade riskier and more likely to break something. Enabling version updates keeps that drift small and each individual pull request easy to review.

Step 2: Enable Dependabot Version Updates for Your Repository

GitHub Dependabot setup starts in your repository settings, not in a config file. Navigate to your repository, then:

1. Go to Settings → Code security and analysis.
2. Confirm Dependency graph is enabled — Dependabot version updates require it to resolve your dependency tree.
3. Look for Dependabot alerts and Dependabot security updates; these are optional but worth enabling alongside version updates for full coverage.

Unlike security updates, version updates don't have a toggle switch in the UI — they're activated purely by the presence of a dependabot.yml file in your repository. So the real "enable" step is creating that file, which is what the rest of this guide covers. If you're rolling this out across an organization, GitHub also lets admins enforce dependency graph and Dependabot settings at the org level under Settings → Code security and analysis, so individual repos can't opt out silently.

Step 3: Create the dependabot.yml Configuration File

Dependabot reads its instructions from a single YAML file at .github/dependabot.yml. Create the directory and file if they don't already exist:

mkdir -p .github
touch .github/dependabot.yml

A minimal dependabot.yml configuration for a Node.js project looks like this:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

The three required fields are package-ecosystem (npm, pip, docker, gomod, maven, cargo, github-actions, and more), directory (where the manifest lives relative to the repo root), and schedule.interval (daily, weekly, or monthly). If you have multiple ecosystems — say a Node frontend and a Python backend — add multiple entries under updates:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/frontend"
    schedule:
      interval: "weekly"
  - package-ecosystem: "pip"
    directory: "/backend"
    schedule:
      interval: "weekly"
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "monthly"

That last entry is easy to forget but important: GitHub Actions workflows pin third-party actions by version tag or SHA, and those need updating too — it's one of the more overlooked corners of automated dependency updates.

Step 4: Tune the Update Schedule and Pull Request Volume

Left at defaults, Dependabot can flood a busy repo with pull requests. Control the volume with open-pull-requests-limit and be specific about timing with day and time:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "06:00"
      timezone: "America/New_York"
    open-pull-requests-limit: 10

For ecosystems with many small transitive updates, grouping is worth setting up so related packages land in one pull request instead of twenty:

    groups:
      dev-dependencies:
        dependency-type: "development"
      production-dependencies:
        dependency-type: "production"

Grouping doesn't reduce your security coverage — it just makes the resulting PRs more reviewable, which in practice means they get merged faster instead of piling up unreviewed.

Step 5: Set Reviewers, Labels, Ignore Rules, and Commit Preferences

Once the schedule is dialed in, layer on routing so the right people see the right PRs:

    reviewers:
      - "platform-team"
    labels:
      - "dependencies"
      - "automated"
    commit-message:
      prefix: "deps"
      include: "scope"
    ignore:
      - dependency-name: "legacy-sdk"
        versions: ["4.x"]

The ignore block is useful when a specific dependency has a known-breaking major version you're not ready to adopt, or when a package is being deprecated in favor of a migration you're tracking separately. Avoid over-using it, though — every ignored dependency is a manifest entry that silently ages out of your automated coverage.

Step 6: Commit, Push, and Confirm Dependabot Picks It Up

Commit the file to your default branch:

git add .github/dependabot.yml
git commit -m "Enable Dependabot version updates"
git push origin main

Dependabot doesn't require a merge to a specific branch name beyond whatever your repository's default branch is set to. Within a few minutes of the push, GitHub validates the file. You can check parsing status under Insights → Dependency graph → Dependabot, where GitHub will surface a clear error message if the YAML is malformed or references an unsupported ecosystem.

Verifying Dependabot Is Actually Running

A config file existing isn't the same as it working. Confirm the setup with these checks:

• Insights tab: Go to Insights → Dependency graph → Dependabot to see the last time each ecosystem was checked and whether there were parsing errors.
• Manual trigger: On the same Dependabot tab, each configured update has a "Last checked" timestamp and a manual Check for updates button — use it to force an immediate run rather than waiting for the next scheduled interval.
• Pull requests: If any dependency is genuinely out of date, you should see a PR appear titled something like Bump lodash from 4.17.19 to 4.17.21 within one check cycle.
• No PRs appearing: This usually means either every dependency is already current (good news), the directory path doesn't match where your manifest actually lives, or open-pull-requests-limit is set to 0.
• YAML errors: Indentation mistakes are the most common failure. Validate locally with yamllint .github/dependabot.yml or a YAML linter in your editor before pushing.
• Ecosystem not supported: Double-check the exact package-ecosystem string against GitHub's documentation — values are case-sensitive and some ecosystems (like docker-compose versus docker) are easy to mix up.
• Private registries: If your manifest pulls from a private npm or PyPI registry, Dependabot needs credentials configured separately under repository secrets and referenced via a registries block, or the update PRs will fail during dependency resolution.

How Safeguard Helps

Enabling Dependabot version updates is a strong first step, but a single repository's dependabot.yml only tells part of the story. Safeguard gives security and platform teams visibility across every repository at once — flagging which repos are missing Dependabot configuration entirely, which have version updates enabled but no security updates, and which have accumulated ignore rules that are quietly masking risk. Instead of manually auditing dependency graphs repo by repo, Safeguard continuously monitors your software supply chain, correlates dependency data with real exploitability signals, and prioritizes the updates that actually reduce risk — so your team spends less time triaging noisy pull requests and more time closing the gaps that matter. If you're rolling out automated dependency updates across dozens or hundreds of repositories, Safeguard is built to make that rollout consistent, auditable, and provable for compliance frameworks like SOC 2 that expect evidence your dependency management program is actually working.