Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Introduction — How a "Default Choice" Went Read-Only
The Timeline — What the Repository Recorded About Itself
What Changed, and What Didn't
Where the Alternatives Actually Stand — As of July 2026
So If You're Running MinIO Right Now
Closing
References

Introduction — How a "Default Choice" Went Read-Only

This blog's May 2026 distributed storage roundup called MinIO "the de facto reference implementation of the S3 protocol." That was back when the default move for on-prem S3-compatible storage was simply to install MinIO and go. Two months after that post, the minio/minio repository is archived — read-only. The GitHub banner says exactly what it says: "archived by the owner on Apr 25, 2026," and three days before this writing, on July 14, 2026, the mc client repository was archived too.

This event has drawn as many angry threads as it has inaccurate summaries. Claims like "they changed the license" (they didn't) or "they took the code private" (it's archived but still public) circulate freely. So this post follows the record, not the sentiment — every claim here is backed by the repository's own commits, release notes, registry metadata, and the official blog, and community reactions are linked only as reactions. The back half covers the actual state of the real alternatives — Garage, SeaweedFS, and Ceph RGW — as of July 2026, and what your options are if you're running MinIO right now.

The Timeline — What the Repository Recorded About Itself

Date	What happened	Primary source
2025-05-24	Embedded console cut down, LDAP/OIDC login removed	Release notes
2025-09-07	Last Docker Hub image update	Registry tag history
2025-10-15	Last release + "source-code-only distribution" announcement	Release, Commit 9e49d5e7a6
2025-10-16	High-severity CVE-2025-62506 disclosed (fix shipped only in the release above)	GHSA-jjjj-jwhf-8rgr
2025-12-03	README declares "maintenance mode"	Commit 27742d4694
2026-01-06	README replaced with AIStor Free/Enterprise guidance	Commit be7800c813
2026-02-12	"THIS REPOSITORY IS NO LONGER MAINTAINED."	Commit 7aac2a2c5b
2026-03-20	minio/operator archived	Repository banner
2026-04-25	minio/minio archived	Repository banner
2026-07-14	minio/mc archived	Repository banner

Let's go through these one at a time.

May 2025 — Management Features Leave the Console

The RELEASE.2025-05-24T17-08-30Z release notes state that the embedded UI console is deprecated and moving to the object-browser repository, and on removing LDAP/OIDC external IdP login they wrote — "these are now available as part of the AiStor Product." In other words, the community binary's web UI shrank from a management console to a plain object browser, and the release notes themselves said where the removed features went: the commercial product. The same notes recommend paying customers upgrade to AiStor.

The reaction was predictable — the HN thread from that time (176 points), and a console UI fork, OpenMaxIO, created the very next day, May 25, which picked up roughly 1,900 stars. But that fork's last push was June 24, 2025 (per the GitHub API, checked 2026-07-17). It's been stalled for over a year with no releases. That's data showing that announcing a fork and maintaining one are different things. One more note: the minio/object-browser repository the release notes pointed to as the console's new home returns a 404 as of today — it's gone from the list of public repositories.

September–October 2025 — Images Stop, the Last Release Lands

By registry metadata, minio/minio on Docker Hub last updated on September 7, 2025 (tag RELEASE.2025-09-07T16-13-09Z). The latest tag has been frozen since that day too. For scale: this image's cumulative pull count is roughly 1.8 billion, per the Docker Hub API — which gives some sense of the size of the distribution channel that just stopped. The HN thread (733 points) captures the reaction at the time.

RELEASE.2025-10-15T17-29-55Z, dated October 15, 2025, became this repository's last release. That same day, README commit 9e49d5e7a6 declared that the community edition was now "distributed as source code only," and stated flatly of the existing binaries: "These legacy binaries will not receive updates." The installation instructions the final release notes give are themselves a summary of the new distribution model.

# The install method given by the RELEASE.2025-10-15T17-29-55Z release notes
go install -v github.com/minio/minio@RELEASE.2025-10-15T17-29-55Z

# Containers are now built yourself
git clone https://github.com/minio/minio
cd minio && git checkout RELEASE.2025-10-15T17-29-55Z
TAG=myregistry.com/minio/minio:RELEASE.2025-10-15T17-29-55Z make docker

CVE-2025-62506 — Where Ending Distribution Actually Hurts

This last release wasn't just a wrap-up release. It contains the fix for CVE-2025-62506, disclosed as GHSA-jjjj-jwhf-8rgr — privilege escalation via a session-policy bypass in service accounts and STS, severity high. Per the advisory, everything before the 2025-10-15 fix commit is in the vulnerable range.

This is where the practical meaning of ending distribution becomes exact.

The official Docker Hub image stopped five weeks earlier (September 7), so no official public image containing this fix exists. quay.io has no tag for this release either (the tag lookup comes back empty).
quay.io did keep getting occasional hotfix tags for older releases through as late as April 2026. But, for instance, the hotfix tag pushed on 2026-04-01 references commit 7aa24e772, which doesn't exist in the public repository (the GitHub API can't find that SHA). That means it's an image built outside the public tree, and the community has no way to check its contents against source.
So, for a user who was pulling images, the only official path to patch this high-severity vulnerability was "build from source yourself."

"They stopped shipping binaries" sounds abstract. "The fix for a disclosed privilege-escalation vulnerability never reaches you as an image" does not. This is the concrete case that made October's shift tangible.

December 2025 – July 2026 — From Maintenance Mode to the Archive Chain

On December 3, a README commit declared the project to be in maintenance mode — no new features, no improvements, no PRs accepted, with only critical security fixes possibly reviewed case by case (HN, 511 points). On January 6, a commit replaced that space with AIStor Free and AIStor Enterprise guidance, and on February 12, a commit condensed the banner into one sentence — "THIS REPOSITORY IS NO LONGER MAINTAINED." (HN, 500 points)

Then the archiving followed. The Kubernetes operator, minio/operator, on March 20, 2026; the server itself, minio/minio, on April 25; the CLI, minio/mc, on July 14. By contrast, the SDK repositories — minio-go, minio-py, minio-js — are still actively updated as of this writing (minio-js pushed as recently as yesterday). AIStor customers need S3 client SDKs too, so the archive pattern itself traces out exactly where the product boundary sits.

What Changed, and What Didn't

Remembering this as a "license rug pull" is inaccurate. Here's what the record actually shows.

What didn't change — the license. minio/minio was AGPLv3 from start to finish. The repository metadata, README, and LICENSE file are all unchanged. There was no switch to BSL or SSPL. The archived code is still there for anyone to take under AGPLv3 today.

What changed — four things, in order. (1) Features: the management console and external IdP login left the community binary (2025-05). (2) Distribution: official binaries and container images stopped (2025-09 to 10). (3) Maintenance: PRs and issues stopped being accepted (2025-12). (4) The repository itself: it went read-only (2026-03 to 07, the archive chain).

What's offered as the replacement — AIStor Free. Per MinIO's subscription-tier announcement, AIStor Free is single-node only, has no capacity cap on that one node, and is free but under a license that restricts redistribution and resale (a free license key is required to download, per the archived README's instructions). Multi-node distributed setups start at Enterprise Lite, and per the announcement, crossing 400 TiB auto-converts you to Enterprise. In short, AIStor Free is a "free, proprietary, single-node product." It isn't a successor to open-source MinIO — it's a different thing, and should be judged as one.

What didn't happen — a successful server fork. When HashiCorp Vault switched licenses, OpenBao branched off under a foundation and has sustained itself. No such fork has appeared for MinIO as of this writing. The console UI fork, OpenMaxIO, stalled as shown above, and no fork that picked up the server itself and gained traction has been confirmed. Community commentary (e.g., MinIO Is Dead, Long Live MinIO) mostly recommends migrating to an alternative rather than forking. That no party stepped up to carry a large Go codebase without a foundation, under a single-vendor AGPL CLA structure — that's one of the quiet lessons of this episode.

Where the Alternatives Actually Stand — As of July 2026

The S3 API being the de facto portability layer is exactly what shines in a moment like this. Most application code just needs its endpoint and credentials swapped. The catch is that all three server-side operational profiles differ quite a bit from MinIO's.

Garage — Still the Lightest Slot, and Now Courting Migrants

Garage is a lightweight, geo-distributed S3 storage system in Rust from France's Deuxfleurs, licensed AGPLv3 (confirmed in the repo's LICENSE file). Looking at the release history (their own Gitea instance): v2.0.0 landed 2025-06-14 — a full overhaul of the admin API (v2 endpoints), a breaking change that split replication_mode into replication_factor and consistency_mode — then v2.2.0 and the maintained v1 line's v1.3.1 shipped side by side on 2026-01-24, and the latest, v2.3.0, is from 2026-04-16.

v2.3.0's direction is telling. It added a garage server --single-node option to spin up a single-node cluster instantly, plus environment-variable bootstrapping for a default access key and bucket, and — in the release notes' own words — relaxed the requirements for imported access keys specifically to ease switching over from other S3 storage providers. It's a change aimed squarely at the users who used to start with "one minio server in an empty folder."

The limits are also spelled out in the design docs. The official goals document states it does not do erasure coding, only duplication — meaning triple replication means 3x storage overhead. Not adding features beyond the S3 API is an explicit non-goal too. The project's scale matters here as well — per its own site's funding page, 2025 funding was on the order of 1.5 FTE backed by NLnet/NGI0. It's a great fit for homelabs, small organizations, and small-scale geo-distribution, and a poor fit by design for dense, high-capacity single-DC storage.

SeaweedFS — the Most Active, and the Most Dependent on One Person

SeaweedFS is Apache-2.0 licensed (roughly 33,000 stars), and has the fastest release cadence of the three — 4.00 shipped 2025-11-03, then continued weekly, with the latest as of this writing at 4.39 (2026-07-10). The 4.00 release notes alone list a string of S3-surface improvements, including S3 IAM config file support.

The architecture isn't a single MinIO-style binary. Per the README, the core is a blob store where a central master handles only volume placement while metadata is distributed across volume servers; on top of that sits a separate stateless server, Filer, which adds directories and POSIX attributes; and the S3 API is a gateway on top of that. Erasure coding is implemented too (stated in the README). So it has real strength for high-volume small-file workloads, at the cost of more kinds of daemons for an operator to understand than MinIO has.

The risk worth being honest about is concentration. Per the GitHub contributors API, founder chrislusf's commit count is 9,968 — an order of magnitude apart from the second place among non-bot contributors, at 530. That doesn't mean the project is dying — it's currently the most active of the three — it means the bus-factor concern is legitimate. Something worth weighing if you're moving off MinIO specifically because you've felt single-vendor risk before.

Ceph RGW — Heavy, But a Different Governance Story

Ceph's RADOS Gateway (RGW) is among the longest-proven of the S3-compatible storage options. The current stable release is Tentacle (v20.2.0, GA 2025-11-18), which has reached 20.2.2 as of this writing, with Squid (19.2.5) and Reef (18.2.8) supported in parallel. The Tentacle announcement lists, among its dashboard improvements, RGW multisite automation, tiering, lifecycle, notifications, and fine-grained replication — a sign that the operational side of RGW keeps getting polished.

The tradeoff is exactly the well-known one. Even if all you need is RGW, the whole Ceph cluster (mon, mgr, OSD) comes along with it. cephadm has lowered the installation burden a lot, but it's still a tool for "an organization with a storage team," not a homelab tool. In exchange, it has an advantage that maps directly onto what just happened here — Ceph is a multi-vendor project governed by the Ceph Foundation under the Linux Foundation, which structurally lowers the risk of distribution stopping because one company pivoted its business.

Also Worth Noting

There are newer entrants too, like RustFS, which is rewriting S3 storage in Rust (Apache-2.0, roughly 30,000 stars, a same-day push confirmed as of 2026-07-17). But data durability is a property proven by time, not by star count — verify the track record yourself before moving production data onto anything.

So If You're Running MinIO Right Now

You have four options. All four have a cost, and so does "doing nothing."

Ride out the frozen binary. This means deciding to run software that hasn't been patched since 2025-10-15. As CVE-2025-62506 showed, the fix for the next vulnerability won't reach you as an image. Justifiable only in a fully isolated environment with no external exposure, and only with an expiration date set.
Maintain your own source build. Since the archived repository doesn't accept PRs, this path is, in effect, a private fork of your own. You take on the Go toolchain and build pipeline, and the judgment calls on backporting fixes for future vulnerabilities, yourself.
Move to AIStor Free. If a single node is enough and a proprietary license key is acceptable in your environment, this is honestly the lowest-friction path. The moment you need distributed HA, you're in paid territory (Enterprise Lite, with the 400 TiB boundary).
Migrate. On the application side, S3 compatibility usually means it's just an endpoint swap, but moving the data itself and translating IAM policies and lifecycle rules is separate work (mc is archived too, so a neutral tool like rclone is the safer bet for the data move). The default mapping is as covered above — Garage for homelab, small-scale, geo-distributed; SeaweedFS if you have heavy small-file volume and can tolerate a fast release cadence; Ceph RGW when organizational scale and long-term governance matter most.

If your Kubernetes deployment was sitting on top of minio/operator, plan for that axis too — the operator repository was archived on March 20, 2026.

One generalization to close on. The lesson here isn't "MinIO was bad" — it's a reconfirmation of an old fact: for open-source infrastructure where a single vendor holds the CLA, that vendor's business pivot is the project's fate. In a layer like storage, where data physically settles in, that risk translates directly into migration cost. When you pick your next dependency, look at the governance structure alongside the feature table — is it foundation-owned, are contributors distributed, is it actually at a scale where a fork is realistic.

Closing

To sum up only what the record confirms. MinIO Community Edition ended in this order: feature reduction in May 2025, distribution stopping in September–October (last image September 7, last release October 15), maintenance mode in December, and the repository archive chain from March through July 2026. The license stayed AGPLv3 to the end, and the transition cost was pushed onto users in the concrete form of a high-severity CVE's fix never reaching an official public image. The official successor, AIStor Free, is free but a single-node-only proprietary product.

The alternatives differ in maturity and character. Garage offers small-scale, geo-distributed fit through a small, clear design (replication-only, nothing beyond S3); SeaweedFS offers fast development velocity and small-file strength (at the cost of founder concentration); Ceph RGW offers foundation governance and proven longevity, at the price of operational weight. None of them is a full successor. That's the honest conclusion of this rundown — so the choice is decided not by a benchmark, but by your scale, your team, and your risk tolerance.