While many projects turn to open source to grow their community, ensure longevity, and keep improving their products, MinIO, a high-performance object storage server fully compatible with Amazon S3, seems to be heading in the opposite direction. Why am I saying this?
Because the MinIO team has once again stirred community debate after quietly discontinuing pre-built binaries for its Community Edition. According to the project, users must now build MinIO entirely from source — a move that many see as a setback for accessibility and open-source collaboration.
The change surfaced after users noticed missing Docker and Quay images, confirmed in a GitHub issue where MinIO maintainers stated that only “source-only distributions” will be provided moving forward.
In other words, if you’ve been using MinIO’s Docker images for your deployments, well… from now on, you’ll have to build them yourself. This move caught many users off guard. For context, MinIO’s images on Docker Hub have been downloaded over a billion times—so you can imagine just how many people this change is going to affect.
While the company argues that this ensures better control and compliance, the open-source community has a different view, raising concerns about openness and trust in the project’s direction. Many long-time users criticize the decision as another step away from transparency and open-source principles, and as a complication for automated deployments and CI/CD workflows that rely on official binaries.
In fact, this is actually the second hit the open-source community has taken from MinIO. As we informed you, less than five months ago, the company removed nearly all useful tools from the admin web console in the community version, keeping them only for paying customers.
Now, with this latest move, a serious question arises again — can MinIO still be considered a reliable option for open-source communities relying on the free version? Here’s my honest, personal take on it.
At this point, it’s pretty clear that MinIO is trying to discourage users of its community version and steer them towards the paid one, walking a very fine line between open source and proprietary software. And while that might be understandable from a business standpoint, the way they’re going about it has raised quite a few eyebrows.
Changes seem to come out overnight—no transparency, no advance notice, and no official announcements. One day, everything’s fine, and the next, you stumble upon a passing comment buried somewhere in a GitHub thread that reveals a major shift.
That says a lot about the company’s attitude and approach to the open-source community. Sure, MinIO has built a strong reputation and millions of users who trust its open-source product. But turning that success into a monetization strategy could turn out to be a double-edged sword.
Given how unpredictable the company’s actions have been lately, if you’re an open-source enthusiast or a small business that depends on MinIO, it might be time to rethink just how reliable it really is to keep using this software.
The good news is that there are great, fully open-source alternatives out there — like Garage or RustFS — that are well worth a serious look if you’re thinking about migrating away from your current MinIO setup.
So, to conclude—for now—users who depend on MinIO’s precompiled builds must either adapt to compiling from source or switch to an alternative solution. I’ll wrap things up with a user’s comment on GitHub that really says it all: “Anyway, thanks for all the fish — time to fork and build.”
We are trying to replace MinIO with RustFS.
This policy of Minio is too disappointing.
Except “RustFS is under rapid development. Do NOT use in production environments!”
Yes, that shows the RustFS team is very responsible.
In fact, I’ve been working on RustFS for over a month, and it’s very stable.
I don’t know why they’re warning against production use.