Run Dependabot on Repository-Specific Runners: Labels, Groups and Security

GitHub now lets repository administrators choose the runner type, custom label, and optional runner group used by Dependabot version and security updates. The repository-level control is useful when one project needs private-registry access or larger hardware without forcing every repository in the organization onto the same runner pool.

The feature is available for private and internal repositories on GitHub.com. It is hidden for public repositories and GitHub Enterprise Server, and organization security configurations do not currently enforce these repository runner settings.

When a custom Dependabot runner is useful

Use a labeled runner when Dependabot needs something the standard hosted environment cannot safely reach:

• a package registry available only on a private network;
• a self-signed corporate certificate authority;
• a large monorepo that exhausts standard runner memory;
• an Actions Runner Controller pool with controlled egress;
• a repository-specific network or compliance boundary.

Do not move Dependabot to an internal runner merely for consistency. Dependency update jobs process code and packages from outside your network. A compromised dependency can become hostile input, so the runner should have the smallest possible network reach.

Configure the repository setting

In the repository, open Settings → Advanced Security. Under Dependency scanning, edit the runner type for Dependabot version updates. Choose one of:

• Standard GitHub runner for the default hosted environment.
• Labeled runner to target a self-hosted or larger GitHub-hosted runner.

When using a labeled runner, enter an optional custom label and runner group. If you omit the label, Dependabot uses dependabot.

Before saving, verify at least one online runner matches both the label and group. Otherwise Dependabot update jobs can remain queued indefinitely.

Provision a dedicated runner pool

For a self-hosted design, use Linux x64 with Docker available to the runner user. GitHub recommends rootless Docker where practical. Keep Dependabot runners separate from production deployment runners.

Useful labels might include:

self-hosted
linux
x64
dependabot-payments

The custom label should describe the security boundary, not only the tool. A label such as dependabot-payments makes it harder for unrelated repositories to accidentally select a runner with payment-registry access.

Restrict the runner group to the repositories that actually need it. A group restriction and a unique label provide two independent placement controls.

Network design

Dependabot runners need access to GitHub.com, the public internet required by supported ecosystems, and any internal registries referenced by the repository. GitHub also documents outbound access to dependabot-actions.githubapp.com for security update jobs.

Start with deny-by-default egress where your platform supports it. Permit only:

• GitHub endpoints required by Actions and Dependabot;
• approved public package registries;
• explicitly authorized internal registries;
• DNS, time synchronization, certificate validation, and observability endpoints.

Do not give the runner broad access to production databases, cluster administration endpoints, or cloud metadata credentials. A dependency updater needs package metadata and repository access—not your runtime control plane.

Credentials and certificates

Store private-registry credentials as Dependabot secrets, not ordinary Actions secrets. Workflows triggered by Dependabot have special permission behavior: GITHUB_TOKEN is read-only by default, and GitHub Actions secrets are not exposed in the same way as Dependabot secrets.

For a registry using a private certificate authority, install the CA certificate on the runner and configure Node.js to trust it. Many Actions are JavaScript programs, and Node.js does not automatically use every operating-system certificate store configuration.

Rotate registry credentials independently of the runner image. Prefer read-only tokens scoped to package metadata and downloads. Dependabot should not receive package publish or registry administration rights.

Autoscaling with Actions Runner Controller

ARC can provide ephemeral runners for Dependabot. Ephemeral runners reduce persistence between jobs and make patching easier because each job starts from a controlled image.

Create a dedicated runner scale set and expose only the label selected in repository settings. Apply resource requests and limits that match the largest dependency ecosystem in the repository. Java, JavaScript, and large monorepo updates can have very different memory profiles.

Keep the runner image current. Dependabot runner placement does not exempt the pool from GitHub's self-hosted runner version policy. Immutable images with --disableupdate must be rebuilt within 30 days of every runner release.

Validate before switching production repositories

Use a low-risk private repository first:

1. Confirm Dependabot and GitHub Actions are enabled.
2. Provision an online runner with the selected label and group.
3. Configure a test private registry using a read-only credential.
4. Change the repository runner type to the labeled runner.
5. Trigger or re-run a Dependabot version update.
6. Filter the Actions tab for dynamic Dependabot workflows and inspect logs.
7. Verify the job reached only approved network destinations.
8. Confirm the pull request contains the expected dependency change and checks.

Dependabot workflows may appear as dynamic/dependabot/dependabot-updates; they are generated for a run rather than stored as ordinary workflow files in .github/workflows.

Common failure modes

Job remains queued: No online runner matches the label and group, or repository access to the runner group is missing.

Private registry authentication fails: The credential is stored as an Actions secret instead of a Dependabot secret, has insufficient read scope, or references the wrong registry host.

TLS verification fails: The private CA is missing from the container or Node.js trust configuration.

Update times out: The runner is undersized, the registry is slow, or the package manager downloads through an inefficient proxy. Larger runners can help with memory pressure but do not increase Dependabot's 55-minute job limit.

Public repository has no control: Repository-level labeled runners are intentionally unavailable for public repositories.

Security checklist

• Use a dedicated runner group and repository-specific label.
• Prefer ephemeral runners and clean images.
• Run Docker rootless when compatible with the ecosystem.
• Apply minimal egress and block production control planes.
• Store registry credentials as scoped Dependabot secrets.
• Install and rotate private CA certificates deliberately.
• Monitor dynamic Dependabot workflow failures and queue time.
• Patch runner images within GitHub's version window.

For fleet freshness requirements, read the self-hosted runner enforcement guide. For workflow security controls, see GitHub Actions workflow execution protections.

Want deeper hands-on GitHub Actions practice? Explore this GitHub Actions course on Udemy. Affiliate link: DevOpsBoys may earn a commission at no extra cost to you.

Sources

• GitHub Changelog: Repository custom runner settings for Dependabot
• GitHub Docs: Configure Dependabot on self-hosted runners
• GitHub Docs: Dependabot on GitHub Actions
• GitHub Docs: Self-hosted runner reference