GitHub Actions Blob Storage: 120 New Hosts to Allowlist

7 min read

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The announcement

• Meta API endpoints updated for Actions blob storage, GitHub Changelog, October 22 2026

On October 22, 2026, GitHub announced it is adding new blob storage endpoints for GitHub Actions on github.com. The stated reason is capacity and reliability. The meta API, which is where GitHub publishes the endpoints its services use, now lists these new hosts.

The new hosts come in two inclusive ranges: productionresultssa30 through productionresultssa49, and productionresultssa100 through productionresultssa199, all on blob.core.windows.net. If your network only lets Actions talk to specific hosts, you need to add them. If you skip it, GitHub says you risk interruptions to job summaries and logs.

Key takeaways

• GitHub added two new ranges of Actions blob storage hosts, announced on October 22, 2026.
• The ranges are productionresultssa30 to 49 and productionresultssa100 to 199, both inclusive. That is 120 new hostnames.
• If you already allow the wildcard productionresultssa*.blob.core.windows.net, you need to do nothing.
• If you allowlist individual hosts, add all of them, or job summaries and logs can break.
• The current list lives in the meta API, so pull it from there instead of copying hostnames by hand.

What did GitHub change for Actions blob storage?

Short version: more storage hosts, same naming pattern.

GitHub is spreading Actions blob storage across more hosts. The changelog calls this part of "ongoing work to improve capacity and reliability." The two things it names as depending on that storage, and at risk if you block it, are job summaries and logs.

Here is the full set of additions, straight from the announcement:

Range	First host	Last host	Hosts
1	productionresultssa30.blob.core.windows.net	productionresultssa49.blob.core.windows.net	20
2	productionresultssa100.blob.core.windows.net	productionresultssa199.blob.core.windows.net	100

Both ranges are inclusive, so 30 and 49 count, and so do 100 and 199. I did the arithmetic so you do not have to: 20 plus 100 is 120 hostnames.

Notice the gap. Nothing in the announcement covers 50 through 99. Do not fill that gap in your config because it looks tidy. Allow what GitHub published, or allow the wildcard.

Why does this matter to a developer?

Most people reading this will never notice the change. If nothing filters the traffic between your workflows and the internet, the new hosts just start working.

It matters if you are on the other side of that line. That usually means one of these:

• You run self hosted runners inside a company network with outbound filtering.
• Your security team keeps a strict egress allowlist and every new host needs a ticket.
• You copied a list of hostnames into a firewall or proxy rule a while ago and never touched it again.

In those setups, the failure mode is the annoying kind. GitHub specifically names job summaries and logs as what gets interrupted. Your build might do its work, but you lose the record of what happened. When something fails at 2am, missing logs turn a five minute fix into an afternoon.

And if only some jobs land on the new hosts, this can look random. One run has logs, the next does not. That is exactly the kind of bug people waste days on before realising it is a network rule.

What changes in practice?

It depends entirely on how your allowlist is written.

How your allowlist is written	What you need to do
No allowlist for Actions blob storage	Nothing
Wildcard: productionresultssa*.blob.core.windows.net	Nothing. GitHub confirms the wildcard already covers these
Individual productionresultssa hostnames	Add all 120 new hosts
Not sure	Check before your next big release, not after

The wildcard row is the one worth thinking about. GitHub's own wording is that if you already allow productionresultssa*.blob.core.windows.net, "no changes are needed for these additions." Teams that pinned individual hosts now have to do work every time GitHub adds capacity like this. Teams on the wildcard did not even need to read the changelog.

Whether your security team accepts a wildcard is their call, not mine. But this announcement is a good concrete example to bring to that conversation.

If you need the explicit list, do not type it. Generate it from the two ranges in the announcement:

# Prints the 120 new Actions blob storage hosts from the Oct 22, 2026 changelog
for i in $(seq 30 49) $(seq 100 199); do
  echo "productionresultssa${i}.blob.core.windows.net"
done

Pipe that into a file, diff it against what your firewall or proxy currently allows, and you have your ticket. Check the count with wc -l. You should see 120.

What should you do this week?

Here is the order I would go in. For most teams this is a short job.

1. Find out if you have an allowlist at all. If nothing filters your Actions traffic, you are done. Close the tab.
2. Search your network config for productionresultssa. Firewall rules, proxy config, infrastructure as code, wherever egress rules live.
3. Look at how the match is written. A wildcard on productionresultssa*.blob.core.windows.net means you are covered. A list of numbered hosts means you have work to do.
4. Generate the new hosts with the loop above and diff them against your current list.
5. Add the missing ones through whatever change process your team uses.
6. Pull from the meta API going forward. GitHub points to its REST API endpoints for meta data as the way to retrieve the current endpoint list, and to its "GitHub's IP addresses" docs for allowlisting guidance. A scheduled job that compares the meta API against your rules beats reading every changelog.
7. Run a workflow on a self hosted runner after the change and confirm the job summary and logs show up.

The step people skip is the sixth one. Copying hostnames by hand is how you ended up with a list that goes stale. The meta API exists so the source of truth is GitHub's, not a wiki page someone wrote two years ago.

What does the changelog not tell you?

I am only working from the announcement, so it is worth being clear about its gaps.

• There is no date for when traffic starts flowing to the new hosts. Treat it as now.
• There is no detail on affected features beyond "GitHub Actions on github.com", with job summaries and logs named as what can break.
• There is nothing about the 50 to 99 range. Do not assume it is coming, and do not assume it is not.

If any of those matter for your team, the meta API is the place to check, because that is where GitHub says the current list lives.

FAQ

Do I need to change anything if I use GitHub Actions?

Only if your organization uses a network allowlist to access GitHub Actions blob storage. The changelog is aimed at exactly those organizations. If nothing filters the traffic, the new hosts just work.

Is the productionresultssa wildcard enough?

Yes, according to GitHub. The announcement says that if you already allow productionresultssa*.blob.core.windows.net, no changes are needed for these additions. Only teams that allow individual hosts need to add the new ones.

How many new hosts did GitHub add?

The two inclusive ranges cover 30 through 49 and 100 through 199. That works out to 20 plus 100, so 120 new hostnames, all under blob.core.windows.net.

What breaks if I miss the new hosts?

GitHub says you may see interruptions to job summaries and logs. If only some jobs hit the new hosts, it can look intermittent, which makes it harder to trace back to a network rule.

Search your network config for productionresultssa today and you will know in two minutes whether this affects you. While you are at it, the free tools on Art of Code can handle the small chores around your pipeline, and if you are the person who ends up owning these runners, our jobs board lists teams hiring for that work.

Written by Adithya Guttha, Founder of Art of Code.