MinIO Vanished From Docker Hub: The One-Line Fix and the Migration You Actually Owe Yourself

On September 11, 2026, docker compose pull started failing for MinIO users everywhere — not with a rate limit or an auth prompt, but with pull access denied for minio/minio, repository does not exist or may require 'docker login'. The repository genuinely does not exist anymore. MinIO deleted both minio/minio and minio/mc from Docker Hub between September 11 and 14, and the Hub API now answers object not found for both. If your machine had cached layers, nothing changed. If it didn't — a fresh server, a new CI runner, a teammate's laptop — your storage service simply stopped deploying.

The fix is one line, and this post gives it to you in the next section. But the fix is also a trap if you stop there, because the quay.io image you'll repoint to is frozen in time and will never receive another security patch. So this post does three things: the immediate repair, the five-year history that explains why it happened, and an honest comparison of the three exits worth considering now.

The one-line fix: repoint to quay.io​

MinIO publishes the same images to its own registry at quay.io/minio, and those repositories are still live, still public, and still anonymous — no login required. The tags and manifest digests are byte-identical to what Docker Hub served, which means your pinned versions keep working with only a registry-prefix change. In every compose file, CI workflow, and Helm values file that references MinIO:

# Before — dead since September 11, 2026
image: minio/minio:RELEASE.2025-09-07T16-13-09Z
 
# After — same image, live registry
image: quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z

Do the same for minio/mc → quay.io/minio/mc. Then verify cold, the way the next machine will see it: delete the local images and bring the stack up from an empty cache.

docker rmi minio/minio minio/mc 2>/dev/null
docker compose pull && docker compose up -d

If you pin by digest rather than tag — and you should — the digests carry over unchanged, since quay.io serves the same manifests Hub did. At least one large project, Unstract, handled the migration exactly this way: same digests, new registry prefix, verified against a cold pull.

There is a lesson hiding in that sentence worth stating plainly, because one operator wrote it better than anyone else in their repoint commit: pinning protects against drift, not against removal. A digest pin guarantees the bits never change under you. It says nothing about the registry continuing to serve them. The teams that pinned diligently and the teams that floated on latest broke identically on September 11 — the only machines that survived were the ones with warm layer caches. Keep pinning. But stop believing a pin is a supply-chain strategy on its own. Section six below covers what actually is.

How we got here: a five-year wind-down in one table​

Nobody watching MinIO should be shocked, even if the timing surprised everyone. The Docker Hub deletion is the last step of a retreat from community distribution that has been unfolding since 2021:

One nuance matters enormously and most coverage gets it wrong: MinIO did not relicense, and MinIO did not go proprietary. The server code is still AGPLv3, still public, still forkable. What ended was maintenance and distribution — no new releases, no reviewed patches, no official community binaries. The path went from "pull the image" to "build it yourself from frozen source," and now the frozen images are leaving the places you'd pull them from too. MinIO Inc. directs users toward its commercial AIStor product, whose containers require a paid license to run.

That framing changes the decision. This isn't a license-compliance emergency; nothing you run today became illegal. It's a maintenance cliff: every MinIO Community deployment is now running software that will never be patched again, distributed through channels that are actively being dismantled.

Why quay.io is a stopgap, not a strategy​

The quay.io repositories work today, and there is no announced date for their removal. But consider what they contain: the last community release, RELEASE.2025-09-07, is already a year old, and nothing newer will ever land beside it. Every CVE in MinIO's dependency tree discovered from this point forward stays open in your deployment forever. The quay.io repoint buys you a working docker compose pull; it buys you zero future.

So treat the repoint as triage with an expiry date you set yourself. A reasonable priority order:

1. Internet-exposed MinIO clusters first. Anything reachable beyond your own network is running unpatchable S3-compatible storage with credentials attached. Migrate these on a real deadline, not a backlog wish.
2. CI and test fixtures second. These are the lowest-risk moves — often a single image swap in a compose file — and several projects have already demonstrated the pattern. Laravel Sail removed its MinIO service entirely and now ships RustFS as the S3-compatible replacement; test-only MinIO usage is the easiest footprint to eliminate.
3. Internal, network-isolated deployments last. A MinIO instance that only your own services reach, behind auth, on a private network, can ride the quay.io image while you plan. "Can" is doing heavy lifting in that sentence — schedule the migration anyway.

With triage sorted, the actual question is where to go. There are three serious answers, and they suit different teams.

The three exits, compared honestly​

The 2026 consensus among teams that already migrated is unusually consistent: SeaweedFS or Garage for pragmatic self-hosted deployments, Ceph's RADOS Gateway if you operate at enterprise scale, and RustFS only in monitored pilots for now. Here's the honest version of each:

SeaweedFS is the default recommendation for a reason. It's Apache-2.0 licensed, which ends the AGPL anxiety that has followed MinIO since 2021 for teams embedding storage next to commercial code. Operationally it's genuinely simple: a single container can serve the master, volume servers, filer, and S3 gateway together, so the "one box, one S3 endpoint" shape that made MinIO beloved survives intact. It has the longest independent track record of the three and the richest S3 API surface. If you just want this migration over with, start here.

Garage, from the Deuxfleurs collective, is the lightweight pick — small resource footprint, designed for self-hosted and multi-site deployments from the start. The tradeoffs are real: it keeps the AGPL license MinIO defectors may be fleeing, and a cluster needs its storage layout assigned before it serves traffic, which is more ceremony than MinIO's "point at a directory" bootstrap. Choose it when you run lean nodes or genuinely want geo-distributed buckets, not when you want the shortest migration.

RustFS is the intriguing one: a Rust-based, Apache-2.0 project explicitly positioning as a MinIO drop-in, and Laravel Sail's chosen replacement. The catch is maturity — pre-1.0, and every careful operator in 2026 files it under "monitored pilot," not "production default." That's not a dismissal; it's a sequencing suggestion. Pilot it where failure is cheap, watch its release cadence, and revisit in six months.

Above all three sits Ceph RGW, the right answer if you already operate Ceph or need enterprise-grade S3 at scale — and massive overkill if you don't. Nobody should adopt Ceph to replace a single MinIO container.

Whichever exit you take, the migration itself is the easy part of this story: these are all S3-compatible endpoints, so mc mirror, rclone sync, or your SDK's copy path moves the data without application rewrites. The hard part was deciding; the table above is the decision.

The real lesson: Docker Hub is a single point of failure​

Zoom out from MinIO, because the deeper failure here belongs to everyone who treats a public registry as durable infrastructure. Docker Hub has now demonstrated — not hypothetically, in production, across thousands of compose files — that a repository you depend on can vanish with no notice period, no deprecation window, and no redirect. Your digest pin survives the content changing; it does not survive the content leaving.

A self-hosted fleet should treat every public registry as a cache with someone else's eviction policy. Concretely, that means two layers:

Pin everything by digest. Tags are mutable nicknames; digests are content addresses. image: quay.io/minio/minio@sha256:… cannot silently become a different image next Tuesday. This is table stakes, and the MinIO episode doesn't change it — it just proves it's necessary but not sufficient.

Run a pull-through mirror you control. Registry, Harbor, or even a cron job that re-pushes pinned digests into your own registry namespace — the mechanism matters less than the property: a deploy of your fleet must never require a third-party registry to be reachable, solvent, and still hosting your images. Mirror on a schedule, alert when an upstream tag disappears, and deploy from the mirror. Had every affected team done this, September 11 would have been a monitoring event ("upstream minio/minio gone, serving from mirror") instead of a broken-deploy event.

The cost of a mirror is one small stateful service. The cost of not having one is discovering, at the worst possible moment, that your infrastructure's first dependency is a URL you don't own.

What to do Monday morning​

If you run MinIO Community Edition, your checklist is short. First, repoint every minio/minio and minio/mc reference to quay.io/minio and verify with a cold pull — that restores green builds today. Second, inventory where MinIO runs and sort by exposure: internet-facing clusters get a migration deadline, test fixtures get swapped opportunistically, isolated internal instances get a scheduled plan. Third, pick your exit from the table above — SeaweedFS for most, Garage for lean multi-site, RustFS as a pilot — and start the S3-to-S3 copy. Fourth, stand up the registry mirror so the next deletion is a notification instead of an outage.

September's removal wasn't the license change, the console stripping, or the archive notice. Those were all warnings you could defer. A deleted repository breaks your next deploy, on every cold machine, with no workaround except leaving. That forcing function is finally here — use it.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Self-hosting means owning your whole supply chain, registry mirrors included. Star the repo on GitHub or deploy your first app today.