When we said we were leaving MinIO, the most common reaction was: why? This article answers that question with sources and what we experienced in practice. It is the companion article to the execution report: that one explains how; this one explains why we left MinIO. One note: this is an opinion piece, written by people who pay the bills for a small team, and opinions are marked as such.
What happened to the MinIO community edition
The MinIO community edition gradually lost features throughout 2025. In June, Blocks and Files reported that management features had been removed from the basic edition’s code. According to the timeline compiled by ayedo, the project stopped publishing Docker images to public registries in October, entered maintenance mode in December, and, in early 2026, began warning that the repository was no longer maintained. In December, InfoQ was already discussing alternatives compatible with the S3 API. Check the dates in the sources: here we are using their summaries, not relying on our memory.
What changed for us
In practice, four things. First, without upstream maintenance, security fixes are no longer something you can count on. Second, distribution: when one of our teams tried to download the MinIO image for a CI test, it found that all public channels were closed or lacked anonymous access. Third, the console: the community version had already lost its full administration interface.
Fourth—and this is our opinion—the path MinIO points to is the commercial product, AIStor, and for a small team that price is far too high. We will not include a number here because pricing changes and depends on the contract: run the numbers for yourself. Ours did not work out.
None of these issues brings down a server today. But all of them push the cost into the future, and a small team does not have enough slack to pay that cost all at once during a bad night.
The decision criteria
We started with three criteria. Zero changes for customers: our applications, backups, and website speak S3 using fixed keys and hostnames, so every reconfigured consumer is a risk. A real rollback: it must be possible to go back with one command, with the data intact. And low cost, both operational and licensing: a small team should not have to learn an entirely new system or pay for a subscription that does not fit the budget because of a forced migration.
The trade-off is honest. These criteria favor the option most similar to what we already have, which leaves us one step behind a new architecture that might be better in the long term.
Why Silo now, and RustFS or Garage later
Silo is a community fork maintained by Pigsty that, according to the project’s own manifesto and documentation, keeps the S3 API, environment variables, and on-disk format, while restoring the built-in console under the AGPLv3 license. Because these sources come from the project itself, we validated compatibility using our own data before trusting it; the report is in the execution article.
That fits all three criteria, so Silo is our bridge. It is not the destination. Later, we will look at RustFS if we want something similar to the MinIO way of operating, and Garage if the priority shifts to multiple locations with modest hardware. We have not evaluated other alternatives in depth, so this article neither recommends nor dismisses them.
Wrapping up
Now for the jab: yes, we call the MinIO team traitors to open source. They took an open project, gradually hollowed out the community edition, and pushed everyone toward the paid product. That is our opinion, expressed with our usual irony. And, again, it is just a jab, a joke, not something to be taken seriously. In fact, the ending is very open source: the code they released is precisely what allows a fork like Silo to exist.
The decision itself is about risk, cost, and team size. If your situation is similar, the best first step is simple: find out who depends on your storage and choose the migration that does not force anyone to change.