Keep Shipping Through Docker Hub Outages and Rate Limits

Your CI pipeline has a dependency you don't own and can't fix: Docker Hub. When it's down, rate-limited, or having a bad day, your builds fail. A read-through cache in front of Docker keeps them running through those failures.

Your build stands on a single point of failure

Every docker pull in your pipeline is a live network call to infrastructure you don't control. Docker Hub has two failure modes, and a paid plan closes only one of them.

Failure mode 1: outages

At 06:48 UTC on October 20, 2025, AWS us-east-1 degraded, and Docker Hub runs there. Image pulls broke across Docker Hub, Scout, Build Cloud, and Testcontainers Cloud, and didn't fully recover for about 12 hours. Docker's own incident report is blunt:

Among Docker's services, Hub's registry operations, especially image pulls, are the most heavily used and the most essential to keeping developer workflows moving.

And it recurred. Docker's status history logs more registry and authentication incidents since: a full Hub and Registry disruption on December 5, 2025, an auth failure two weeks later, and degraded registry performance in March 2026.

A paid plan buys unlimited pulls, not a second registry, so when Docker Hub went down, Business customers went down with everyone else.

Failure mode 2: rate limits

You don't even need an outage to get blocked. Docker Hub enforces pull rate limits:

Exceed the limit and Docker Hub returns 429 Too Many Requests:

toomanyrequests: You have reached your pull rate limit.
You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limits

This mostly bites unauthenticated pulls. CI runners share public IP addresses, so unrelated jobs burn the anonymous 100-pull quota collectively, and a busy afternoon can start returning 429s. Authenticating your CI clears it, and that's the right first move: paid plans make pulls unlimited. But "unlimited" is subject to fair use, and a separate abuse limit "applies to all users equally regardless of account level." Those thresholds are high, so most teams won't hit them.

The deeper point is the one no plan changes: unlimited or not, every pull still depends on Docker Hub being up and willing to serve it. That dependency is what a cache removes.

Either way, the vendors agree: cache it

Whatever tier you're on, the companies running this infrastructure recommend the same fix.

Docker, in its October 2025 postmortem, lists caching among the mitigations:

[...] ensuring customers can continue accessing frequently used images even during partial outages.

AWS advises copying public Docker Hub images into a private registry. GitLab runs a pull-through cache for its hosted runners:

For hosted runners on GitLab.com, we use Google Cloud's pull-through cache [...] For most users, configuring the Dependency Proxy with Docker Hub authentication is the most efficient long-term solution.

Red Hat recommends a local mirror for the same reason:

CI/CD pipelines might start to fail building and rolling out your software [...] [deploy a registry to] provide a fast, local cache of public image repositories.

The recommendation is consistent: don't pull straight from the public registry in CI. Put a cache in front of it.

What about the CI platforms?

A few CI vendors have taken this on. They differ in what they cover, whether they survive an outage, and whether the fix works beyond their own runners.

GitHub's and CircleCI's exemptions remove the 429 throttle, but those runners still pull live from Docker Hub, so when the registry goes down they fail anyway. Only a cache keeps building through an outage.

The caches that survive an outage still take setup. Depot is a pull-through cache, but you create pull-through repositories and rewrite your pulls to Depot image references. Blacksmith's is opt-in via a support ticket.

Nx Cloud's is an add-on you flip on, with none of that setup.

The Docker read-through cache in Nx Cloud

A read-through cache sits between your builds and the registry: the first pull fetches an image from upstream and caches it, and later pulls are served locally. The catch has always been standing up and operating that mirror yourself.

Nx Cloud's Docker read-through cache removes that work. It puts a registry mirror close to your Nx Agents, so every pull routes through the cache automatically. That gives you:

• Outage resilience. While Docker Hub is down, builds keep pulling whatever the cache has retained. Cold misses still need upstream, but your everyday base images are covered.
• Rate limits stay out of the way. Agents pull through the cache instead of hitting Docker Hub directly, keeping you well under the limit.
• Faster builds. A local cache hit beats a round trip to a public registry.

It works automatically once enabled, with no changes to your Dockerfiles, docker pull commands, or image references. It fronts Docker Hub, caching the public images your agents pull.

If your CI already runs on Nx Cloud agents on a dedicated compute cluster, you enable the cache as an add-on from your Nx Cloud settings and every agent picks it up. Billing is usage-based, per agent per CI run, on top of the dedicated cluster (no provisioning fee, $99/month minimum spend).

Not running on Nx Cloud agents yet?

The cache lives on Nx Cloud agents, so you need your CI running there. If you already use Nx Agents on a dedicated compute cluster, the add-on is one step away. If not, you move CI onto Nx Cloud agents first. Use AI assistance to move your existing CI setup to Nx Agents, which gives you remote caching, task distribution, flaky task re-runs, self-healing CI, and more.

Stop pulling straight from Docker Hub

If your team ships software for a living, "our deploy is blocked because Docker Hub is down" isn't an acceptable status update, and it's avoidable. Put a cache between your CI and the registry, and the next time Docker Hub is down or rate-limited, your builds keep running.