A dark infographic shows a GitHub repository automated by a bot and deployed to cloud servers and databases.
GitHub has added per-repository runner selection for Dependabot, giving administrators of eligible repositories a choice about where version-update and security-update jobs execute. An organization can already configure Dependabot runners centrally; the new control lets a repository use a runner arrangement suited to its own dependencies and infrastructure.

That distinction matters when one project needs access to a private package registry while another is content with GitHub’s standard hosted environment. A labeled runner can direct jobs to a matching self-hosted runner or larger GitHub-hosted runner. Selecting Standard GitHub runner instead uses the default GitHub-hosted environment. The setting chooses where Dependabot runs; it does not provision a runner or grant one access to internal resources.

Who gets the new control?​

GitHub says the repository-level settings are available for private and internal repositories on GitHub.com. The controls are hidden for public repositories and are unavailable on GitHub Enterprise Server. That is a boundary on this new settings interface, not an announcement of a new Dependabot configuration option for public repositories.

How to select a runner​

Before choosing a self-hosted runner, GitHub’s documentation says Dependabot must be installed and enabled, GitHub Actions must be enabled and in use, and the runner environment must meet Dependabot’s requirements. Assign the intended label to a runner first; if you plan to specify a runner group, verify that it exists and that the repository can access it.

For an eligible repository:

  1. Open the repository’s Settings, then Advanced Security.
  2. Under Dependency scanning, find Dependabot version updates and edit Runner type.
  3. Select Labeled runner, optionally entering a custom label and runner group, then save the selection. If you leave the label blank, Dependabot uses dependabot.
  4. Alternatively, select Standard GitHub runner for the default hosted environment.

Do not expect an immediate update run. GitHub’s setup documentation explicitly says changing the runner setting does not trigger a new Dependabot run. If the control cannot be changed, an organization restriction on actions or self-hosted runners may be the reason; GitHub advises contacting the organization owner.

What administrators should watch​

Runner placement has operational consequences beyond the settings screen. GitHub says Dependabot jobs on standard hosted or self-hosted runners do not count toward included GitHub Actions minutes, while jobs on larger runners are billed at the organization’s regular rate. A self-hosted choice also means the team must keep a suitable runner available and maintain the access its dependency jobs require.

If an update does not complete, inspect Dependabot’s runs in the repository’s Actions tab and open the run logs. GitHub generates these as dynamic workflows for individual jobs, so searching for a conventional workflow file in .github/workflows is the wrong first troubleshooting step.

Finally, this is a repository setting, not a new dependabot.yml runner key or a centrally enforced security policy. GitHub explicitly says security configurations do not currently enforce Dependabot runner settings. For teams that rely on those configurations for consistency, runner choices therefore warrant a separate administrative check.

 

References

  1. Repository custom runner settings for Dependabot GitHub Changelog 2026-09-29T19:10:00+00:00
  2. Configuring Dependabot on self-hosted runners - GitHub Docs docs.github.com
  3. Dependabot on GitHub Actions runners - GitHub Docs docs.github.com