GitHub Actions’ Multi-Cloud Runners Add Capacity—and New Egress IPs

A workflow file can remain byte-for-byte identical while its network path changes. GitHub’s October 28 update schedules eligible hosted Linux jobs across a multi-cloud pool, which can reduce queueing pressure and add capacity during peaks. The practical migration task is not a YAML edit: it is checking whether systems those jobs call still trust the IP ranges GitHub publishes for Actions.

What changes for a runner

GitHub says eligible standard two-core and four-core Linux runners—and compatible larger runners without specialized configurations—may run on AWS as well as Azure. The rollout is automatic for GitHub Free, Pro and Team plans. GitHub Enterprise Cloud customers can opt in through an enterprise policy. Windows runners, private-networking runners and other specially configured runners are outside this change. Runner labels and workflow syntax stay the same. ^[1]

The distinction matters because the infrastructure provider was not a stable contract encoded in a workflow. A job that requests ubuntu-latest asks GitHub for a supported runner image and service; it does not promise that the virtual machine will originate from one cloud provider. If an allowlist quietly assumed otherwise, that assumption was never part of the YAML contract.

The reliability benefit has a security-shaped prerequisite

Adding capacity across providers gives GitHub another pool to schedule from. GitHub describes the goal as faster starts and greater reliability during demand spikes. But a job may connect to package registries, deployment APIs, identity providers, internal endpoints or a managed database. If any of those systems accept traffic only from a hard-coded cloud range, a job placed in the expanded pool can fail at the connection layer or receive an unexpected access denial. ^[1]

GitHub specifically advises keeping allowlists current with the actions array from GET https://api.github.com/meta. Its IP-address documentation explains that the published ranges represent GitHub services and can change; the REST endpoint provides the machine-readable source for metadata. That is a better basis than maintaining a guessed list of Azure-owned ranges, though it still needs an owner, update cadence and alerting around failed synchronization. ^{[2] [3]}

This is also an identity policy concern. Microsoft Entra Conditional Access and similar controls may apply network conditions to service access. A network policy that grants trust to one provider’s IP space can reject a legitimate GitHub-hosted runner simply because the runner was scheduled elsewhere. The right response is to model the service identity and the allowed GitHub Actions ranges, not to broadly relax the policy.

A practical readiness check

Before enabling or relying on the expanded pool, inventory the external systems a hosted runner calls. Include deployment targets, artifact stores, package mirrors and identity gateways, not only the primary cloud account. Identify which rules rely on source IP and which use stronger workload identity or signed credentials. For the former, replace provider-specific assumptions with a controlled process that fetches, parses and applies GitHub’s actions ranges.

Then test both the update path and the failure path. A scheduled sync that silently stops is not a durable control. Keep the last known good list, alert when the endpoint cannot be read or parsed, and have a bounded response when ranges change. Avoid copying the complete GitHub meta response into a firewall if the service only needs the actions property.

GitHub’s status history is useful operational context: hosted CI has experienced service incidents before, as any large distributed service does. Multi-cloud capacity can improve resilience against a narrower class of infrastructure pressure, but it is not a guarantee that Actions or a downstream dependency will always be available. Keep retries, idempotent deployment steps and clear failure reporting in the workflow itself. ^[4]

For adjacent supply-chain controls, see our guides to locking GitHub Actions workflow dependencies and GitHub’s package firewall policy preview. Pinning dependencies protects a different boundary from runner network identity; a reliable pipeline needs both.

The meaningful change is the boundary you maintain

Multi-cloud scheduling is largely invisible to the workflow author by design. That is useful: teams can benefit from a broader pool without rewriting every runner declaration. The invisible part is also why the network boundary deserves an explicit review. If your CI trusts GitHub’s published Actions ranges and keeps them current, the new capacity can arrive without turning a provider-specific assumption into a production outage. If the allowlist is static, the new pool may expose that hidden coupling before it improves your build times.