Docker Hub Is Down

I guess the best way would be to have a self-hosted pull-through registry with a cache. This way you'd have all required images ready even when dockerhub is offline.

Unfortunately that does not help in an outage because you cannot fill the cache now.

  docker image ls
  docker tag name/name:version your.registry/here/name/name:version
  docker push your.registry/here/name/name:version

It's a bit stupid that I can't restart (on Coolify) my container, because pulling the image fails, even though I am already running it, so I do have the image, I just need to restart the Node.js process...

> I don't work on mission-critical software

> wondering what my alternate deployment routes are

If the stakes are low and you don't have any specific need for a persistent registry then you could skip it entirely and push images to production from wherever they are built.

This could be as simple as `docker save`/`scp`/`docker load`, or as fancy as running an ephemeral registry to get layer caching like you have with `docker push`/`docker pull`[1].

[1]: https://stackoverflow.com/a/79758446/3625

> Is there a mirror registry with all the same basic images?

https://gallery.ecr.aws/

I’ll admit I haven’t checked before posting, perhaps an admin can merge both submissions and change the URL on the one you linked to the one in this submission.

I think it was likely caused by the cache trying to compare the tag with Docker Hub: https://docs.docker.com/docker-hub/image-library/mirror/#wha...

> "When a pull is attempted with a tag, the Registry checks the remote to ensure if it has the latest version of the requested content. Otherwise, it fetches and caches the latest content."

So if the authentication service is down, it might also affect the caching service.

In our ci setting up the docker buildx driver to use the artifact registry pull through cache involves (apparently) an auth transaction to dockerhub which fails out

I’m able to pull by the digest, even images that are now missing a tag.

Basically all my Docker images were being built from Github repos anyways, so I just switched to Github's container registry.

Quay.io is nice (but you have to memorize the spelling of its name)

We use a https://container-registry.com, which is a clean version of the open source Harbor registry software (https://goharbor.io/) from one of the maintainers. It works well and reliable for years now and has no vendor-lock-in thanks to Harbor.

Not Debian itself, but Red Hat's registry has them: https://quay.io/organization/lib

same

You pull the images you want to use, preferably with some automated process, then push them to your own repo. And anyways use your own repo when pulling for dev/production. It saves you from images disappearing as well.

The images I use the most, we pull and push to our own internal registry, so we have full control.

There are still some we pull from Docker Hub, especially in the build process of our own images.

To work around that, on AWS, you can prefix the image with public.ecr.aws/docker/library/ for example public.ecr.aws/docker/library/python:3.12 and it will pull from AWS's mirror of Docker Hub.

Someone mentioned Artifactory; but its honestly not needed. I would very highly recommend an architecture where you build everything into a docker image and push it to an internal container registry (like ecr; all public clouds have one) for all production deployments. This way, outages only affect your build/deploy pipeline.

Another reply had some good insight: https://news.ycombinator.com/item?id=45368092

I had some images in cache, but not all of them, and pull is failing

for example, i have redis:7.2-alpine in cache, but not golang:1.24.5-alpine

I needed the golang image to start my dev-backend

so i replaced FROM golang:1.24.5-alpine with FROM redis:7.2-alpine, and manually installed golang with apk in the redis container :)

CNCF has harbor [0], which I use at home and have deployed in a few clusters at work, and it works well as a pull through cache. In /etc/containers/registries.conf it's just another line below any registry you want mirrored.

    [[registry]]
    location = "docker.io"
    [[registry.mirror]]
    location = "core.yourharbor.example.com/hub"

Where hub is the name of the proxy you configured for, in this case, docker.io. It's not quite what you're asking for but it can definitely be transparent to users. I think the bonus is that if you look at a podspec it's obvious where the image originates and you can pull it yourself on your machine, versus if you've mutated the podspec, you have to rely on convention.

[0] https://goharbor.io/

Not Google Artifact Registry... Our Docker Hub pull-through mirror went down with the Docker Hub outage. Images were still there but all image tags were gone

We do a local (well, internal) mirror for "all" these things. So, we're basically never stuck. It mirrors our CPAN, NPM, Composer, Docker and other of these web-repos. Helps on the CI tooling as well.

Quay.io

I've been using Amazon ECR as an alternative source.

https://gallery.ecr.aws/

I've been using https://github.com/enix/kube-image-keeper on some of my clusters - it is a local docker registry running on cluster, with a proxy and mutation webhooks. I also evaluated spegel, but currently it isn't possible to setup on GKE

I usually do upstream image mirroring as part of CI. Registries are built into GitLab, AWS (ECR), GitHub, etc

You can use Artifactory as a "front" for a variety of registries, including Docker, so it'll pull once and then use its cached image.

I'm using a different approach for local testing where I don't want to redownload images over and over: https://github.com/stackabletech/k8s-local-dev

Basically it's a k3s configured to use a local mirror and that local mirror is running the Zot registry (https://zotregistry.dev/v2.1.8/). It is configured to automatically expired old images so my local hard drive isn't filled up).

Depending on what other (additional) features you're willing to accept, the GoHarbor[0] registry supports pull-through as well as mirroring and other features, it's a nice registry that also supports other OCI stuff like Helm charts, and does vulnerability scanning with "Interrogation Services" like Trivy.

I've been using it at home and work for a few years now, might be a bit overkill if you just want a simple registry, but is a really nice tool for anyone who can benefit from the other features.

[0] https://goharbor.io/

Tech support needs to log the server in to its account to get a bigger quota.

Hard to see if this is /s or not. Nobody is forcing you to run images straight from dockerhub lol. Every host keeps the images already on it. Running a in-house registry is also a good idea.

There's a registry image for OCI containers that is pretty painless to set up and low maintenance, can use s3 as a storage backend.

https://hub.docker.com/_/registry

Your git provider probably also has a container registry service built in.