MinIO is deprecated: do you need a new object store, or just a maintained image?
Somewhere right now there’s a Kubernetes cluster serving object storage perfectly well, and a platform engineer who has just realized that if a node goes down tonight, it won’t come back.
Not because the data is gone. Because the image can’t be pulled. At Echo we maintain secure container images for infrastructure teams, which is how we ended up fielding a steady stream of questions about this particular one — enough that we wrote up what happened to MinIO’s Docker images and how to find a secure alternative in detail. The questions almost always arrive framed as “what do we migrate to?” And that framing, we think, is where teams go wrong.
What actually happened to MinIO?
MinIO’s community distribution was withdrawn in stages, not all at once. In October 2025 the project announced it would stop publishing free Docker images to Docker Hub. The upstream GitHub repository was archived on April 25, 2026, with a README stating “THIS REPOSITORY IS NO LONGER MAINTAINED.” In September 2026 the minio/minio Docker Hub repository was archived, and users reported that minio/minio and minio/mc could no longer be pulled.
The timing of the first step was the part that stung. The announcement landed alongside a critical security release, RELEASE.2025-10-15T17-29-55Z — so the teams most dependent on timely patching were the ones who lost their patching path first. The final image published to Docker Hub carried a known high-severity advisory.
The sequence matters more than any single date in it. This was not a project that vanished. It was a distribution channel that closed, in steps, over about a year — exactly the kind of change that doesn’t trigger an incident until the day it does.
Is MinIO broken, or is its distribution broken?
MinIO the software is not broken. It is the same S3-compatible object store it was eighteen months ago, running in production right now for thousands of teams. What broke is the supply line — the ability to pull a current, patched image when you need one. Echo’s position is that these are two separate problems, and that conflating them is what turns a packaging event into a migration project.
This distinction is the entire decision, and most of the conversation collapses it.
Read the situation as “MinIO is dead” and the obvious response is to pick a successor and migrate. That means a data migration, an S3 compatibility validation effort, re-tuning everything downstream that assumed MinIO’s behavior, and a rollback plan you hope not to use.
Read it as “my image source went away” and the response is smaller: find a maintained image source. It’s the same question every team eventually faces about consuming open source versus commercially maintained images, arriving sooner and with less warning than usual.
Those two responses differ by roughly a quarter of engineering effort, and teams are choosing between them under time pressure — the worst possible condition for that choice.
What breaks first if you do nothing?
Nothing, until something restarts. Running clusters keep serving objects indefinitely. The failure arrives the first time your orchestrator needs to pull the image again — a node failure, a rescheduled pod, a scaled replica, a cluster upgrade.
This is why the problem feels theoretical until it isn’t. Your monitoring is green, your buckets respond, and the only thing standing between you and an outage is that no pod has needed rescheduling yet.
The second failure mode is slower and worse: you’re now running a frozen image against a moving CVE landscape. Every vulnerability disclosed against anything in that image is permanent. No upstream fix is coming, because upstream has stopped shipping. Your remediation path becomes rebuilding MinIO from source yourself — recompiling, validating dependencies, applying the hardening work a maintained image normally absorbs for you, then doing it again every time something new lands.
That’s a standing commitment most teams discover they’ve made only after they’ve made it, and the cost tends to show up somewhere other than the security budget.
Should you migrate to Garage, RustFS, or SeaweedFS?
Yes — if you want to leave MinIO for architectural reasons. Garage is built around geographically distributed, multi-site deployments. RustFS takes design inspiration from MinIO and suits teams wanting a familiar distributed model. SeaweedFS is a broader platform spanning S3, FUSE, HDFS, WebDAV and SFTP, at the cost of more operational surface.
These are real projects solving real problems, and Echo isn’t going to pretend otherwise in order to sell an image. If your requirements have outgrown MinIO — if you need multi-site replication as a first-class design property rather than a bolt-on — migrating is the right call and one of these is probably where you’ll land.
Get Echo’s stories in your inbox
Join Medium for free to get updates from this writer.
But notice what’s happened if you migrate because the image disappeared. You’ve let a packaging event make an architecture decision for you. You’ll be validating S3 compatibility against real workloads under deadline, in a quarter you hadn’t planned for, to solve a problem that was never about object storage design in the first place. Migrations go well when they’re planned as migrations rather than executed as incident response.
The architecture question and the availability question deserve separate answers, on separate timelines.
What is Echo’s MinIO alternative, and why isn’t it a migration?
Echo publishes a secure, minimal, continuously updated MinIO container image. You replace the image reference in your Dockerfile or deployment manifest and change nothing else — your storage endpoints, credentials, environment variables and startup commands work exactly as they did, because the Echo image is a drop-in replacement for MinIO’s discontinued one.
That’s the whole change. No data migration, no S3 compatibility testing, no downstream re-tuning, because nothing downstream has changed. The S3 API your applications call is the same API.
What the Echo image adds on top of staying put:
- A minimal starting point — built on Echo’s zero-CVE base layer, without packages MinIO never needed
- Patching that continues — automatically rebuilt and rescanned on every upstream change and CVE disclosure, including the high-severity advisory present in the final Docker Hub image
- Evidence you can hand to an auditor — reproducible builds, with SBOMs and provenance attestations for every Echo release
Echo didn’t start maintaining this image because of the deprecation. MinIO was already in our catalog of secure images. The deprecation simply made visible what that catalog is for: upstream distribution can change overnight, and when it does, somebody needs to still be building.
How do you know a third-party image is safe to trust?
Ask what evidence ships with it. An image you can’t verify is a different kind of supply chain risk, not a smaller one — you’ve swapped a missing maintainer for an unknown one. Echo’s answer is that every image ships with an SBOM, provenance attestations and reproducible builds, so the claims are checkable rather than asserted.
The things worth demanding, from Echo or anyone else:
Provenance and signatures, so you can prove the artifact came from the build system it claims to and hasn’t been altered since. An SBOM per tag, so “minimal” is a verifiable claim rather than an adjective. A stated rebuild cadence, because an image that isn’t rebuilt against new vulnerability data is a frozen image with a different logo on it. Visibility in your own scanner — if the improvement shows up only in a vendor console and not in the Trivy or Wiz report your auditors actually read, it isn’t an improvement you can evidence.
Trusting a new image source is a real decision. Make it on artifacts, not assurances.
So how should you decide?
Two questions, in this order. First: do I want to run MinIO a year from now, on the merits? Second: how do I keep it patched and pullable in the meantime? Echo exists to answer the second one so that the first can be answered calmly.
If the answer to the first is no, migrate — deliberately, scoped, on a schedule you chose, to whichever of Garage, RustFS or SeaweedFS fits the architecture you actually want to operate.
If the answer is yes — and for most teams running MinIO happily today, it is — then you have a distribution problem wearing a deprecation costume. Solve it as a distribution problem. With Echo it’s one line in a manifest, and it buys back the time to make the architecture decision properly.
The worst outcome here isn’t picking the wrong object store. It’s letting an image pull failure at 2 a.m. pick one for you.
Echo is an independent software provider. We are not affiliated with, endorsed by, or sponsored by MinIO. MinIO is a registered trademark of its respective owner. Echo provides a secure, verified alternative to their container distribution.
