GitHub Actions adds new blob storage hosts – update your network allowlist

GitHub has expanded the set of blob storage endpoints used by GitHub Actions and exposed the new ranges through the Meta API. The change matters for any environment that filters outbound traffic to GitHub, because missing hosts can break the delivery of job summaries and logs.

What changed in the Meta API

The Meta API now returns two additional host ranges for Actions blob storage:

• productionresultssa30.blob.core.windows.net through productionresultssa49.blob.core.windows.net
• productionresultssa100.blob.core.windows.net through productionresultssa199.blob.core.windows.net

These entries are part of the same service that stores job artifacts, and they are listed alongside existing endpoints when querying the /meta REST endpoint.

Network‑allowlist impact

If your organization uses a static allowlist for outbound connections to GitHub, you need to verify that the new hosts are covered. Two scenarios apply:

• Wildcard allowlist – if you already permit productionresultssa*.blob.core.windows.net, no action is required.
• Explicit host entries – if you enumerate individual hosts, add every host in the two new ranges to avoid service disruption.

For reference, GitHub also publishes its IP address ranges; those should be reviewed in parallel to ensure complete coverage.

Operational steps

Practical actions you can take today:

1. Query the Meta API (GET https://api.github.com/meta) to confirm the current list of blob storage hosts.
2. Update firewall, proxy, or egress‑filter rules to include the new ranges, using either the wildcard pattern or the full host list.
3. Validate the change by running a short Actions workflow that generates a job summary or log file, confirming that the data reaches the new storage endpoints.
4. Document the allowlist change in your network policy repository to keep audit trails up to date.

Related CloudNinjas coverage: DevOps.

What This Means For Practitioners

In short, the added blob storage hosts are a capacity‑ and reliability‑focused expansion that does not alter the API surface, but it does require a small network‑policy update for any environment that restricts GitHub traffic. Ensure your allowlist reflects the new ranges, verify connectivity with a test workflow, and keep an eye on future Meta API releases for additional endpoint changes.