Dependabot with Private GitHub Packages (Maven)

Publishing private artifacts is only half the job. If consumers never get notified about updates, versions drift and fixes sit unused. Dependabot can handle private packages just fine once it knows where to look and how to authenticate. This post shows the minimal, repeatable setup that made it work reliably for private Maven packages hosted on GitHub Packages.

For context, the previous write up covered publishing to a private feed. See: Private GitHub Maven Packages: A Clean, Repeatable Setup. This post focuses on consuming those private artifacts during Dependabot runs.

Goal

• Make Dependabot open pull requests when a private Maven dependency has a newer version in any repository under the same owner.
• Keep configuration small and portable.
• Use repository or organization secrets for credentials.

The dependabot.yml that works

Create .github/dependabot.yml in the consumer repository with a single registry and one update rule:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

version: 2

registries:
  maven-github:
    type: maven-repository
    url: https://maven.pkg.github.com/ORG_NAME/*
    username: ${{secrets.REPO_USER}}
    password: ${{secrets.REPO_KEY}}

updates:
  - package-ecosystem: "maven"
    directory: "/"
    registries:
      - maven-github
    schedule:
      interval: "daily"

Why this works

• The org-wide wildcard ORG_NAME/* lets Dependabot resolve packages from any private repository under the owner. Without it, Dependabot only searches one repository and will miss artifacts that live elsewhere.
• Credentials are read from secrets so no tokens land in the repo. Use repository or organization secrets named REPO_USER and REPO_KEY to match the file above.

That is the entire configuration. No extra services, no custom workflows, and no additional token plumbing.

Secrets to provide

Add two secrets to the consumer repository or at the organization level so multiple repos can reuse them:

• REPO_USER → a GitHub username that has permission to read the private packages
• REPO_KEY → a Personal Access Token with scopes repo and read:packages

Store them under Settings → Secrets and variables → Dependabot or Actions. The file references them as ${{secrets.REPO_USER}} and ${{secrets.REPO_KEY}}.

Verification steps

1. Commit the .github/dependabot.yml file on main.
2. In Insights → Dependency graph → Dependabot, trigger an update run or wait for the next scheduled run.
3. Watch the Dependabot tab or the Pull requests list. For out-of-date private dependencies, Dependabot should open PRs that point to the latest versions it finds in the private feed or Maven Central.
4. If nothing appears, check the Dependabot logs for the last run. Common signals include authentication failures and repository not found errors.

Common pitfalls and fixes

• Missing wildcard
  If the registry URL ends at ORG_NAME/REPO, Dependabot will only check that single repository. Use ORG_NAME/* to search across all repos under the owner.

• Wrong secret names
  The names in your secrets page must match what you put in dependabot.yml. If you prefer different names, update the file accordingly.

• Insufficient token scopes
  If the logs show 401 Unauthorized, confirm the token used for REPO_KEY has repo and read:packages scopes and that the user in REPO_USER can access the private repos that host the packages.

• Directory mismatch
  directory: "/" assumes the pom.xml is at the repo root. If your Maven project lives in a subfolder, change the directory path.

• Rate limiting
  If you hit API limits during large updates, rerun later or stagger updates by temporarily switching to weekly while you clear the backlog.

Keeping it maintainable

• Keep the registry name stable across repos, for example maven-github. That way the same snippet can be reused everywhere with only the owner name changed.
• Prefer organization secrets for REPO_USER and REPO_KEY so you do not repeat setup across many repositories.
• Review and merge Dependabot PRs promptly. Smaller, frequent bumps are easier to test and roll back than large version jumps.

What you get

With this one file in place, Dependabot will check both Maven Central and your private GitHub Packages feed each day. When a private library publishes a new version, consumer repositories receive a pull request with the updated version. No manual checks, no custom jobs, and no extra infrastructure.

Thanks for reading. If you have a tighter configuration for multi module Maven repos or a good pattern for grouping related Dependabot PRs, share it so others can benefit.