GitHub has announced repository-level runner settings for Dependabot version and security updates. Administrators of eligible private and internal repositories on GitHub.com can now choose between the standard GitHub-hosted environment and a labeled runner, with optional runner-group selection.
The change gives teams more control over where Dependabot jobs execute. That can be useful when update jobs need access to internal package registries or a controlled execution environment, but it also makes runner permissions, network access, and repository policies more important operational considerations.
What changed for Dependabot
Runner configuration was previously available at the organization level. The new repository-level controls allow administrators to configure the setting for an individual repository through Settings > Advanced Security > Dependency scanning > Dependabot version updates, where they can edit Runner type.
The available choices are:
- Standard GitHub runner: Uses the default GitHub-hosted environment.
- Labeled runner: Allows an administrator to provide an optional custom runner label and select an optional runner group.
If no custom label is supplied, Dependabot uses the dependabot label. The selected runner must have the relevant label, and any selected runner group must exist and permit access from the repository.
GitHub’s announcement says labeled runners can target self-hosted runners and larger GitHub-hosted runners. The related documentation also notes that larger Dependabot runners can be enabled only for an organization. Larger runners may provide additional resources for jobs affected by timeouts or out-of-memory errors, but the documented 55-minute update-job limit remains unchanged.
Who can use the repository setting
The repository-level controls are available for private and internal repositories hosted on GitHub.com. GitHub says the controls are hidden for public repositories and GitHub Enterprise Server.
The supplied documentation does not establish whether every eligible repository receives the feature immediately or whether availability varies by account or plan beyond those stated restrictions. It also does not document a staged rollout schedule.
Dependabot must be enabled, and GitHub Actions must be enabled and in use when configuring Dependabot on self-hosted runners. A repository with Dependabot enabled but GitHub Actions disabled continues using the built-in Dependabot application rather than Dependabot running through GitHub Actions.
Requirements for self-hosted runners
Teams selecting a self-hosted runner need to prepare more than a matching label. The Dependabot on GitHub Actions documentation specifies a Linux x64 virtual machine with Docker, along with network access to the public internet, GitHub.com, and any internal registries required for the update.
Security-update jobs also require outbound access to dependabot-actions.githubapp.com. Environments that use registries with self-signed certificates may need additional certificate handling and Node.js certificate configuration.
These requirements make runner placement and egress policy part of the implementation. A self-hosted environment that cannot reach the required services or internal registries may not be able to complete Dependabot jobs, even when its label and runner-group assignment are correct.
Runner groups add an access-control decision
Runner groups can restrict access to selected repositories or allow access across an organization. According to GitHub’s runner access documentation, the default policy allows private repositories to access a runner group, subject to the organization’s configured policies.
Administrators should therefore verify both sides of the configuration: the repository’s selected group and the group’s repository-access policy. A group can exist while still denying the repository access required for the Dependabot job.
GitHub documents REST API endpoints for managing organization self-hosted runner groups, including listing groups visible to a repository, creating groups, and managing membership. However, the supplied API documentation does not provide an endpoint for changing the repository-level Dependabot runner setting itself. Teams should not assume that runner-group API support also provides an automation interface for the repository setting.
Security and network considerations
Routing Dependabot jobs to a self-hosted environment can make internal resources available to those jobs, which is useful for private registries but requires careful network design. GitHub’s documentation recommends limiting the virtual machine’s access to the internal network to reduce potential damage from a hijacked dependency.
The same documentation says Dependabot-triggered GitHub Actions workflows have read-only GITHUB_TOKEN permissions by default for the documented events. GitHub Actions secrets are unavailable to these workflows; Dependabot secrets are used instead.
Runner-group policies should be reviewed alongside repository visibility. The documentation recommends using self-hosted runners only with private repositories because public forks can execute potentially dangerous code on those runners. GitHub-hosted runner IP addresses should also not be used as authentication for private registries, because those addresses are not exclusive to GitHub.
The announcement separately states that security configurations do not currently enforce Dependabot runner settings. The supplied sources do not define the exact scope of that limitation, so teams should treat it as an announced configuration caveat rather than infer broader behavior.
Operational implications
The repository setting is most useful when different repositories need different execution environments. One project may remain on the standard GitHub-hosted runner, while another can use a labeled self-hosted runner with access to an internal registry or specialized tooling.
Administrators should also account for timing: changing the runner setting does not trigger a new Dependabot run. The change affects subsequent job execution rather than immediately starting an update.
Organization-level configuration remains relevant. The documentation says organization-level self-hosted configuration can update existing private repositories on their next Dependabot job and can enable the feature for new repositories. However, the supplied sources do not document precedence or migration behavior when organization-level and repository-level settings overlap. The repository control should therefore not be described as a documented migration mechanism.
What you should do
- Confirm that the repository is private or internal and hosted on GitHub.com.
- Verify that Dependabot and GitHub Actions are enabled if the repository will use Dependabot on Actions runners.
- Open the repository’s Dependabot version-update settings and review the Runner type selection.
- For a labeled runner, confirm that the intended runner has the selected label. If no custom label is entered, prepare a runner with the
dependabotlabel. - If using a runner group, verify that the group exists and that its repository-access policy permits the repository.
- For self-hosted execution, validate the Linux x64, Docker, network, registry, and certificate requirements before relying on the setting.
- Review workflow permissions, Dependabot secrets, network isolation, and repository visibility before assigning internal resources to update jobs.
- Remember that changing the setting does not start a new Dependabot run, and do not assume the runner selection can currently be changed through the documented REST API.
Repository-level runner selection gives administrators finer control over Dependabot execution without requiring every repository to use the same environment. Its practical value depends on correctly matching labels, runner-group policies, network access, and the security boundaries of the selected runner.
Sources
- GitHub Changelog: Repository custom runner settings for Dependabot
- GitHub documentation: Configure Dependabot on self-hosted runners
- GitHub documentation: Dependabot on GitHub Actions
- GitHub documentation: Manage access to self-hosted runners
- GitHub documentation: Configure Dependabot on GitHub-hosted runners
- GitHub REST API documentation: Self-hosted runner groups
