Dependabot for a solo dev: the grouped config I actually ship

Dependabot out of the box is unusable for a solo developer. Turn it on with default settings and you get 20–30 PRs per week — one per dependency, each requiring review, CI runs, and a merge. Nobody maintains that. You either burn hours on dependency PRs or you start ignoring them entirely.

Both outcomes are bad. Here's the config that makes Dependabot useful: 2–3 grouped PRs per week that you can review in 10 minutes.

The config

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
      day: monday
    groups:
      # Group 1: Minor and patch updates (safe to merge)
      minor-and-patch:
        update-types:
          - minor
          - patch
        exclude-patterns:
          - 'next'
          - 'react'
          - 'react-dom'
          - '@types/react'
          - '@types/react-dom'

      # Group 2: Next.js + React together (test carefully)
      next-react:
        patterns:
          - 'next'
          - 'react'
          - 'react-dom'
          - '@types/react'
          - '@types/react-dom'

    # Major versions: individual PRs (breaking changes need attention)
    # This is the default — majors are NOT grouped

    open-pull-requests-limit: 5
    reviewers:
      - your-github-username

  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: monthly
    groups:
      actions:
        patterns:
          - '*'

Why this grouping

Group 1: Minor + patch (the bulk)

Most dependency updates are minor and patch versions. Semver says these shouldn't break anything. In practice, they rarely do. Grouping them into one weekly PR means:

• One CI run instead of 20
• One review instead of 20
• One merge instead of 20

If CI passes, merge it. If it fails, check which dependency caused it — the PR description lists all updates.

Group 2: Next.js + React pinned together

Next.js and React have tight version coupling. Updating Next.js without React (or vice versa) can break your build. Grouping them ensures they update together.

These updates need more attention — read the changelog, check for breaking changes, test locally. But it's one PR to review, not four.

Majors: individual PRs

Major version bumps mean breaking changes. You want to see each one individually so you can:

1. Read the migration guide
2. Check if your code uses deprecated APIs
3. Test thoroughly
4. Merge one at a time

Grouping major updates hides which change broke your build. Keep them separate.

GitHub Actions: monthly

Action updates are low-risk and infrequent. Monthly is enough. Group them all — if CI passes, merge.

The exclude-patterns for Next.js/React

Without excluding Next.js and React from the minor-and-patch group, they'd get lumped in with everything else. A Next.js minor update often requires testing — it's not the same risk level as bumping date-fns from 3.6.0 to 3.6.1.

My weekly routine

Monday morning: Dependabot creates the grouped PRs overnight. I review them with coffee.

1. Minor + patch PR: check CI status. Green? Merge. Red? Check which dependency failed, open an issue or pin the version.
2. Next.js + React PR (if any): read the changelog, run the dev server locally for 5 minutes, check Lighthouse. Merge if clean.
3. Major PRs (if any): schedule for later in the week when I have time to handle potential breakage.

Total time: 10–15 minutes. Down from 2+ hours without grouping.

Security alerts

Dependabot security alerts are separate from scheduled updates. They trigger immediately when a vulnerability is published. These bypass the weekly schedule — and they should.

For security alerts, I have a different policy:

• Critical/High severity: fix same-day. Usually means merging the security PR or manually bumping the dependency.
• Medium severity: fix within the week.
• Low severity: batch with the next weekly PR.

What I don't use

Renovate. Renovate is more configurable than Dependabot, but that configurability is complexity. For a solo dev on 1–5 projects, Dependabot's grouping feature (added in 2023) is enough. Renovate makes sense for teams managing 50+ repos with shared config.

Auto-merge. Some teams auto-merge minor/patch updates when CI passes. I don't — I want to see what's changing, even if I merge in 10 seconds. One bad auto-merge of a subtly broken dependency costs more time than months of manual 10-second reviews.

Version pinning everything. Pinning locks you to exact versions and turns off all automatic updates. You trade "too many PRs" for "zero visibility into security vulnerabilities." Ranges with lock files (package-lock.json) give you reproducible builds without losing update visibility.

The package-lock.json question

Dependabot updates package-lock.json in its PRs. This is correct behavior — the lock file should reflect the updated versions. If you see large diffs in the lock file, that's normal for dependency trees.

The one thing to watch: if a Dependabot PR only changes package-lock.json (no package.json change), it's a transitive dependency update. These are usually safe but can occasionally cause issues. CI catches most of them.

Starting from zero

If you have a project with no Dependabot config and haven't updated dependencies in months:

1. Don't turn on Dependabot yet — you'll get 50+ PRs immediately.
2. Run npm outdated to see what's behind.
3. Manually update everything in one session: npm update for minors/patches, then major updates one at a time.
4. Fix any breakage.
5. Now turn on Dependabot with the config above. The weekly PRs will be manageable because you're starting from a clean state.

Starting from zero with Dependabot is like turning on a firehose. Update first, automate second.

Want your dependencies managed without the noise? Let's talk — I set up security-conscious development workflows on every client project.