MinIO archived — the open-source storage shakeout and what to use instead

On April 25, 2026, MinIO archived its main GitHub repository — the canonical open-source S3-compatible object storage server that powered countless homelabs, internal data lakes, and self-hosted backup pipelines. The r/selfhosted thread (590 upvotes) captures the community read: this wasn’t a surprise — MinIO has been on the “burning every bridge with the community” trajectory for two years — but the actual archival makes the migration question urgent.

Theo’s April 22 video — “Open source is dead now?” — published three days before the archival, frames the broader pattern this incident exemplifies: the slow-motion conflict between open-source projects, their commercial sponsors, and their downstream users keeps producing the same outcome — and 2026 is where several of those conflicts hit terminal velocity.

What MinIO did

The community-facing history, condensed:

• 2014-2022: MinIO was the canonical “self-hosted S3” — easy to deploy, broadly compatible, Apache 2.0 licensed
• 2023: License relicensing concerns; MinIO Inc. (the company) emphasized commercial features in newer versions
• 2024-2025: Visible feature pullback from the open source server; commercial enterprise edition diverged
• 2025: Documentation gaps and community contributor friction increased
• April 25, 2026: Main MinIO repo archived

The archival doesn’t mean the software stopped working. It means active development moved to MinIO Inc.’s commercial offerings and the open-source community no longer has a maintained upstream. For existing deployments running pinned versions, nothing immediately breaks. For new deployments, the answer to “should I deploy MinIO?” is now clearly no.

From the r/selfhosted top comments:

“You should absolutely not use minio https://blog.elest.io/rustfs-vs-seaweedfs-vs-garage-which-minio-alternative-should-you-pick/” — 467 upvotes

“So they finally pulled the plug then. MinIO has burned every bridge they had at this point.” — 110 upvotes

“I’ve since moved to Garage” — 79 upvotes

The credible alternatives

Three open-source S3-compatible alternatives have absorbed most of the MinIO mindshare:

1. Garage (garagehq.deuxfleurs.fr). AGPL-licensed, written in Rust, designed for self-hosting on commodity hardware including geographically distributed setups. The Deuxfleurs collective maintains it. Strong fit for homelabs, federated organizations, and small-to-medium deployments. Lacks some enterprise-tier features (deep IAM integration, advanced encryption tiers) that MinIO Inc. monetized.

2. SeaweedFS (github.com/seaweedfs/seaweedfs). Apache 2.0, Go, mature, performance-focused. Designed for very large object stores with billions of small objects. Heavier operational burden than Garage; more flexible for high-scale deployments.

3. RustFS (github.com/rustfs/rustfs). Apache 2.0, Rust, newer and lighter than Garage. Smaller community but actively developed. Good fit for users specifically wanting a MinIO-shaped replacement with minimal feature surface change.

For typical homelab use cases (Restic/Kopia backup targets, media storage, internal pipelines), Garage is the default recommendation in April 2026. For higher-scale deployments, SeaweedFS. For minimal-change MinIO replacement, RustFS.

The bigger pattern

Theo’s “Open source is dead now?” doesn’t argue open source is literally dead. It argues the open-source-as-loss-leader-for-commercial-edition pattern is dead — at least as a sustainable equilibrium. The recurring cycle:

1. Project ships open source, gains adoption
2. Sponsor company forms to monetize
3. Commercial features diverge from open source
4. Community sees the divergence widen
5. Eventually: relicense, fork, archive, or some combination

This happened with Redis (RSAL 2024), Elastic (SSPL), Terraform (BSL), Sentry (FSL), and now MinIO. The specifics vary; the structural pattern doesn’t.

Theo’s framing is useful: the “open source” label has become diluted because the implicit social contract — your code can run my infrastructure, indefinitely, without renegotiation — was never written down. When commercial pressure forces a renegotiation, the user-facing experience is “the project I depended on stopped being available on the terms I started using it on.”

Creator POV vs Reddit dissent

The creator landscape is largely aligned on the structural critique. Theo, Christian Lempa, Fireship, Primeagen — all have published material in 2024-2026 arguing license risk is now a first-class concern when selecting infrastructure. Lempa’s Caddy coverage and broader self-hosted content explicitly favors community-governance models (foundations, federated maintainers) over single-company-sponsored open source.

The Reddit dissent splits in interesting ways:

• “This was inevitable; commercial sponsors need revenue.” Pragmatic defense of the pattern — MinIO Inc. is allowed to monetize; users should have known.
• “AGPL/copyleft licenses prevent this.” Garage’s AGPL choice is a direct response to this pattern; it forces commercial users to release modifications.
• “Use vendor solutions instead.” Counter-position from a different angle — if you’re going to pay for object storage features eventually, paying AWS / Cloudflare R2 / Wasabi is more predictable than running open source that might rug-pull you.

The honest read: selecting open-source infrastructure in 2026 requires a license-and-governance audit, not just a feature comparison. Garage’s federated governance + AGPL is one solid answer. SeaweedFS’s federated maintainer model is another. Anything with a single corporate sponsor controlling the license is a strategic risk for long-deployment infrastructure.

What this means for working engineers

Three concrete actions in April 2026:

1. If you’re running MinIO in production, plan a migration. Not urgent (existing versions still work) but not optional (no security patches forthcoming). Garage migration paths are well-documented; budget a quarter for the transition.

2. If you’re picking object storage for a new project, default to Garage. For homelab and SMB-scale workloads, it’s the lowest-risk choice. Federated maintainers, AGPL license, active development, MinIO-compatible API.

3. Audit your other “open source” dependencies for license risk. MinIO is the most recent example, not the last. Anything with a single-company-controlled license that has substantially diverged commercial features is at risk of the same trajectory.

The honest critique

What this story doesn’t mean:

• It doesn’t mean open source is dying. Lots of healthy projects exist; the foundation-model / federated-maintainer pattern works. The dying thing is “VC-backed company ships open source as user acquisition, then enclosure.”
• It doesn’t mean MinIO is broken. Pinned versions keep working. The archival changes the maintenance trajectory, not the immediate operational state.
• It doesn’t mean cloud object storage is the answer. S3 is cheap until it isn’t (egress fees, request fees, retrieval costs for archival tiers). Self-hosted storage has real cost advantages that survive this incident.

For most working engineers in April 2026: MinIO archived is a useful forcing function to revisit your infrastructure license posture. The alternatives are now mature; the migration paths are documented; the broader pattern is visible enough that the next MinIO-shaped incident shouldn’t catch anyone by surprise.