GitHub now lets repository admins choose exactly where Dependabot jobs run. For teams with private registries and network-isolated environments, this closes a real gap — but the feature ships with some notable rough edges.
For years, Dependabot's automated dependency updates ran on GitHub's own hosted runners. That worked fine for public repos pulling packages from public registries. It didn't work so well for enterprise teams whose dependencies live behind firewalls, inside private artifact stores, or in environments requiring specialized build tooling. Organization-level runner configuration helped, but it was a blunt instrument: one setting for every repo in the org, regardless of each project's actual needs.
As of September 29, GitHub shipped repository-level custom runner settings for Dependabot, letting admins configure the runner type, a custom label, and a runner group on a per-repo basis. It's a targeted improvement, not a sweeping overhaul. But for the teams who've been waiting for it, the practical impact is significant.
What Repository-Level Runner Settings Actually Change
Before this update, Dependabot runner configuration existed only at the organization level. That meant every private and internal repo in an org shared the same runner setup. If your org had 50 repositories and only three of them needed access to a private Maven registry behind a VPN, you had two choices: route all Dependabot jobs through a self-hosted runner that could reach that registry, or accept that those three repos couldn't get automated dependency updates.
The new setting changes this calculus. The GitHub Blog changelog explains that admins can now open a repository's settings, navigate to Advanced Security under "Dependency scanning," and edit the runner type for Dependabot version updates. The options are straightforward: choose "Standard GitHub runner" for the default hosted environment, or "Labeled runner" to target a self-hosted or larger GitHub-hosted runner. If you pick a labeled runner, you can optionally specify a custom label and a runner group.
This is granular control where it matters. Repository A can keep using GitHub's default runners. Repository B, which pulls internal packages from a private registry, can point its Dependabot jobs at a self-hosted runner that sits inside the corporate network. Repository C, which needs a beefier machine for dependency resolution in a large monorepo, can target a larger GitHub-hosted runner. Each repo gets the right runner for its needs without affecting the others.
The Self-Hosted Runner Setup
Configuring a self-hosted runner for Dependabot isn't new, but the repository-level settings add a step worth understanding. GitHub's documentation on configuring Dependabot on self-hosted runners notes that runners need the dependabot label by default. If you don't specify a custom label in the repository settings, that's what Dependabot looks for.
The docs are explicit about ordering: make sure a runner with your intended label actually exists before you select "Labeled runner" in the repo settings. If you specify a runner group, that group must exist and the repository must have access to it. This sounds obvious, but it's the kind of thing that bites teams during initial setup: Dependabot won't fail loudly if the runner isn't there, it simply won't run.
One important detail from GitHub's documentation: changing the runner setting does not trigger a new Dependabot run. You'll need to wait for the next scheduled update cycle or manually trigger one. For teams testing a new runner configuration, this means you won't get instant feedback on whether your setup works.
Enterprise Policy Interactions
There's a wrinkle for organizations that enforce strict GitHub Actions policies. GitHub's documentation notes that if your enterprise restricts actions to only those from your own org, Dependabot on Actions won't run at all unless you explicitly allow GitHub-created actions or add the necessary workflows to your allowlist. This is a common stumbling block for security-conscious enterprises that lock down Actions as a matter of policy.
The Concrete Scenario: Network-Isolated Dependency Updates
The most compelling use case is straightforward: private package registries.
Consider a mid-size engineering org running a mix of services. Some are open-source-heavy Node.js applications pulling everything from npm. Others are internal Java services whose dependencies live in a private Artifactory or Nexus instance accessible only from the corporate network. Before repository-level runner settings, the org had to either give up on Dependabot for those Java repos or configure org-wide self-hosted runners and accept the overhead for repos that didn't need them.
Now, the Java repos can target a labeled self-hosted runner sitting inside the network perimeter, while the Node.js repos keep using standard GitHub-hosted runners. The self-hosted runner handles authentication to the private registry, resolves internal dependencies, and opens PRs — all without exposing the registry to the public internet.
This also matters for teams in regulated industries. Financial services, healthcare, and defense contractors often can't let dependency resolution traffic leave their network. A self-hosted runner inside a VPC or on-premises data center lets Dependabot do its job without violating network security policies.
Where the Gaps Are
This feature ships with some clear limitations.
-
Public repos are excluded. The GitHub Blog changelog states that repository-level runner settings are available only for private and internal repositories on github.com. The controls are hidden for public repos entirely. This makes sense from a security perspective — you don't want public repos routing jobs to self-hosted runners that might have access to internal resources — but it means open-source maintainers won't benefit.
-
GitHub Enterprise Server is also excluded. The setting is available on github.com (GHEC) but not on GHES (GitHub Blog changelog). Notably, Dependabot updates have been generally available on GHES since version 3.5, with self-hosted runners central to the GHES Dependabot story from the start. Teams running GHES already configure runners at the instance level, but they don't get the new repo-level granularity. Whether this comes to GHES in a future release isn't specified.
-
Security configurations don't enforce runner settings. The changelog notes this explicitly (GitHub Blog changelog). If your org uses GitHub's security configurations to standardize settings across repos, those configurations won't currently push or enforce Dependabot runner choices. That means runner settings remain a manual, per-repo decision — manageable for small orgs, potentially tedious for large ones with hundreds of repositories.
-
No immediate feedback loop. GitHub's documentation confirms that changing the runner setting doesn't trigger a new Dependabot run. You configure, you wait. For teams iterating on runner setup, this slows down the debugging cycle.
What This Means for CI/CD Workflows
Dependabot's repository-level runner settings don't transform CI/CD pipelines on their own. What they do is remove a specific friction point that forced teams into awkward workarounds.
The broader pattern here is GitHub steadily making Dependabot more configurable for enterprise environments. Org-level runner settings came first. Repository-level settings add the granularity that heterogeneous engineering orgs need. The logical next steps would be security configuration enforcement and GHES support, but GitHub hasn't announced either.
For teams already running self-hosted runners for their CI/CD workflows, adding Dependabot to those runners is a natural extension. The runner infrastructure is already there. The network access is already configured. Pointing Dependabot at the same runners that build and test your code means dependency updates happen in the same security context as everything else — no special exceptions, no additional network rules.
For teams that haven't adopted self-hosted runners yet, this feature alone probably isn't the reason to start. The operational overhead of maintaining runner infrastructure is real. But if you're already hitting the wall with private registries or network isolation requirements, this is the missing piece that makes Dependabot viable in those environments at the repository level rather than the organizational one.
The feature is live now on github.com for private and internal repos. If your org has been working around Dependabot's runner limitations, it's worth testing on a single repo before rolling it out broadly — especially given the lack of immediate feedback when you change settings.
