In early 2026 the minio/minio repository on GitHub was archived. Not deprecated with a roadmap, not "we will revisit it later." Archived: read-only, no new commits, no accepted pull requests. If you were running MinIO as your S3-compatible layer, the project that powered your buckets stopped taking contributions the day it went dark.
This post is for the people who now have a minio process in production and a question mark where the upgrade path used to be. I will stick to what changed, what the community fork actually covers, and where the realistic alternatives sit today. I work on storage, so I will mention RustFS where it fits, but I am not going to pretend it is the only answer.
What actually happened to MinIO
The archive did not come out of nowhere. It was the last step in a year-long wind-down of the community edition:
- May 2025: the admin console was stripped from the community build. The GUI most people actually used was moved to the commercial product.
- October 2025: pre-built binaries and Docker images for the community edition were discontinued. "Build from source" became the official answer.
- December 2025: the repository entered maintenance mode. No new features, no PR reviews, security fixes "evaluated case by case."
- February 2026: the README was marked "no longer maintained."
- April 25, 2026: the repository was archived on GitHub and set to read-only. (It was briefly reopened and re-archived; April 25 is the date that appears final.)
The license did not change. The community source is still AGPLv3. What changed is that the code is frozen. The Docker Hub images were later pulled (September 2026), so even standing up the last community release now means building from source or finding a mirror.
MinIO, Inc. still exists. Its active product is AIStor, a commercial object store. The free tier of AIStor is single-node only: no clustering, no HA. Multi-node needs a quoted enterprise agreement.
What "archived" means for you
If you already run MinIO, nothing breaks tomorrow. The binary you have keeps working. The real costs show up over time:
- No security patches. Every new CVE in the community codebase is fixed only in AIStor or in community forks. For teams under SOC 2, ISO 27001, or similar audits, "security fixes evaluated case by case" is a finding, not a policy.
- No new S3 features. AWS keeps extending the S3 API. A frozen server drifts further from what current SDKs expect.
- No multi-node future on the free path. If you run a distributed MinIO cluster, the only vendor-supported successor is paid AIStor. The free tier is single-node by license.
None of this is a reason to panic-migrate tonight. It is a reason to have a plan before your next renewal, audit, or CVE.
The community fork: real, but read the fine print
Because the code is AGPLv3, anyone can fork it, and someone did. The pgsty/minio project (sometimes called Silo) restores the admin console, re-enables binary and Docker image distribution, and keeps full S3 API compatibility. Drop-in: swap minio/minio for pgsty/minio in your compose file and the rest stays the same.
That is genuinely useful. But be honest about what a one-maintainer fork can and cannot promise:
- It inherits the entire frozen codebase. The fork restores distribution and the console, it does not magically add a security team.
- Sustainability is unproven. No community MinIO fork has yet gained the contributor base that OpenTofu (from Terraform) or Valkey (from Redis) found under Linux Foundation backing.
- For a single-node lab or CI bucket, a fork is a fine stopgap. For production data at scale, "one person with AI coding tools" is a risk you should name out loud, not assume away.
Where the alternatives sit in 2026
Here is the landscape as it stands, focused on S3-compatible, self-hostable options.
| Option | License | Maintenance | Notes |
|---|---|---|---|
| MinIO community (archived) | AGPLv3 | Frozen, read-only | Works, but no patches or features |
| AIStor (MinIO Inc.) | Proprietary (Free = single-node) | Active, commercial | Only vendor path for multi-node |
| RustFS | Apache 2.0 | Active, young | Rust-built, S3-compatible, MinIO-shaped toolchain, migration path |
| SeaweedFS | Apache 2.0 | Active, mature | High I/O, broad storage features, more to operate |
| Garage | AGPLv3 | Active | Rust, lightweight, built for geo-distributed modest hardware |
| Ceph (RadosGW) | LGPL 2.1 | Active, foundation-governed | Production-grade at scale, heavier to deploy |
No single row is "the winner." The right move depends on what you are running today and what you can operate.
RustFS, specifically
I will give it the same honest treatment I gave the fork. RustFS is a from-scratch, Rust-built, Apache 2.0 object store that speaks the S3 API. The reason it comes up in MinIO-migration conversations is practical, not marketing: the toolchain is MinIO-shaped. The mc client, aws CLI, and SDK calls you already use against MinIO work against RustFS by changing one endpoint. Migration is a configured move, not a rewrite.
What I would weigh before reaching for it:
- Apache 2.0, not AGPL. If the AGPL obligation was what nudged you to look away from MinIO, RustFS removes that specific concern for embedding or modified network services.
- Young project. This is the part to respect. RustFS is newer than the others in that table. For a production lakehouse, S3 Tables (the Iceberg REST catalog) is still Preview. There is no FUSE or POSIX mount, by design. If you need a filesystem layer or HDFS today, this is not your tool yet.
- Good fit for the S3-shaped workload. CI artifact stores, dataset buckets, self-hosted backends that already talk S3: those are exactly where RustFS is comfortable, and where the migration story is cleanest.
I am not claiming RustFS replaces MinIO for everyone. I am saying: if your workload is S3-shaped and you want a permissively licensed, actively maintained server with a familiar toolchain, it is worth a benchmark on your own hardware before your next MinIO decision.
How I would decide
- Single-node lab / CI / backup: a community fork is fine short term. Evaluate RustFS if you want an actively maintained Apache 2.0 path without building from source.
- Production multi-node, can pay: AIStor Enterprise or Ceph RadosGW are the defensible commercial/foundation options.
- Production multi-node, want open governance: Ceph RadosGW is the mature, foundation-governed choice.
- S3-shaped workload, want permissive license + MinIO toolchain: RustFS is the one to pilot.
The point is not to flee MinIO in a panic. The point is that the community edition is now a frozen artifact, and "frozen" is a planning input, not a crisis.
A note on how this was verified
The timeline and license facts come from public write-ups published in 2026 (DevOps Pack's "MinIO Is Archived. What Happens Next?", Hostzero's Ceph-vs-MinIO analysis, and the MinIO knowledge base at ekarisky.com), plus the repository's own license metadata (AGPLv3) and archive state. I did not run a MinIO-to-RustFS migration benchmark for this post; the "pilot it on your hardware" advice is deliberate. Validate any migration on a non-production bucket first.
If you were running MinIO in production when it was archived, what was the deciding factor for where you landed: license, support, or just "the thing I already have keeps working"?
Top comments (0)