MinIO Alternatives: What to Run Now That the Repository Is Archived

The most useful summary of this situation is a thread title on the Proxmox forum: "MinIO is dead... What's next?" On Reddit the same week, someone opened with "MinIO CE is on life support" and asked which of three replacements to pick. Both threads rank on the first page for this search as of writing, which tells you something about how much settled guidance exists.

So start with the part that is not a rumour. Open the repository and GitHub shows a banner above the code.

The README opens with a line in capitals:

THIS REPOSITORY IS NO LONGER MAINTAINED.

That is the whole premise. This is not another licence-change post. The licence argument happened, and then the project stopped. What follows is what the four credible replacements are actually like to run, what each one costs you once you count past the download, and the question almost nobody on this search result page asks: whether you should be operating object storage yourself in the first place. If you want the mechanics of the S3 API itself before any of that, that is a separate piece.

What happened, and what "maintenance mode" turned into

The sequence is short. In December 2025 the company behind the project announced it was in maintenance mode and would not accept new changes. On 25 April 2026, by the timestamp GitHub prints, the repository was archived. LWN, reviewing the fallout in June, dates the archiving to February. The discrepancy probably comes from separate repositories being closed at different times, so the banner is the safer thing to quote.

The code did not vanish. It is AGPLv3, it still builds, and nothing stops you running the last release for years. What ended is the part you were relying on without pricing it: someone else fixing the bugs, someone else shipping the security patches, someone else deciding what the S3 compatibility surface does next. An archived repository is a dependency with a maintainer of exactly zero.

AIStor Free is not the open-source version

The archived README points readers at two products: AIStor Free and AIStor Enterprise. It is worth being precise about what that offer is, because the naming invites a misreading. AIStor Free is a no-cost tier of a proprietary product. It is not a community edition, and it is not the thing you had before under a different name.

If you were running MinIO because it was free, that path stays open. If you were running it because the source was yours to read, patch and keep, moving to AIStor Free hands you the same exposure you were trying to avoid: a vendor deciding, on their schedule, what the free tier is allowed to do. The search traffic suggests people worked this out on their own: interest in AIStor is climbing, and so is interest in forks and alternatives, at the same time.

The question the search results skip: should you run object storage at all?

Look at who is answering this question. A thread in r/selfhosted. A homelab YouTube channel. XDA. The Proxmox forum. These are excellent sources and they share an assumption that is invisible until you name it: that running the storage yourself is a given, and the only open question is which binary.

For a homelab that assumption is correct. The hardware is already bought and running it is the point. For a team that installed MinIO three years ago as an S3-compatible backend for user uploads, it usually is not. That team did not want a distributed storage cluster. They wanted a bucket with an S3 API so the SDK they had already written against would work, and MinIO was the cheapest way to get one.

If that is your situation, the honest answer is that you may not need a replacement binary at all. You need a bucket. Point the same client at a managed S3-compatible endpoint, change two config values, and the migration is done. The comparison of managed providers on price and egress is the branch to follow from there. The rest of this article is the other branch: you have a real reason to hold the data on your own disks, and you need to know what you are signing up for.

MinIO alternatives: the open source options that are still maintained

Four projects come up repeatedly, and they are not interchangeable. Garage is built for small deployments spread across locations. SeaweedFS is built for enormous numbers of small objects. RustFS is the closest thing to a drop-in and the least finished. Ceph is the one that answers questions larger than object storage. Pick by which sentence describes you, not by which benchmark looks best.

Garage: the small one, and it knows it

Garage, the S3 implementation hosted by the Deuxfleurs association in France, is the option that keeps coming up in European self-hosting circles, and the one that has been most explicit about what it is for. It is written in Rust, it has been going since 2020, and it ships what the project calls "a single dependency-free binary that runs on all Linux distributions".

The design target is unusual and worth understanding, because it explains both the appeal and the limits. Garage is built to "run over the Internet across multiple datacenters", not across a fast local network in one rack. It uses conflict-free replicated data types so that nodes on flaky links converge without a coordinator, runs one daemon per host, and asks very little of the hardware. If you have three modest machines in three different places, this is the design that fits.

The cost of that focus is API surface. In LWN's review, Garage's S3 support is narrower than Ceph's: no object versioning, and Signature Version 4 only. Neither is exotic. Plenty of applications never touch versioning, and every current SDK signs with SigV4. But both are the kind of thing you discover on a Friday rather than during evaluation. Check your application against the compatibility list before you commit, not after.

• Good fit: multi-site or geographically split storage, modest hardware, small operations team.
• Bad fit: you rely on object versioning, or on the long tail of S3 features a backup vendor might use.
• Licence: AGPL, as of writing.

SeaweedFS: the one built for a very large number of small files

SeaweedFS is the oldest and busiest project in this set. It is written in Go, and its architecture comes from a different lineage than the rest. It follows the approach Facebook described for its photo storage, keeping file metadata in memory so that reading an object costs a single disk seek regardless of how many objects exist.

That is a real answer to a real problem. Storage systems that treat every object as a file on a filesystem degrade badly at tens of millions of small objects, and this one does not. S3 arrives as a gateway on top of that core rather than as the native interface, which is the thing to understand before choosing it: SeaweedFS is a distributed storage system that speaks S3, not an S3 server that happens to be distributed.

Practically, this makes it the least drop-in of the four. The concepts you learn are SeaweedFS concepts: volumes, masters, filers. They do not map onto what you knew about MinIO. Budget for that. In exchange you get the project in this list with the longest operational track record at scale.

RustFS: the closest thing to a drop-in, and the least finished

RustFS is the project the AI summaries and the forum threads keep putting first, and it is easy to see why. Its repository tagline is a benchmark claim, "2.3x faster than MinIO for 4KB object payloads". It is Apache 2.0 licensed, it ships a management console, and it is openly positioned as the replacement people are looking for.

Take the benchmark line as what it is: a project's claim about itself, on a payload size it chose. It may well hold. It has not been independently reproduced in anything ranking on this search as of writing.

Which is better, MinIO or RustFS?

For a new deployment, RustFS, because MinIO is archived and RustFS is not. That is nearly the whole comparison and it has little to do with throughput.

The caveat matters more than the answer. RustFS is young, and the community consensus in the threads Google is currently surfacing is that it is not yet recommended for large-scale production use. Distributed operation in particular is described as still maturing. Google's own summary of this search repeats that warning while listing the project first, which is an unusually honest thing for a generated answer to do. Single-node, non-critical, or a staging environment: reasonable today. The bucket holding your customers' uploads: not yet, unless you are prepared to be the one who finds the bugs.

Ceph: the answer when the question is bigger than object storage

Ceph is the mature end of this list. It is stewarded by the Ceph Foundation under the Linux Foundation, it has been in production at serious scale for over a decade, and its RADOS Gateway is the most complete S3 implementation here: bucket lifecycle rules, encryption, the features a backup product expects to find.

It is also the one where the phrase "just replace MinIO with it" does the most damage. Ceph is several coordinated daemon types (ceph-osd, ceph-mon, ceph-mgr and more) with their own hardware expectations and their own failure modes. Ubuntu's MicroCeph and similar packagings genuinely reduce the setup burden, and they do not reduce the operational one. You are running a storage cluster now.

The case for it is honest and narrow: if you also need block devices and a POSIX filesystem, or you are storing enough that a dedicated storage function already exists, Ceph is the only option here that answers all of those at once. If you needed a bucket, this is the most expensive way to get one.

The table nobody prints: what each one costs to run

Every comparison of these projects compares the software. The software is free in all four cases, which is exactly why comparing it settles nothing. Here is the part that decides the bill.

Read that last row properly. Any of these run on one machine, and none of them should. A single node means a single disk controller, a single kernel, and a restore from backup as your recovery plan. Redundancy means at least three nodes, which means three sets of disks, replication traffic between them, and a person who knows what to do when one of them stops answering at two in the morning.

Price that in euros at European hardware rates and the shape becomes obvious. Three servers with real disks cost more per month than most teams' entire object storage bill was, before adding the engineer time to build the cluster, the periodic restore test that proves the backups work, and the on-call rotation that makes the redundancy mean anything. The licence was never the expensive part. Bandwidth is worth checking too, since self-hosting changes where the egress arithmetic lands rather than removing it.

MinIO alternative for local development

This deserves its own answer, because it is a common reason MinIO was installed and the requirements are nothing like production. A development S3 endpoint needs to start fast, hold nothing valuable, and go away cleanly.

Nothing here has to be production-grade for that. Garage's single static binary is well suited to it, RustFS's alpha status stops mattering when the data is disposable, and lighter S3 mocks exist that are not object storage at all. The one thing worth keeping consistent between your laptop and production is the signing behaviour and path style, since that is what breaks first when the endpoint changes. If you have already written presigned URL flows, verify those against whichever local server you pick — they are the part most likely to differ.

What self-hosting does to your GDPR position

This is missing from every result on the page as of writing, in a discussion about where user files live, and it changes the decision for a lot of European teams.

Self-hosting does not remove the obligations that come with holding personal data. It moves them onto you. Run your own object storage and you are the one answering for where the disks physically sit, for the security of the store, for breach notification when something goes wrong, and for the records of processing. There is no processor between you and the regulator, because you are it. Teams often reach for self-hosting specifically for compliance reasons and end up with more obligations than they started with, not fewer.

That is not an argument against it. It is an argument for counting it. If the reason you want the data on your own hardware is data residency, a managed provider operating inside the EU already gives you that, with a processor agreement and someone else's name on the security of the store. If the reason is that you do not want the data under a foreign legal regime, that is a question about the operator, not the hardware, and it is the column none of these comparisons contains.

How Runsite handles it

Runsite provides managed S3-compatible object storage on European infrastructure, with servers in Germany as of writing. The API is the one your code already targets, so migrating off MinIO is an endpoint and a set of credentials rather than a project.

The part that is relevant to this article is the last row of the table. There is no quorum for you to size, no replication to watch, and no page at two in the morning when a node stops answering. The operator of the store is a European company, which means the processor obligations stay with the provider instead of moving onto your team along with the binary. Implementation details (SDK configuration, endpoints, credentials) are in the Runsite docs.

Short version

The archive banner is real and the project is not coming back, so a decision has to be made either way. Just make sure it is the decision in front of you. Most of the internet is answering "which binary replaces MinIO" when the question worth asking first is whether the binary was ever the thing you wanted.