Configuring private networking for GitHub-hosted runners in your organization

Learn how to use GitHub-hosted runners with an Azure private network in your organization.

Who can use this feature?

Organization owners with the GitHub Team plan can configure Azure private networking for GitHub-hosted runners at the organization level.

In this article

About Azure private networking for GitHub-hosted runners

To use GitHub-hosted runners with Azure VNET, first, configure your Azure resources. Then create a private network configuration in GitHub.

The following procedures will lead you through both steps.

For more information about troubleshooting common issues with using GitHub-hosted runners with Azure VNET, see Troubleshooting Azure private network configurations for GitHub-hosted runners in your organization.

Configuring your Azure resources

You will use a script to automate configuring your Azure resources.

Prerequisites

  • Use an Azure account with the Subscription Contributor role and the Network Contributor role. These roles enable you to register the GitHub.Network resource provider and delegate the subnet. For more information, see Azure built-in roles in the Azure documentation.

  • To correctly associate the subnets with the right user, Azure NetworkSettings resources must be created in the same subscriptions where virtual networks are created.

  • To ensure resource availability/data residency, resources must be created in the same Azure region.

  • Outbound network traffic from the subnet must not be subject to TLS interception as our Virtual Machines will not be configured to trust intermediate certificates that your network uses to perform the interception.

    If you need to use TLS interception, you can install intermediate certificates via a custom image. See Using custom images.

  • We recommend some level of network traffic control over your Azure VNET and to use DNS/domain-based controls. The previously recommended IP addresses will be closed on or after July 1, 2026.

If you control the outbound access of your GitHub-hosted runners with Azure VNET using DNS or domains, you allow-list a set of domains for GitHub Actions functionality. This is the recommended approach because the domains are published on the GitHub meta endpoint, which GitHub keeps up to date as network requirements change. For a breakdown of the domains by function, see the "Communication" section in Self-hosted runners reference.

You can find the domains to allow-list on the GitHub meta endpoint at https://api.github.com/meta. For more information on the meta endpoint, see REST API endpoints for meta data.

There are three sections on the meta endpoint you can choose to allow-list based on:

  • domains.actions_inbound.full_domains: An extremely specific list of exact domains needed for GitHub Actions functionality, with no wildcarded domains.
  • domains.actions: A middle-ground domain list, with some GitHub-owned domains wildcarded, but other domains listed specifically.
  • domains.actions_inbound.wildcard_domains: A list with primarily wildcarded domains. This will be the most stable from a domain change perspective.

Warning

Required domains on the meta endpoint are subject to change. GitHub ensures a domain is on the meta endpoint for at least one week before it goes into use. The meta endpoint does not provide a "last updated" date, so you cannot rely on a timestamp to detect changes.

If you plan to use the more specific domain lists, you must check for new domains on a weekly basis and update your network control systems appropriately, or your GitHub Actions jobs may experience unintended issues. Because new domains are published at least a week before they are required, a weekly check leaves enough lead time to apply changes before they take effect. The middle-ground list that allows for some GitHub domain wildcards will be much more stable, and the full wildcard list should see very little change.

You can use any technology of your choice for doing DNS/domain control on your Azure VNET. This guidance is for the minimal required domains for basic functionality; you may need to add more domains to your allow-list system for additional scenarios.

IP address controls

Warning

The IP-based .bicep template below is closing down and will be removed on or after July 1, 2026. It remains available to support migration to DNS/domain-based control (see "DNS/domain control" above). Customers who hard-code or template this IP list (for example, in Terraform) are at risk of broken traffic when the underlying Azure IP ranges change, because this static list is not kept up to date. Migrate to the meta endpoint domains before this template is removed.

Note

To determine the appropriate subnet IP address range, we recommend adding a 30% buffer to the maximum job concurrency you anticipate. For instance, if your network configuration's runners are set to a maximum job concurrency of 300, it's recommended to utilize a subnet IP address range that can accommodate at least 390 runners. This buffer helps ensure that your network can handle unexpected increases in VM needs to meet job concurrency without running out of IP addresses.