MinIO archives its open-source repo, leaving self-hosted object storage unpatched
On April 25, 2026, the minio/minio repository was archived as read-only, cutting the self-hosted S3 server off from new fixes and releases. On August 24, 2026, Docker announced it would maintain MinIO through a paid ELS subscription, forcing self-hosters to decide before their next audit.
April 25, 2026. Read-only. A billion pulls. On April 25, 2026, the owner of the minio/minio repository archived it on GitHub: the code is now read-only, the last contribution dates to April 24, 2026, and no further release, fix, or backport will come out of the open-source branch. On August 24, 2026, Docker made its answer public: take over MinIO maintenance through its Extended Lifecycle Support (ELS) offering, for a fee. For a self-hoster storing backups, media, and application buckets on MinIO, the clock has started.
An archive, not a pause
The archive is not a governance footnote. MinIO is an S3-compatible object store, shipped as a single binary, licensed under AGPL-3.0, and one of the most widely deployed servers in self-hosting — the free equivalent of Amazon S3 for anyone who wants to keep data at home. Docker pegs its official image at more than a billion pulls.
When a repository of that scale goes read-only, the consequence is mechanical: the next CVE found in MinIO or its Go dependency tree will have no upstream patch. The images you pull today are frozen. Vulnerability scanners will keep flagging them, and a compliance audit will read “unmaintained software in production”.
The dates deserve precision. GitHub records an archive by the owner on April 25, 2026. Docker, in its August 24, 2026 announcement, places the end of open-source releases at February 13, 2026. Whichever date you hold to, at the time of writing the minio/minio repository is read-only — verifiable in a single API call.
Why this goes beyond MinIO
MinIO’s fate is only a symptom. Docker cites Black Duck’s 2026 Open Source Security and Risk Analysis, which found that 93% of commercial codebases carry components with no development activity for at least two years. The same pattern runs everywhere: Node 18, Python 3.8, and older Airflow releases still run in production long after upstream support ended.
What is new is that regulatory frameworks turn that technical debt into an audit finding. FedRAMP, DORA, and the EU Cyber Resilience Act treat unpatched end-of-life software as a compliance gap. The migration timeline is no longer set by the internal roadmap — it is set by the audit calendar. For MinIO, the question is no longer “when do we migrate” but “what do we do before the next review”.
Three options, no fourth
In practice, a self-hoster running MinIO today has three exits, and “do nothing” is not one of them:
- Migrate to a replacement. This is the sound long-term path: SeaweedFS, Garage (the lightweight S3 server from Deuxfleurs), a Ceph RGW if you already run Ceph, or a return to managed S3. We compared these options in July in our roundup of S3 alternatives. The cost is real: moving a production object store is measured in terabytes, sometimes petabytes, and the migration window can stretch for months.
- Carry the patches yourself. The letter of the AGPL allows it: the code remains readable. But maintaining a MinIO fork means sustained Go engineering on a project that no longer ships fixes. Unrealistic for a homelab, and rarely cost-effective below a certain volume.
- Keep what runs and delegate maintenance. This is exactly what Docker ELS proposes: a maintained, hardened MinIO image, with CVE tracking that covers the Go dependency graph, transitives included, plus backports that are rebuilt and republished.
The trap would be reading this list as a free-choice menu. The first two options cost time; the third costs money. The real trade-off plays out between those two currencies.
Docker ELS: the bridge, not the destination
Docker ELS (Extended Lifecycle Support) is a subscription service: you request an image, Docker builds and maintains it for up to five years past upstream end-of-life. The model is not limited to MinIO — it covers any end-of-life component you need to keep, and MinIO is only its latest illustration.
Read the offer for what it is: a bridge. It buys time to run the migration properly, without letting CVE exposure grow while the data move progresses. It does not remove the underlying problem — a project whose upstream is frozen — it defers it and makes it auditable.
The risk is confusing the bridge with the destination. An ELS subscription that renews year after year turns technical debt into a permanent rent on a frozen component. The right reading is one rule: every renewal should come with a measurable migration milestone toward a maintained target — an active community fork, a replacement, or a return to managed S3.
# The official image no longer moves since the archive: check yours
docker images minio/minio --format '{{.Tag}} {{.CreatedSince}}'
docker pull minio/minio:latest # will pull no new layersDetect your exposure before you choose
Before picking an option, measure the actual exposure. Three checks are enough to frame the decision.
- The version. A
minio --versionon every node tells you whether you run a recent release or an old image. Since the archive, no patch will close the gap. - The surface. How many applications point at your instance, and which ones hold sensitive data? A cache bucket migrates in a day; a bucket of legally significant backups migrates in quarters.
- The scanner. Image scanners already flag CVEs in MinIO and its Go tree. The count only grows: with no upstream patch, every new finding becomes a permanent signal.
That snapshot sets the timeline. A homelab holding a few gigabytes can migrate to Garage this weekend. A fleet serving petabytes to business applications has no such luxury: that is where the ELS bridge becomes a rational purchase of time, not a comfort reflex.
A quick comparison of replacements on the criterion that matters: Garage is lightweight and multi-node, ideal to start small. SeaweedFS offers a filer and an S3 gateway in one binary. Ceph RGW is heavy but battle-tested, relevant if you already run Ceph. None replicates MinIO one-to-one: the choice depends less on features than on your ability to operate the replacement.
Verdict
If MinIO sits at the heart of your stack — your backups, media, and application buckets — and migration is more than six months away, subscribing to Docker ELS is defensible: you stop the patch bleed and keep audits green while the move progresses.
If MinIO is peripheral, or your data volume is small, do not pay for a bridge you do not need: migrate straight to SeaweedFS, Garage, or managed S3, and use the occasion to reassess what that storage was actually supposed to do.
Either way, start with a simple, immediate step: inventory your MinIO instances, record the exact version of each, and check whether the image you pull is already frozen. What you do not know is running in your infrastructure, you can neither patch nor migrate — and that is precisely what an audit will flag first.