25 comments

[ 4.2 ms ] story [ 49.6 ms ] thread
...well this explains a lot about how my morning is going...
I guess people who are running their own registries like Nexus and build their own container images from a common base image are feeling at least a bit more secure in their choice right now.

Wonder how many builds or redeployments this will break. Personally, nothing against Docker or Docker Hub of course, I find them to be useful.

This broke our builds since we rely on several public Docker images, and by default, Docker uses docker.io.

Thankfully, AWS provides a docker.io mirror for those who can't wait:

  FROM public.ecr.aws/docker/library/{image_name}
In the error logs, the issue was mostly related to the authentication endpoint:

https://auth.docker.io → "No server is available to handle this request"

After switching to the AWS mirror, everything built successfully without any issues.

So thus far today outages are reported from

- AWS

- Vercel

- Atlassian

- Cloudflare

- Docker

- Google (see downdetector)

- Microsoft (see downdetector)

What's going on?

(comment deleted)
What are good proxy/mirror solutions to mitigate such issues? Best would be an all in one solution that for example also handles nodejs, packigist etc.
Is there a built-in way to bypass the request to the registry if your base layers are cached?
even reddit throws a lot of 503s when adding/editing comments
Does it decrease the AWS's nine 9s ?
I wonder if this is why I also can't log in to O'Reilly to do some "Docker is down, better find something to do" training...
Shameless plug but this might be a good time to install Spegel in your Kubernetes clusters if you have critical dependencies on Docker Hub.

https://spegel.dev/

what good options are there for container registry proxies / caches to protect against something like this?
Recovering as of October 20, 2025 09:43 UTC

> [Monitoring] We are seeing error rates recovering across our SaaS services. We continue to monitor as we process our backlog.

For other people impacted, what helped me this morning was to use the `ghcr`, albeit this is not a one-to-one replacement.

Ex: `docker pull ghcr.io/linuxcontainers/debian-slim:latest`

Its impressive that even though registry-1.docker.io returned 503 errors they where able to keep a the metric "Docker Registry Uptime" at 100%.
I'm fairly new to Docker. Do folks really rely on public images and registries for production systems? Seems like a brittle strategy.
It's quite funny/interesting that this is higher in HN front page than the news of the AWS outage that caused it.
The internet was designed to be fault tolerant and distributed from the beginning and we still ended up with a handful of mega hosts.
mirror.gcr.io is your friend
Hi all, Tushar from Docker here. We’re sorry about the impact our current outage is having on many of you. Yes, this is related to the ongoing AWS incident and we’re working closely with AWS on getting our services restored. We’ll provide regular updates on dockerstatus.com .

We know how critical Docker Hub and services are to millions of developers, and we’re sorry for the pain this is causing. Thank you for your patience as we work to resolve this incident. We’ll publish a post-mortem in the next few days once this incident is fully resolved and we have a remediation plan.

this is by design

docker got requests to allow you to configure a private registry, but they selfishly denied the ability to do that:

https://stackoverflow.com/questions/33054369/how-to-change-t...

redhat created docker-compatible podman and lets you close that hole

/etc/config/docker: BLOCK_REGISTRY='--block-registry=all' ADD_REGISTRY='--add-registry=registry.access.redhat.com'

This is a huge stretch.

Even if you could configure a default registry to point at something besides docker.io a lot of people, I'd say the vast majority, wouldn't have bothered. So they'd still be in the same spot.

And it's not hard to just tag images. I don't have a single image pulling from docker.io at work. Takes two seconds to slap <company-repo>/ at the front of the image name.