A Mac CI job finishes, but its logs, summary, or artifact are missing.
Fastest fix: Check whether your firewall allows blob storage by individual hostname or by a matching wildcard. If it uses individual entries, compare them with GitHub’s current published hostname list and update missing entries; if the relevant wildcard is already allowed, verify its scope and test a real workflow before changing anything.
This runbook is for you if you manage an enterprise firewall, proxy, or DNS filter and need to assess GitHub Actions blob storage endpoints. It also covers platform engineers responsible for self-hosted Mac runners and IT or release teams that need a repeatable network-change acceptance process.
Last updated October 27, 2026. The endpoint change and applicability were checked against GitHub’s October 22, 2026 announcement, the GitHub Meta API documentation, and the self-hosted runner network requirements.
1. Policy scope: identify what your firewall matches
Start with the policy object, not with the failed job. The change covered here concerns GitHub Actions blob storage endpoints on GitHub.com. It does not change Runner labels or workflow files, and it should not be treated as evidence that GitHub API access, repository access, or Xcode has failed.
Inspect the actual rule and determine whether it matches:
- Individual hostnames entered as separate allow rules.
- A wildcard domain pattern that includes the affected storage hosts.
- IP addresses or network ranges rather than hostnames.
GitHub’s announcement identifies two groups of new hostnames for Actions blob storage and distinguishes organizations using wildcard rules from those listing hosts individually. Use the hostnames shown in the announcement as the comparison target; do not copy an older ticket or a static example and treat it as a permanent list. The change applies to GitHub.com as described in the announcement. Do not extend it to GitHub Enterprise Server without separate product-specific evidence.
Do GitHub Actions blob storage changes require a firewall update? Not in every environment. If your existing rule already covers the relevant hostname patterns, first confirm that the wildcard is scoped to the intended domain and that the connection is allowed through each relevant network layer. If your policy lists hostnames individually, review those entries against GitHub’s current announcement and add any missing hosts. GitHub did not specify a universal enforcement deadline in that announcement, so do not invent one for your change plan.
2. Rule precision: choose a narrow, evidence-based change
The safest change is the smallest one that restores the required traffic. Do not replace a host-specific policy with broad outbound access just because a storage transfer failed. Before adding a rule, check whether your organization’s security standard permits wildcard domains, whether the proxy evaluates the original hostname, and whether DNS filtering or TLS inspection changes the request path.
Use these decision branches:
- If the firewall explicitly allows the relevant wildcard hostname and your proxy and DNS controls do not narrow or override it, keep the rule and validate the workflow. Do not add duplicate host entries merely to mirror the announcement.
- If the firewall enumerates hostnames individually, compare every current entry with the announcement and add only missing entries, following your normal approval process.
- If the policy is IP-based, use the appropriate current GitHub network data and confirm how your product handles changing address ranges. Do not convert hostname data into guessed IP rules.
- If the policy combines a proxy, DNS filter, and firewall, trace the request through each control. Update only the layer that is demonstrably blocking it.
- If you cannot establish what the rule matches, pause the change. Export or inspect the effective policy, identify its match type, and run a controlled test before widening access.
| Existing policy | Recommended action | Fit for this change |
|---|---|---|
| Individual hostname entries | Compare against the current published hostnames; add only missing entries, then test. | Strong match for an explicit review |
| Relevant wildcard domain | Verify wildcard scope and downstream controls; test without adding redundant entries. | Usually no separate host entry is needed |
| IP ranges only | Check the current IP data and your firewall’s matching behavior separately from hostname rules. | Conditional; hostname data alone is insufficient |
| Broad outbound access | Do not use it as a shortcut. Replace or constrain it only through an approved policy change. | Poor least-privilege fit |
3. Data currency: use the official sources for different jobs
Use GitHub’s changelog to identify the announced hostname additions and the rule patterns the change affects. Use the GitHub Meta API documentation to understand the machine-readable metadata and the current Meta API response as the live reference for the fields it exposes.
Do not assume those sources are interchangeable. A hostname list in an announcement and IP ranges in a JSON response are not the same kind of data. Check the relevant response fields and your policy’s match type before translating one into the other. The API’s current response is not a reason to ignore the changelog’s hostname-specific instructions, and a copied response from a past ticket is not current simply because it came from the API at the time.
| Evidence source | What to verify | What not to infer |
|---|---|---|
| GitHub changelog announcement | The two published hostname groups, the affected allowlist patterns, and the stated GitHub.com scope. | A universal deadline or a change to GitHub Enterprise Server |
| GitHub Meta API documentation | What the available metadata fields represent and how to retrieve them. | That every hostname is represented as an IP range, or vice versa |
| Current Meta API response | The current values in the relevant fields when your policy uses those values. | That an old saved response remains valid |
| Runner network requirements | The network communications required by self-hosted runners. | That every runner connection problem is caused by blob storage |
4. Workflow coverage: map endpoints to the affected data
Blob storage traffic is part of the workflow’s data-transfer path. It can affect logs, workflow summaries, artifacts, and dependency caches, but those features have distinct workflow behaviors and permissions. GitHub documents workflow artifacts and dependency caching separately. Use those references to identify what your pipeline actually uploads or downloads.
A missing workflow summary is not by itself proof of a storage-host firewall block. The step that writes a summary, the runner’s ability to upload it, the job result, and any permissions or workflow errors are separate things to inspect. GitHub’s workflow variable reference describes the summary-related interface. Check the runner log and workflow output before attributing a symptom to the new hostnames.
Similarly, do not classify repository checkout, GitHub API requests, or Xcode toolchain failures as blob storage failures without evidence. A runner may be online and able to fetch source while an artifact transfer is blocked; an Xcode build may fail before it reaches any upload step. Keep the diagnosis tied to the failing operation and the corresponding network log.
A successful build step does not prove that the post-build upload path works. Validate the transfer that your release process depends on, not only the compiler result.
5. Mac CI acceptance: verify the effective rule with a real workflow
A policy review confirms what should be allowed. A workflow test confirms what actually happens from the target runner network. Test from the same egress path, proxy configuration, and DNS policy used by the affected self-hosted Mac runner; a laptop on a different network is not a substitute.
Use this sequence:
- Capture the baseline. Record the policy version, rule type, runner network path, and the workflow run that exposed the issue. Preserve relevant firewall, proxy, and DNS logs before changing rules.
- Check name resolution and policy evaluation. Verify that the runner resolves the requested host as expected, then inspect whether the proxy or firewall allows or denies the connection. Keep DNS failure distinct from an explicit egress denial.
- Compare the allowlist. For individual hostname rules, compare entries with GitHub’s announcement. For wildcard rules, confirm the exact matching scope and check for more specific deny rules.
- Make a minimal approved change, if required. Add only missing hostname entries or update the relevant network data under your change process. Keep the previous policy available for rollback.
- Run a representative Mac workflow. Include the operations your team uses: log and summary reporting, artifact transfer, and cache upload or retrieval where those features are part of the pipeline.
- Collect the result. Save the run URL or internal record, relevant runner output, rule-hit evidence, and transfer outcome. If the test fails, classify it as DNS, proxy, firewall, workflow permission, or another observed error before making another change.
How can you confirm the allowlist covers the new storage endpoints? Match the policy type to the official evidence, then run the relevant workflow from the affected Mac runner network. Confirm the intended transfer succeeds and correlate its timestamp with firewall, proxy, and DNS logs. If the job still fails, use the logs to identify the rejecting layer; do not keep adding destinations without a demonstrated policy gap.
6. Change governance: make endpoint review repeatable
Assign an owner for the Actions endpoint inventory. That owner should be able to explain which source is authoritative for hostname changes, which source is authoritative for any IP-based rules, and which teams approve changes to each control. Keep the announcement, the API retrieval or review record, the policy diff, and the workflow acceptance evidence together.
Trigger a review when GitHub publishes a relevant endpoint notice, when the runner network architecture or proxy policy changes, or when a representative workflow shows a new transfer failure. Recheck the official runner network requirements when you revise the runner’s egress design; do not treat a storage endpoint update as a complete inventory of all runner dependencies.
For a Mac CI environment with a separate network boundary, evaluate the actual access policy and the routes available to that environment. A dedicated host does not automatically solve an egress restriction, and a rented or remote Mac does not remove the need to verify your organization’s proxy, DNS, and firewall requirements. If you are assessing hosted capacity alongside your existing setup, review MACGPU’s remote Mac options and compare the required access path with your own network controls.
A team that buys and operates every build Mac keeps direct hardware control, but it also owns procurement, lifecycle maintenance, and capacity planning. A shared existing machine avoids a new purchase, but can introduce contention and makes network-policy ownership easy to blur. If you need temporary or separately managed Mac CI capacity, MACGPU can be one option to evaluate; confirm that its access method and your required network controls fit before relying on it. You can review available Mac configurations, then validate the network path with your own representative workflow. If your pipeline requires physical interfaces or long-running, predictable heavy workloads, a dedicated Mac you operate may remain the better fit.
For the allowlist change itself, the decision is narrow: keep a verified wildcard policy unchanged, update an individual-host policy from GitHub’s current published evidence, and accept either change only after a real Mac workflow confirms the data transfers your team depends on.