Skip to main content

RustFS Hits 1.0 as Docker Hub Drops MinIO: Your Forced S3 Migration, Mapped

8 min readDora NodaDora Noda
Share
On this page

Your MinIO redeploy broke last week, and the fix is two lines in your Compose file. Sometime between September 11 and 14, the minio/minio and minio/mc repositories vanished from Docker Hub: anonymous pulls now fail with pull access denied, the Hub API answers 404 for the repository, and every CI run, fresh install, and pruned server that pulls MinIO from Docker Hub goes red at the pull step before a single container starts. If your image cache still holds a copy, everything looks fine — until the next docker compose pull on a cold cache.

If you only have 30 seconds: repoint your MinIO image to quay.io/minio/minio, pinned by digest, today — that restores redeploys. Then, this month, move your buckets to a maintained S3 implementation. RustFS reaching 1.0 general availability on September 16, days after the Hub deletion, finally gives the MinIO-shaped successor a production stamp. This post maps both steps: the ten-minute bridge and the real migration.

What actually happened: a 16-month wind-down in one table

The Docker Hub deletion looks sudden, but it is the last step of a wind-down MinIO Inc. has been executing since 2025. The community edition was not relicensed — the server code is still AGPLv3 — but maintenance and distribution ended in stages:

DateWhat happened
May 2025Full admin console removed from the community edition, moved behind the commercial AIStor paywall
Oct 2025Community image publishing stopped; last CE build is RELEASE.2025-09-07T16-13-09Z
Dec 2025minio/minio repository enters maintenance mode
Feb 2026README changed to "THIS REPOSITORY IS NO LONGER MAINTAINED"; repository archived (formally read-only since April 2026)
Sept 11–14, 2026minio/minio and minio/mc deleted from Docker Hub; anonymous pulls return 401, repo API returns 404

What still works right now: any host with a cached image keeps running MinIO normally, the source remains buildable for anyone willing to self-build, and MinIO-published copies of the last releases still exist on quay.io/minio/minio — including a security-hotfixed rebuild, RELEASE.2025-09-07T16-13-09Z.hotfix.7aa24e772, patched as recently as April 2026 (amd64-only). The quay.io copies carry no stated retention promise, so treat them as a bridge, not a home.

The blast radius is visible across GitHub: self-hosted projects spent mid-September landing one-line fixes — Dokploy deploys failing on minio/mc:latest with "pull access denied" while the server limped along on a cached minio/minio, kind clusters with MinIO pods stuck in ImagePullBackOff, CI test jobs failing at docker compose up with "repository does not exist". Every report has the same shape: it worked until a cold pull, then nothing pulled at all.

Step 1 — the 10-minute bridge: repoint to quay.io, pinned by digest

Do this first, before any migration planning. In every Compose file, Dockerfile FROM, and CI workflow that references MinIO, swap the registry and pin the digest so the bridge is reproducible:

yaml
# before: dead on any cold cache
image: minio/minio:RELEASE.2025-09-07T16-13-09Z
 
# after: the same MinIO-published release, from the surviving registry
image: quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z

Then resolve and pin the digest so no future tag move can surprise you:

bash
docker pull quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z
docker inspect --format='{{index .RepoDigests 0}}' quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Z

Apply the same repoint to minio/mcquay.io/minio/mc, since your migration tooling needs mc and it vanished from the Hub in the same deletion. Verify with a cold pull on a machine that never cached the image — docker compose pull succeeding there is the actual proof, not a green run on your warm laptop.

This buys you working redeploys on an archived, unmaintained binary. Internet-exposed clusters should not stop here: no new releases, no reviewed patches, and no guaranteed security fixes are coming for the community edition. The bridge exists to give the real migration a calm schedule, not to cancel it.

Step 2 — pick the successor: RustFS 1.0 vs Garage vs SeaweedFS

Until this month, the honest guidance — repeated across May 2026 evaluations — was that RustFS belonged in monitored pilots only, while pragmatic self-hosted deployments should pick SeaweedFS or Garage and enterprises should look at Ceph RGW. The September 16 GA changes that calculus, but it does not end the comparison. Here is the field as it stands:

RustFS 1.0GarageSeaweedFS
LicenseApache 2.0AGPLv3Apache 2.0
MaturityGA Sept 2026; ~2.5 years of development, 32,000+ stars, 2.7M+ deployed instancesStable, slower-moving single binary~12 years in production
MinIO-shaped?Yes — designed as a drop-in, same port 9000 API + 9001 console shapeNo — own config and topology modelPartially — S3 emulation over 4 subsystems
Single-node fitYes, one processAwkward — replication_factor=1 is advised againstWorkable, more moving parts
S3 completenessGood; lifecycle, multipart, erasure coding, tiering, plus S3 Tables with an embedded Iceberg REST catalogBasic-good; no S3 Object LockGood; richer S3 API than Garage
ConsoleBuilt-in, replaces MinIO's removed consoleWebUI includedIncluded

The per-profile read:

  • Closest thing to the MinIO you ran: RustFS. Same operational shape, Apache 2.0 instead of AGPL, and the GA stamp means a supportable production designation rather than a beta you apologize for. Real migrations already exist to copy from: Formbricks replaced bundled MinIO with RustFS in its self-hosted setup, and homelab operators have published full cutover designs.
  • Single binary, minimal operational surface: Garage, accepting the AGPLv3 implications and the multi-node-first design. Best when you run several nodes and want geo/edge replication without a complex stack.
  • Battle-tested at real scale: SeaweedFS (or Ceph RGW if you already operate Ceph). Twelve years of production history is a durability argument no 1.0 can match.

Be clear-eyed about what "1.0" means. Independent pre-GA evaluation found RustFS functionally a working MinIO drop-in but with a large read-latency regression versus MinIO, and the GA-week guidance still reads: production-ready for S3-centric, write-heavy workloads, no full feature parity yet, MinIO's ecosystem and read-mixed performance still lead. Beta-to-beta upgrades broke deployments earlier this year, so treat your first upgrade past 1.0 as a tested procedure, not a routine bump. The responsible rollout is the one every GA-week guide repeats: migrate one workload first, measure it against your current MinIO numbers, then move the rest.

Step 3 — move the buckets: the mc mirror runbook

The good news is that mc speaks plain S3 and works against any S3-compatible endpoint, RustFS included — so the migration needs no MinIO-specific tooling and your old stack can keep serving while you copy. Stand up the successor next to the existing MinIO, then:

bash
# point mc at both ends (same credentials work if you reuse them)
mc alias set old http://minio:9000 "$MINIO_ACCESS_KEY" "$MINIO_SECRET_KEY"
mc alias set new http://rustfs:9000 "$MINIO_ACCESS_KEY" "$MINIO_SECRET_KEY"
 
# create the destination buckets, then preview the copy
mc mb --ignore-existing "new/my-bucket"
mc mirror --dry-run "old/my-bucket" "new/my-bucket"
 
# copy with metadata preserved, then verify byte-for-byte
mc mirror --preserve "old/my-bucket" "new/my-bucket"
mc diff "old/my-bucket" "new/my-bucket"

Repeat per bucket, then cut over in this order: point writers at the new endpoint, run one final mc mirror --preserve to catch stragglers, verify with mc diff until it is empty, and only then point readers over and stop the old container. Rollback is pointing the endpoints back — nothing in this procedure mutates the source buckets, so keep the old MinIO stopped-but-present until the new store has survived at least one full backup cycle.

Two Compose-level gotchas from real migrations: RustFS takes its data directories from a RUSTFS_VOLUMES environment variable rather than MinIO's server positional argument, so the command line changes shape, not just the image name. And RustFS's built-in console on port 9001 replaces both MinIO's removed console and any sidecar console container you added after May 2025 — delete the sidecar instead of migrating it.

The lesson: free distribution is a pricing experiment, not infrastructure

Zoom out and the pattern is uncomfortably familiar: a free platform dependency — here, MinIO's Docker Hub distribution — behaved like infrastructure right up until it behaved like a discontinued experiment. Self-hosters just learned the registry version of a lesson PaaS tenants keep relearning about "free" feature lines: an image you pull but do not control is a promise, not a possession.

Three rules harden you against the next one:

  1. Pin every third-party image by digest, not tag. A digest pin would not have survived this deletion either — but it would have made the quay.io bridge a one-line registry swap with identical bytes, instead of a scramble to figure out which tag you were actually running.
  2. Mirror images you cannot afford to lose into a registry you control. The projects that shrugged at this deletion kept a local mirror or a warm cache on every host; the ones that paged depended on a cold pull from someone else's namespace.
  3. Treat archived upstreams as incidents with a slow fuse. The February archive notice was the real alarm; September was just the explosion. When a dependency you run in production announces source-only distribution, the migration plan starts that week, not when the pulls fail.

MinIO defined self-hosted S3 for a decade, and its wind-down deserves a moment of respect alongside the runbook. But the ecosystem it leaves behind is healthier than the obituaries suggest: a GA-stamped Apache 2.0 successor in RustFS, a stable minimalist in Garage, and a twelve-year veteran in SeaweedFS. Pick one, mirror your images, and make September's scramble the last cold-cache surprise you ever debug.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex