The minio/minio GitHub repository was archived on April 25, 2026. 60,000 stars. Over a billion Docker pulls. Read-only.

Everyone has already written the obituary. I'm more interested in what actually happens next — because this story isn't over, and how it plays out matters for anyone building self-hosted infrastructure.

How we got here

This didn't happen overnight. MinIO spent about a year systematically dismantling the community edition before finally archiving the repo:

  • 2021 — License switch from Apache 2.0 to AGPL v3. At the time it looked like protection against commercial exploitation. In hindsight it was the first move in a longer game.
  • May 2025 — Admin console gutted from the community edition. The GUI that most people actually used, gone.
  • October 2025 — Pre-compiled binaries and Docker images discontinued. "Build from source" became the official answer. For anyone running CI/CD pipelines or automated deployments, this was where MinIO effectively stopped being usable.
  • December 2025 — Maintenance mode declared. No new features, no PRs, security fixes case-by-case.
  • February 2026 — Repository archived for the first time, then briefly reopened.
  • April 25, 2026 — Archived again. This time it appears final.

The official destination MinIO Inc. wants you at is AIStor, their commercial enterprise product. For most people who were using MinIO, that's not a realistic path.

The community fork: promising but uncertain

The AGPLv3 license — ironically the same license MinIO used as commercial leverage against Nutanix and Weka — guarantees the community's right to fork. Once code is released under AGPL, the license is irrevocable. You can archive a repo, but you can't take the code back.

A developer behind the Pigsty project (an open-source PostgreSQL deployment platform) stepped up and created pgsty/minio — a community fork that restores the admin console, re-enables binary and Docker image distribution, and continues under AGPLv3. The fork maintains full S3 API compatibility and works as a drop-in replacement: swap minio/minio for pgsty/minio in your Docker setup and everything else stays the same.

The work involved was surprisingly minimal — the admin console removal was essentially just a changed dependency version, which was reverted in one commit. That says a lot about how thin the "end of life" decision actually was technically.

But forking is the easy part. The real question is sustainability. Can one maintainer, even with AI coding tools, keep a production-grade storage system secure and compatible long term? The honest answer is: we don't know yet. No community fork of MinIO has gained real traction so far. The Pigsty fork is a solid start, but it needs more contributors to become something you'd trust with production data at scale.

MinIO is not alone

This isn't an isolated incident. It's a pattern:

  • HashiCorp/Terraform — switched from Mozilla Public License to Business Source License in 2023. Community forked it into OpenTofu. OpenTofu is now under the Linux Foundation and actively maintained.
  • Redis — changed to a dual license (RSALv2 + SSPLv1) in 2024. Community forked it into Valkey. Valkey is now a Linux Foundation project with serious backing from AWS, Google, and others.
  • MinIO — archived 2026. Community fork exists but hasn't yet found its footing.

The difference between Terraform→OpenTofu and MinIO so far is foundation backing. OpenTofu and Valkey both landed under major open source foundations quickly, which gave them credibility, infrastructure, and contributor momentum. MinIO's fork is still one person's side project. That might change — or it might not.

The real alternatives

Regardless of what happens with the fork, the broader S3-compatible storage space has matured. These are worth knowing about:

Ceph (RadosGW)

The elephant in the room. Ceph has had S3-compatible object storage via its RADOS Gateway for years. It's a CNCF project, battle-tested at massive scale, used by cloud providers and enterprises globally. It's also complex — Ceph is not something you casually deploy on a single VPS. But if you need serious, production-grade, open-governed object storage that isn't going anywhere, Ceph is the answer. The governance question is settled here.

RustFS

The newest entry, written in Rust, Apache 2.0 licensed. Positions itself explicitly as a MinIO replacement with better performance for small object workloads. Ships a management console out of the box and supports direct migration from MinIO. Worth watching — but it's young, and young storage software needs time to prove itself under real production load.

SeaweedFS

Go-based, Apache 2.0, more mature than RustFS. Built for distributed storage with S3 compatibility alongside blob and file storage. More capable than MinIO was, but also more complex to operate. Good fit if you need scale beyond what a single-node MinIO ever gave you.

Garage

Rust-based, AGPLv3, built specifically for geo-distributed self-hosted setups on modest hardware. Not trying to compete with enterprise storage — it's for people who want simple, reliable object storage across multiple physical locations. Different use case than most MinIO deployments but worth knowing exists.

So what actually happens next?

A few scenarios are possible:

The pgsty fork gains traction. More developers join, it gets proper CI/CD, regular security updates, and eventually a foundation home. This is the OpenTofu path. Possible, but it needs community energy that hasn't materialized yet.

RustFS takes the crown. It's the most aggressively positioned as a MinIO replacement and has momentum. If it matures fast enough and the community consolidates around it, it could become the default answer to "I need self-hosted S3" within a year or two.

Ceph wins by default. Not because anyone chose it, but because it's the only option with serious governance and a multi-decade track record. Teams that can't afford to bet on young projects will end up here.

Fragmentation. The most likely short-term outcome. Different teams pick different solutions, no clear successor emerges, and the "MinIO-shaped hole" in the ecosystem stays open for a while.

My take: the MinIO fork keeps existing deployments alive for teams that need time to migrate. For new infrastructure, I wouldn't start a MinIO deployment today — either use Ceph if you need something proven, or watch RustFS closely over the next 6-12 months. The ecosystem will sort itself out, it just needs a bit more time.