By default, GitHub-hosted runners have access to the public internet. However, you may also want these runners to access resources on your private network, such as a package registry, a secret manager, or other on-premise services.
GitHub-hosted runners are shared across all GitHub customers. However with private networking, you can configure hosted runners to be exclusively used to connect to your private network and resources while they are running your workflows.
There are a few different approaches you could take to configure this access, each with different advantages and disadvantages.
With GitHub Actions, you can use OpenID Connect (OIDC) tokens to authenticate your workflow outside of GitHub Actions. For more information, see "Using an API gateway with OIDC."
If you don't want to maintain separate infrastructure for an API Gateway, you can create an overlay network between your runner and a service in your private network, by running WireGuard in both places. For more information, see "Using WireGuard to create a network overlay."
- Using GitHub-hosted runners with an Azure VNET is in beta and subject to change.
- Only 4-64 CPU Ubuntu and Windows runners are supported with Azure VNET. For more information on these runner types, see "About larger runners."
- Supported regions include
East US 2, and
West US 2. To request support for a region that is not in this list, fill out the region request form.
If you are using Azure and GitHub Enterprise Cloud, you can use GitHub-hosted runners in your Azure VNET(s) using the Azure private network configuration. For more information about Azure VNET, see What is Azure Virtual Network? in the Azure documentation.
Using GitHub-hosted runners in an Azure VNET enables you to use GitHub-managed infrastructure for CI/CD while providing you with full control over the networking policies of your runners. For more information, see "About using GitHub-hosted runners in your Azure Virtual Network."