GitHub Actions Adds 120 Blob Hosts: Does Your Allowlist Need Updating?
Your self-hosted runner picks up jobs, but its logs and summaries never arrive. Which of GitHub’s new blob hosts does your firewall need, and does your wildcard cover them?
- GitHub announced additional Actions blob-storage endpoints on October 22.
- Organizations listing individual hosts need two new ranges; an existing productionresultssa wildcard covers them.
- Use live Meta API data and the runner network reference, rather than copying documentation samples into a firewall.
Check whether your rules enumerate individual hosts
The GitHub announcement concerns blob storage for Actions on github.com. Updating exact-host rules helps avoid interruptions to job summaries and logs as the additional storage endpoints are used.
If your network already permits productionresultssa*.blob.core.windows.net, GitHub says these additions require no change. The operational decision starts with the rule you actually have.
Two inclusive ranges add up to 120 hosts
| First host | Last host | Count |
|---|---|---|
productionresultssa30.blob.core.windows.net | productionresultssa49.blob.core.windows.net | 20 |
productionresultssa100.blob.core.windows.net | productionresultssa199.blob.core.windows.net | 100 |
Both endpoints of each range are included. The calculated total describes this addition, not every Actions endpoint. Accounts 50–99 are not part of the two ranges announced here.
Query the API instead of using its example response
The Meta endpoint returns GitHub service information, including domains and IP addresses. A read-only request for public metadata is:
curl -L -H "Accept: application/vnd.github+json" https://api.github.com/metaAuthentication is not required for this public information. GitHub explicitly says the values in its documentation response are examples; current values must come from a direct API request. Fetching the response does not install or update firewall rules.
There is another distinction in the IP-address guidance: the Meta IP list is not exhaustive across all GitHub services. GitHub discourages IP-based allowlisting and recommends regularly monitoring the API if you use it. A copied IP-range list is therefore not equivalent to allowing the storage domains in this announcement.
A connected runner still needs its result-delivery paths
The self-hosted runner reference separates essential operations from result transfer. For summaries, logs, workflow artifacts and caches, it lists results-receiver.actions.githubusercontent.com and *.blob.core.windows.net.
The new host ranges are only one part of that broader network configuration. Some listed domains use CNAME records, and certain firewalls may need rules covering the targets recursively.
A practical check is to compare your existing rule type, apply the missing entries and verify that a real job’s logs and summary arrive. Successful job assignment and successful result delivery establish different things.
Frequently asked questions
Do I need individual entries if the wildcard is already allowed?
No. The existing productionresultssa*.blob.core.windows.net pattern covers this addition.
Is this a complete Actions firewall configuration?
No. The runner reference has separate requirements for basic connectivity, action downloads and other functions. This announcement adds storage hosts.
Start with your current allowlist method, then check result delivery after applying any missing hosts.