Protect your builds from GitHub outages with a file cache

GitHub has its rough patches. In August 2026 alone, GitHub reported five incidents that caused degraded performance across its services.

The largest outage that month lasted almost eight hours and affected github.com, authentication, Actions, APIs and several other services.

If your build fetches release artifacts from GitHub every time it runs, GitHub's availability becomes part of your build's availability too.

We recently saw the same kind of dependency in a StableBuild customer's build. It relied on an artifact hosted on GitHub Releases, and when that download timed out, the build stopped.

At first glance, it looked like an npm problem. The failure followed this pattern:

npm error code 1
npm error path /app/node_modules/sharp
npm error command failed

Further down, the important part followed this pattern:

sharp: Downloading https://github.com/example/project/releases/download/v1.2.3/artifact.tar.br
sharp: Installation error: Request timed out

Their build was installing sharp through npm. In the version used by this project, the installation process also downloaded a prebuilt libvips archive from GitHub Releases.

So every clean build depended on GitHub being reachable and that release artifact continuing to exist there.

An outage could break the build temporarily, while things like a removed release, changed access policy or abandoned project could make that dependency unavailable indefinitely.

‍

GitHub release artifacts are build dependencies too

Sometimes these dependencies are obvious.

You might have something like this directly in a Dockerfile:

RUN curl https://github.com/example/project/releases/download/v1.2.3/tool.tar.gz -o tool.tar.gz

You can look at that and immediately see that GitHub is part of the build.

Other cases are much easier to miss.

For this customer, the dependency chain looked roughly like this:

npm install
  → sharp
  → install script
  → GitHub Releases
  → libvips archive

The libvips archive wasn't something they had added directly to package.json. It was fetched by another dependency during installation.

It is an easy dependency to miss. You can lock your npm dependencies and still have another dependency hiding behind one of them.

‍

Cache the artifact instead of downloading it every time

In this particular case, Sharp allowed the libvips download location to be changed through an environment variable.

The customer used that to route the download through StableBuild's file mirror. The setup follows this general pattern:

ENV npm_config_sharp_libvips_binary_host=https://YOUR-DOMAIN.httpcache.stablebuild.com/sharp-cache/https://github.com/example/project/releases/download

The first request still retrieves the artifact from GitHub. StableBuild stores the file as it passes through.

Later builds can use the cached copy instead of downloading the same artifact from GitHub again.

If GitHub is temporarily unreachable, the build no longer has to fail just because it needs a file that has already been cached.

The environment variable above is specific to this Sharp setup. Other tools will expose external downloads differently, but the goal is the same: get the artifact through the cache while the upstream copy is still available.

‍

The same problem exists beyond GitHub

GitHub happened to be the upstream service in this case, but direct file downloads can come from almost anywhere.

A build might depend on:

• GitHub release artifacts
• S3 buckets
• vendor download servers
• CDNs
• scripts fetched from URLs
• prebuilt binaries downloaded by another dependency

These dependencies can be easier to overlook than packages from npm or images from a container registry because they do not necessarily appear in a lockfile or manifest.

StableBuild's file mirror can cache these URL-based build inputs so later builds use the stored copy instead of depending on the original host every time.

The file still has to pass through StableBuild while the upstream copy is available. If something has already disappeared, StableBuild can't recreate a file it never stored.

‍

Find them before an outage does

Some external downloads will be obvious in your Dockerfile or build scripts. Others only appear several layers down inside a dependency.

One useful check is to occasionally run a clean build without network access and see what unexpectedly breaks. If an install or build step tries to reach GitHub, S3, a CDN or another external service, you have found another build input worth investigating.

You might decide to upgrade the dependency, vendor the artifact yourself or route it through a cache. What matters is knowing that dependency exists before it becomes the reason your build stops.

In this customer's case, an npm dependency also meant depending on an artifact hosted on GitHub Releases. Routing that download through StableBuild meant later builds could use the cached copy instead of requiring GitHub to serve the same file every time.

If your builds depend on files hosted on GitHub or elsewhere, you can create a free StableBuild account and preserve them through the file mirror.

‍