Connecting to a private network from GitHub-hosted Actions runners

Several ways for GitHub-hosted Actions runners to connect to resources on your private network.

GitHub Actions is a powerful tool for automating your development workflows, including CI/CD. There’s several options for where those workflows run, but GitHub-hosted runners can seem particularly magical. Your job runs, you get the results, and that’s it. You don’t have to provision and maintain servers.

But sometimes, particularly for CI/CD, your job needs to connect to resources on a private network. Maybe you need to access a signing service to sign your builds, or a package registry to upload your finished build. You could use self-hosted runners to run the workflows on your network, but then you need to provision and maintain those servers. Sometimes that’s no big deal, but as your usage grows, or if your team doesn’t have the resources to focus there, that might not work for you.

If that describes you, you’re in luck! We’ve added documentation on connecting to a private network from GitHub-hosted runners. In there, we describe three different approaches you can take and the tradeoffs with each approach. Check out the documentation for all the details, but briefly the three options are as follows:

1) Use the GitHub Actions OpenID Connect (OIDC) token to authenticate through an API gateway (we open sourced a reference implementation as an example, but do note that it requires customization for your use case and is not ready-to-run as-is). You would run the API gateway on your infrastructure, but as it is stateless, it can scale quite well for high-bandwidth use cases. Here’s what this looks like:

2) You can use WireGuard to create a temporary overlay network between the GitHub Actions runner and your private network. This is great for point-to-point communication, and not too much effort to set up, but it does not support NAT traversal out of the box, which could be a problem if the edge of your private network doesn’t support resources with public IP addresses.

3) You can use a commercial solution for an overlay network, like Tailscale. Based on WireGuard, it has similar advantages and disadvantages, except that as a commercial product, it’s even easier to set up and includes NAT traversal. Please note that it might require a paid plan for higher data volumes.

The more GitHub customers I talk to, the more I realize there isn’t a one-size-fits-all solution. Between these options for connecting GitHub-hosted runners to your private network, and the option to run self-hosted runners, we hope that one of these solutions will meet your needs.

Happy building!

More on CI/CD

Get started with ease using security workflows!

GitHub Actions workflows in the Security category will now appear among the workflow recommendations based on a repository's content.

Pulkit Agarwal

Release Radar · January 2022 Edition

Here's January's top staff picks on projects that shipped major version releases.

Michelle Mannering

Getting started with GitHub Actions just got easier!

When you want to create a workflow in the Actions tab of your repository, the recommendations are now based on an analysis of repo content.

Pulkit Agarwal

More on GitHub Actions

GitHub Enterprise Server 3.5 is now generally available

GitHub Enterprise Server 3.5 is available now, including access to the Container registry, the addition of Dependabot, enhanced administrator capabilities, and features for GitHub Advanced Security.

Melody Mileski

Supercharging GitHub Actions with Job Summaries

You can now output and group custom Markdown content on the Actions run summary page.

Konrad Pabjan

5 simple things every developer can do to ship more secure code

From plug-and-play automations to protected branches, here are simple ways any developer can build more secure software on GitHub—all with a free account.

Brian Douglas