MinIO vs Garage vs SeaweedFS: self-hosted S3 after the archive, measured (2026)

Quick answer (2026)

If you want the least operational surface and your data fits on a few nodes, run Garage. One Rust binary, no external database, AGPL-3.0, and it was built specifically for cheap machines on unreliable links. Accept in exchange that its real home is not GitHub, which has consequences we measured below.

If you need one system to serve object storage and a filesystem, and you are comfortable running several component types, run SeaweedFS. Apache-2.0, and by a wide margin the fastest moving project of the three. That speed is the reason to pick it and also the thing you have to manage.

If you are currently running MinIO, you are running software whose repository is now archived and read only. You do not have to panic, and the reason you do not have to panic is the single most useful thing we found this week.

Six things we measured on August 24, 2026 that the first page of Google does not say.

The MinIO repository is archived, and it says so in the first line of its own README. Not "quiet". Not "slowing down". The GitHub API reports archived: true, and the README opens with a note in capital letters saying the repository is no longer maintained, offering AIStor Free and AIStor Enterprise as the alternatives. The last tagged release is RELEASE.2025-10-15T17-29-55Z, from October 2025. The licence on the source that remains is still AGPL-3.0, so the code is still there and still forkable. What ended is the product, not the licence.

There are no more community binaries, and the Docker tag that still works is the trap. The README states plainly that the community edition is now distributed as source code only, and that pre-compiled binary releases will no longer be provided for it. Here is the part that matters operationally, because nobody writes it down: minio/minio:latest on Docker Hub still pulls successfully. It last updated on September 7, 2025. So a docker compose up written today against minio/minio:latest does not fail, does not warn, and quietly hands you a build that is approaching twelve months old. A pipeline that fails loudly is a much smaller problem than one that succeeds with a stale artifact, and this one succeeds.

The client libraries are alive, and this is why a migration is smaller than it looks. Every write-up on page one frames this as MinIO dying. The measured picture is more precise and considerably more useful. The MinIO server was retired. The MinIO client SDKs were not. The minio package on npm is Apache-2.0, published version 8.0.7 on February 27, 2026, and is pulling roughly 883,000 downloads a week. Its repository was last pushed on August 11, 2026. The Go, Python, C++ and Rust SDKs in the same organisation were all pushed within three days of this article.

That distinction is the whole migration story. The thing that went away is a server that speaks the S3 API. Garage and SeaweedFS are also servers that speak the S3 API. Your Next.js route handler that signs a PUT, your upload helper, your bucket policy code: none of it is MinIO specific, because it was talking S3 the entire time. You are changing an endpoint and a set of credentials, not rewriting an integration. Budget your migration for data movement and for the S3 features you actually use, not for application code.

SeaweedFS ships faster than most teams can consume. It published 36 releases in 2026 alone, and at the time of writing the two most recent are 4.44 on August 22 and 4.43 on August 21. One day apart. The repository had commits pushed on the morning this was written.

Read that in both directions, because it is genuinely double edged. On the good side, this is the healthiest release pulse of the three by a wide margin, bugs get fixed quickly, and the project description now advertises Iceberg table support alongside object storage and filesystems, which is a real scope expansion rather than a maintenance dribble. On the cautious side, a storage system is the last place you want to be tracking a moving tag. If you run SeaweedFS, pin an explicit version, read the notes between releases, and upgrade deliberately. "Deploy latest and forget" is a reasonable posture for a status page. It is a poor one for the system holding your objects.

You cannot judge Garage by its GitHub stars, and almost everyone does. Garage's canonical repository is not on GitHub at all. It lives on the Deuxfleurs collective's own Forgejo instance at git.deuxfleurs.fr, which reports 169 stars and 192 forks. There is a GitHub repository, it is clearly labelled a mirror, and it shows 4,401 stars with issues disabled.

So when a comparison article puts Garage's 4,401 next to SeaweedFS's 34,240 and draws a conclusion about adoption, it is comparing a mirror against a primary. The mirror cannot collect issues, cannot collect pull requests, and collects only the stars of people who happened to find it. The real discussion, the bug reports and the contribution history are on infrastructure that no GitHub based popularity metric can see. We are not claiming Garage is secretly more popular than SeaweedFS. We are claiming that the number people quote is not measuring what they think it measures, and that if you are evaluating Garage you should go and read the actual forge.

Garage maintains two release lines in parallel, so "latest" is a decision. This one is invisible unless you list the tags in order. Garage released v1.3.0 on September 14, 2025 and v2.1.0 on September 15, 2025, one day apart. It then released v1.3.1 and v2.2.0 on the same day, January 24, 2026. The most recent v2 release is v2.3.0, from April 16, 2026, and the repository was updated the day before this article.

That is not a project that lost track of its branches. That is deliberate long term maintenance of a v1 line alongside v2 development, which is unusually disciplined for a small collective and is a meaningful signal if you are worried about being forced through a major upgrade on someone else's schedule. It also means you have to choose a line on purpose rather than reaching for whatever the download page shows first.

The one on page one that we deliberately left out

Search for MinIO alternatives today and much of the first page will hand you RustFS, frequently described as the MinIO successor. We looked, because a three way comparison that ignores the tool everyone is recommending would be avoiding the question.

RustFS is Apache-2.0, has 31,352 stars, and was pushed the same day this was written, so it is not vapour and the enthusiasm is not baseless. It is also, as of August 21, 2026, at version 1.0.0-rc.3, which is a release candidate. Its recent tags are 1.0.0-rc.2, 1.0.0-rc.2-preview.1 and 1.0.0-rc.3, all marked prerelease. There is no stable 1.0.

We are not saying avoid it. We are saying that "successor to the thing you were running in production" and "has not cut a stable release yet" are two facts that belong in the same sentence, and on page one they usually are not. If you are replacing a storage system because its vendor retired it, replacing it with a release candidate is a specific risk that you should take on purpose, with a rollback plan, rather than because a listicle sounded confident. Revisit when 1.0 ships.

What we did not measure, and why we are saying so

We did not benchmark throughput, small file ingest, or latency, and we are not going to quote anyone else's numbers as if they were ours.

This matters because performance is where the existing coverage is loudest and least verifiable. There are widely shared figures claiming SeaweedFS and Garage are several times faster than MinIO on small files, sourced from forum threads with unpublished methodology, unstated hardware, unstated object sizes and unstated durability settings. Those numbers may well be directionally right. They are not something we can stand behind, and a storage benchmark without a published harness is close to meaningless, because erasure coding versus replication alone changes the write path enough to invert a result.

What we can tell you is that the three make genuinely different architectural bets, and the bets predict the shape of the performance far better than any single number does. Garage stores metadata locally and needs no external database. SeaweedFS separates masters, volume servers and filers, with the filer commonly backed by an external store, which is more moving parts and also more room to tune. If throughput at your object size is the deciding factor, benchmark it on your hardware with your object size distribution. That is a weekend, and it is a better weekend than migrating twice.

Where each one actually loses

Garage loses if you need deep S3 API surface or a large single cluster. It is explicit that it targets small, self hosted, geo distributed deployments, and that focus is why it is pleasant to run. Focus is a synonym for "does less". It also loses on discoverability, for the reason described above: if your organisation evaluates tools by GitHub activity, Garage will lose that evaluation on a technicality.

SeaweedFS loses on operational simplicity. Multiple component types is not a marketing weakness, it is a real thing you will page someone about at three in the morning. It also loses if your team cannot commit to a version pinning and upgrade discipline, because a 36 release year rewards attention and punishes neglect.

MinIO loses the "should I start here" question outright, and we want to be precise rather than dramatic about why. If you are already running it, it has not stopped working, the AGPL source still exists, and AIStor Free is a real option if a vendor licensed free edition suits you. But starting a new self hosted deployment in 2026 on an archived repository, with no community binaries and a container image from September 2025, means adopting something with a known end date. That is a bad trade when two maintained alternatives speak the same protocol and your client code does not care which one answers.

If you are migrating, the order that works

Point a second S3 client at the new endpoint before you move a single byte. Because the SDK does not change, you can run both servers side by side and exercise your real upload path against the new one in a staging bucket. Verify the specific S3 features you depend on rather than the ones the comparison table lists: presigned URLs, multipart upload for anything large, and lifecycle or versioning if you rely on them. Those are where compatibility gaps actually bite, and they differ between implementations far more than the basic PUT and GET do.

Then copy, verify checksums, cut over, and keep the old endpoint readable for longer than you think you need to.

If after reading this you conclude that you would rather not run object storage at all, that is a legitimate answer and not a defeat. We wrote up the managed side of this decision separately, because for a lot of small teams the honest total cost of self hosting storage is higher than the invoice it replaces.

And if the shape of this story feels familiar, it should. A widely deployed open source infrastructure component changes its commercial posture, the community reaches for maintained alternatives, and the alternatives turn out to be a genuine upgrade for most people. That is very close to what happened with Redis and the caches that replaced it, and the lesson generalises: the projects that survive a licence or governance shock are the ones whose protocol was never the proprietary part.

Sources we read directly

Everything above was measured on August 24, 2026 from primary sources rather than from secondary coverage: the MinIO repository and its archive notice, the SeaweedFS repository and release history, and the canonical Garage repository on the Deuxfleurs forge. Package figures come from the public npm registry and downloads API for the minio package, and container dates from the Docker Hub tags API. Where a number in this article disagrees with an older article, check the date on the older article first. Most of page one predates the archive.