Bridging GitHub-hosted runners to your private network
GitHub-hosted Actions runners handle the infrastructure burden of CI/CD, but they run in GitHub’s cloud—outside your network boundary. That becomes a problem when a workflow needs to reach internal services, such as a signing service, artifact store, or package registry.
Self-hosted runners solve this by moving the workload onto your infrastructure, but they bring back the provisioning and maintenance overhead you were trying to avoid. For teams that want to keep using hosted runners, GitHub has published guidance covering three connectivity approaches, each with different tradeoffs.
Option one: OIDC through an API gateway
The most scalable approach is to place an API gateway on your network and authenticate runners using the GitHub Actions OpenID Connect (OIDC) token. Because each job gets a short-lived, verifiable token, you can validate the request without storing long-lived credentials on the runner.
The gateway itself is stateless, so it can handle high-bandwidth workloads well. You can run it on your own infrastructure, but it’s not a plug-and-play solution: GitHub provides a reference implementation that requires customization for your specific environment and use case.
Option two: WireGuard overlay network
If you need direct point-to-point connectivity rather than routed access, WireGuard can establish a temporary encrypted tunnel between a runner and your private network. Setup effort is moderate, making this a reasonable fit for smaller or simpler network topologies.
The key limitation is that WireGuard does not perform NAT traversal out of the box. If your network edge cannot assign public IP addresses to resources, the overlay may not be able to establish a connection at all.
Option three: Managed overlay with Tailscale
Tailscale builds on WireGuard but removes much of the configuration burden as a commercial product. It offers the same general advantages—encrypted, point-to-point connectivity from a runner to your private network—and adds built-in NAT traversal support.
The tradeoff is cost: higher data volumes may require a paid plan. For occasional or moderate use, the simpler setup can be worth the potential expense.
Choosing an approach
There is no single best answer for every team. The right choice depends on your network topology, bandwidth expectations, and how much operational overhead you can accept. Between the three private-network connectivity options and the existing self-hosted runner path, most teams should find one that fits their constraints.
