Setting Up a Private Package Mirror for Credential-Free Dependabot Access

Many development teams maintain private package feeds to share internal libraries across applications. A .NET team, for example, might publish common logging components, authentication helpers, and reusable business libraries to an internal NuGet feed.

The problem often appears when Dependabot tries to update these dependencies. Developers can restore packages on their own machines, but Dependabot may fail because it cannot reach the package feed or does not have the required credentials.

One option is to create and maintain tokens for automated dependency updates. However, this adds another credential to manage, rotate, and troubleshoot.

A different approach works when the organization has a package mirror that allows anonymous, read-only access. In that situation, Dependabot can access the mirror without a username, password, or personal access token.

GitHub now supports an Anonymous authentication option for organization-level private registry configurations. This makes it easier to configure credential-free access for registries that genuinely support it.

The important point is that anonymous access does not make a private registry anonymous automatically. The registry administrator must configure the feed to permit the intended reads, and Dependabot must be able to reach the host.

What Is a Private Package Mirror?

A package mirror is an internal endpoint that provides packages from an upstream package source or an organization's own package collection.

Instead of allowing every application to depend directly on multiple external feeds, a team can configure its build and dependency-management tools to use a central mirror.

For example, a .NET organization might maintain a NuGet mirror containing:

Approved third-party packages.
Internal libraries shared between applications.
Cached packages used by several development teams.
Packages retained for reproducible builds.

A mirror can simplify package management, but it does not automatically provide access control. The organization must decide whether the feed requires authentication, allows anonymous reads, or is available only from a restricted network.

For Dependabot, the distinction is important because a registry can be private to an organization while still allowing read-only access to anyone who can reach a particular endpoint.

How Credential-Free Access Works

Consider a team with an internal NuGet mirror that allows read-only access without credentials. Developers can restore packages from the mirror, but Dependabot needs its own registry configuration to access the same host.

There are three separate requirements.

Registry permissions: The mirror must allow the package metadata and package downloads needed by Dependabot without authentication.

Dependabot configuration: The registry must be declared in dependabot.yml or configured through the appropriate organization-level private registry settings.

Network access: Dependabot must be allowed to connect to the registry host.

All three must be satisfied. Removing credentials from the configuration will not help if the registry still requires authentication or the host is blocked.

It is also important to distinguish this setup from GitHub Packages. For supported private packages hosted in GitHub Packages, Dependabot can use its GitHub-provided token when the repository has the required package permissions. That is authenticated access without a separately managed personal access token, not anonymous access.

Step 1: Prepare the Private NuGet Mirror

Before configuring GitHub, confirm that the package mirror is suitable for anonymous access.

For this example, assume the organization operates a NuGet feed at:

https://packages.example.internal/nuget/v3/index.json

This is an illustrative address. Replace it with the actual endpoint provided by your package administrator.

First, verify that the mirror supports anonymous read access. A basic connectivity check can be performed with:

curl --fail --silent --show-error \
  --output /dev/null \
  --write-out "HTTP status: %{http_code}\n" \
  "https://packages.example.internal/nuget/v3/index.json"

The command reports the HTTP status returned by the endpoint.

A successful response indicates that the endpoint is reachable from the machine running the command. It does not prove that every package can be downloaded anonymously, and it does not establish that Dependabot can reach the same host from GitHub's environment.

Check that the feed exposes the package metadata and package files required by your applications. If the feed redirects requests to another host, verify that the redirected host is also accessible to the intended client.

Do not enable anonymous reads on a feed containing confidential packages simply to make automated updates work. If package access must remain restricted, use a supported authentication method instead.

Step 2: Configure Dependabot in the Repository

Once the mirror is ready, configure the repository's .github/dependabot.yml file.

The following example uses the NuGet package ecosystem:

version: 2

registries:
  internal-nuget:
    type: nuget-feed
    url: https://packages.example.internal/nuget/v3/index.json

updates:
  - package-ecosystem: nuget
    directory: "/"
    registries:
      - internal-nuget
    schedule:
      interval: weekly

This configuration tells Dependabot which package ecosystem to inspect and which registry it may use.

Here is what each section does.

version: 2 specifies the Dependabot configuration format.
registries declares the package source that Dependabot needs to access.
internal-nuget is a name chosen for this registry entry.
type: nuget-feed identifies the registry as a NuGet feed.
url specifies the feed endpoint.
package-ecosystem: nuget enables dependency updates for NuGet dependencies.
directory: "/" identifies the repository directory where Dependabot should look for dependency manifests.
registries under updates grants this update configuration access to the named registry.
schedule determines how frequently Dependabot checks for version updates.

Notice that the registry entry contains no username, password, or token. That is intentional because this example assumes the feed allows anonymous reads.

If the project stores its NuGet manifests in a subdirectory, change directory to the appropriate path. Repositories with multiple projects may need additional update entries for other directories.

Important: Declaring the registry in dependabot.yml is necessary even when the feed allows anonymous access. Dependabot uses its registry configuration to determine which hosts it may reach. Merely adding the feed to nuget.config does not grant the Dependabot update job network access to that host.

Step 3: Configure an Organization-Level Registry

If several repositories use the same mirror, maintaining the same registry configuration repeatedly can become difficult.

Organization-level private registry settings provide a centralized option.

An organization administrator can follow these steps:

Open the GitHub organization's settings.
Navigate to Secrets and variables, then Private registries.
Select New private registry.
Choose the appropriate registry type and enter the mirror's endpoint.
Select Anonymous as the authentication method.
Grant access to the repositories that need the registry.
Save the configuration and test a representative repository.

The exact options available depend on the registry type and GitHub environment.

An organization-level registry is particularly useful when many repositories share the same feed. It can also help with repositories that use Dependabot security updates but do not have a dependabot.yml file.

If an existing organization-level registry was created using a placeholder token as a workaround, GitHub's documented approach is to delete that entry and create a new one with Anonymous authentication. The authentication method cannot simply be changed on the existing registry.

For repositories using ordinary Dependabot version updates, continue to review the repository configuration and ensure that the update job is allowed to use the required registry.

Step 4: Test the Configuration

Do not assume the setup is complete simply because the YAML file is accepted.

Run through a controlled test before rolling out the configuration across the organization.

Select a repository that uses a package available in the mirror.
Confirm that the registry is declared in the Dependabot configuration.
Trigger or wait for a dependency update run.
Open the Dependabot job logs and inspect any registry errors.
Verify that the package metadata and required package files can be retrieved.
Confirm that Dependabot can identify available updates and create the expected pull request.

If the repository contains both public and private dependencies, test both types. Access to the private mirror does not automatically mean that all other package sources are configured correctly.

A useful test is to choose a dependency whose available versions are known. This makes it easier to distinguish a registry access problem from a dependency that simply has no newer version.

Advantages and Disadvantages

Advantages

Fewer credentials to maintain: An anonymously readable mirror does not require a separate token for Dependabot.

Simpler configuration: Registry entries can be shared across repositories through organization-level settings.

Less token-related maintenance: Teams avoid failures caused specifically by expired or incorrectly configured credentials for that mirror.

Centralized package management: An internal mirror can provide a consistent package source for multiple applications.

Disadvantages

Access must be designed carefully: Anonymous reads may expose packages to anyone who can reach the feed.

Network restrictions still apply: Dependabot cannot access a blocked host merely because the registry configuration is valid.

Not every private feed supports anonymous access: Some registries require authentication and must continue using an appropriate credential-based method.

Additional testing is necessary: Developers must validate the registry, package downloads, and update workflow before relying on the configuration.

Common Mistakes and Troubleshooting

Problem	Likely cause	What to check
Dependabot receives an authentication error	The mirror still requires credentials	Test anonymous access to package metadata and package downloads
Dependabot reports that the host is blocked	The registry is missing from the allowed host configuration	Declare the registry in `dependabot.yml` or configure it through the supported organization settings
The configuration is valid, but packages cannot be restored	The endpoint or package download host is inaccessible	Check redirects, package URLs, DNS, and network restrictions
Organization-level configuration does not work as expected	The repository has not been granted access to the registry	Review the registry's repository access settings
Updates fail after removing a token	The feed is not actually anonymous, or another registry still needs authentication	Check which source provides the failing dependency
Public packages update, but internal packages do not	The private registry is missing or inaccessible	Review the registry entry and Dependabot job logs

When troubleshooting, identify the failing stage first. A YAML configuration problem, an HTTP authentication failure, a blocked host, and a missing package version are different issues. Treating them as the same problem usually wastes time.

Best Practices for Production Repositories

Allow anonymous access only when the package mirror's contents and exposure are understood.
Keep internal packages containing confidential code behind appropriate access controls.
Use HTTPS for registry endpoints.
Grant organization-level registry access only to repositories that need it.
Test both package metadata retrieval and package downloads.
Review Dependabot logs when an update fails rather than immediately adding credentials.
Use token-based or supported OIDC authentication when the registry requires an authenticated identity.
Document who owns the mirror and how its permissions are managed.

A credential-free configuration should reduce unnecessary secrets, not weaken the organization's package security.

Summary

A private package mirror can simplify Dependabot configuration when it intentionally supports anonymous, read-only access. The setup requires a working mirror, a registry declaration in Dependabot's configuration or supported organization-level settings, and network access from the update job.

The most important step is to verify that the mirror really permits the required anonymous operations. If it does not, use an appropriate authentication method rather than removing credentials blindly.

For teams managing many .NET repositories, organization-level private registry configuration can reduce duplicated setup and make dependency management easier to maintain. Test the configuration with real dependency updates, review the logs, and keep package access controls aligned with the sensitivity of the packages being served.