alt Hacker NewsMinIO repository is no longer maintained
Comments
They point to AIStor as alternative.
Other alternatives:
https://github.com/deuxfleurs-org/garage
https://github.com/rustfs/rustfs
https://github.com/seaweedfs/seaweedfs
https://github.com/supabase/storage
https://github.com/scality/cloudserver
Among others
First off, I don't think there is anything wrong with MinIO closing down its open source. There are simply too many people globally who use open source without being willing to pay for it. I started testing various alternatives a few months ago, and I still believe RustFS will emerge as the winner after MinIO's exit. I evaluated Garage, SeaweedFS, Ceph, and RustFS. Here are my conclusions:
1. RustFS and SeaweedFS are the fastest in the object storage field.
2. The installation for Garage and SeaweedFS is more complex compared to RustFS.
3. The RustFS console is the most convenient and user-friendly.
4. Ceph is too difficult to use; I wouldn't dare deploy it without a deep understanding of the source code.
Although many people criticize RustFS, suggesting its CLA might be "bait," I don't think such a requirement is excessive for open source software, as it helps mitigate their own legal risks.
Furthermore, Milvus gave RustFS a very high official evaluation. Based on technical benchmarks and other aspects, I believe RustFS will ultimately win.
https://milvus.io/blog/evaluating-rustfs-as-a-viable-s3-comp...
I successfully migrated from MinIO to Ceph, which I highly recommend. Along the way, I tested SeaweedFS, which looked promising. However, I ran into a strange bug, and after diagnosing it with the help of Claude, I realized the codebase was vibe-coded and riddled with a staggering number of structural errors. In my opinion, SeaweedFS should absolutely not be used for anything beyond testing — otherwise you're almost certain to lose data.
I just bit the bullet last week and figured we are going to migrate our self hosted minio servers to ceph instead. So far 3 server ceph cluster has been setup with cephadm and last minio server is currently mirroring its ~120TB buckets to new cluster with a whopping 420MB/s - should finish any day now. The complexity of ceph and it's cluster nature of course if a bit scary at first compared to minio - a single Go binary with minimal configuration, but after learning the basics it should be smooth sailing. What's neat is that ceph allows expanding clusters, just throw more storage servers at it, in theory at least, not sure where the ceiling is for that yet. Shame minio went that way, it had a really neat console before they cut it out. I also contemplated le garage, but it seem elasticsearch is not happy with that S3 solution for snapshots, so ceph it is.
The thing that strikes me about this thread is how many people are scrambling to evaluate alternatives they've never tested in production. That's the real risk with infrastructure dependencies — it's not that they might go closed-source, it's that the switching cost is so high that you don't maintain a credible plan B.
With application dependencies you can swap a library in a day. With object storage that's holding your data, you're looking at a migration measured in weeks or months. The S3 API compatibility helps, but anyone who's actually migrated between S3-compatible stores knows there are subtle behavioral differences that only surface under load.
I wonder how many MinIO deployments had a documented migration runbook before today.
See https://news.ycombinator.com/item?id=46136023 - MinIO is now in maintenance-mode
It was pretty clear they pivoted to their closed source repo back then.
We all saw that coming. For quite some time they have been all but transparent or open, vigorously removing even mild criticism towards any decisions they were making from github with no further explanation, locking comments, etc. No one that's been following the development and has been somewhat reliant on min.io is surprised. Personally the moment I saw the "maintenance" mode, I rushed to switch to garage. I have a few features I need to pack in a PR ready but I haven't had time to get to that. I should probably prioritize that.
If you are struggling with observability solutions which require object storage for production setups after such news (i.e. Thanos, Loki, Mimir, Tempo), then try alternatives without this requirement, such as VictoriaMetrics, VictoriaLogs and VictoriaTraces. They scale to petabytes of data on regular block storage, and they provide higher performance and availability than systems, which depend on manually managed object storage such as MinIO.
COSS companies want it both ways. Free community contributions and bug reports during the growth phase. Then closed source once they've captured enough users. The code you run today belongs to you. The roadmap belongs to their investors.
This is timely news for me - I was just standing up some Loki infrastructure yesterday & following Grafana's own guides on object storage (they recommend minio for non-cloud setups). I wasn't previously experienced with minio & would have completely missed the maintenance status if it wasn't for Checkov nagging me about using latest tags for images & having to go searching for release versions.
Sofar I've switched to Rustfs which seems like a very nice project, though <24hrs is hardly an evaluation period.
What is the best alternative that can run as a Docker image that mimics AWS S3 to enable local only testing without any external cloud connections?
For me, my only use for Minio was to simulate AWS S3 in docker compose so that my applications were fully testable locally. I never used it it production or as a middle ware. It has not sat well with me to use alternative strategies like Ruby on Rails' local file storage for testing as it behaves differently than when the app is deployed. And using actual cloud services creates its own hurdles of either credential sharing among developers and gets rid of the "docker magic" of being to run a single set up script and be up and running to change code and run the full test suite.
My use case is any developer on the team can do a Git clone and run the set up script and then be fully up and running within minutes locally without any special configuration on their part.
Anyone interested in keeping access should fork this open source repository now and make a local archived copy. That way when this organization deletes this repository there can still be access to this open source code.
In the Ruby on Rails space, we had this happen recently with the prawn_plus Gem where the original author yanked all published copies and deleted the GitHub repository.
On GitHub, when a private repo is deleted forks are deleted. But for public repos, the policy is different. See https://docs.github.com/en/pull-requests/collaborating-with-....
This is the latest of a sunset trap set for those of us who use Minio for local testing but not production use.
Has anybody actually tried AIStor ? Is it possible to migrate/upgrade from a minio installation to AIStor ? It seems to be very simple, just change the binary from minio to aistor: https://docs.min.io/enterprise/aistor-object-store/upgrade-a...
Is AIStor Free really free like they claim here https://www.min.io/pricing, i.e
Free
For developers, researchers, enthusiasts, small organizations, and anyone comfortable with a standalone deployment.
Full-featured, single-node deployment architecture
Self-service community Slack and documentation support
Free of charge
This is becoming a predictable pattern in infrastructure tooling: build community on open source, get adoption, then pivot to closed source once you need revenue. Elastic, Redis, Terraform, now MinIO.
The frustrating part isn't the business decision itself. It's that every pivot creates a massive migration burden on teams who bet on the "open" part. When your object storage layer suddenly needs replacing, that's not a weekend project. You're looking at weeks of testing, data migration, updating every service that touches S3-compatible APIs, and hoping nothing breaks in production.
For anyone evaluating infrastructure dependencies right now: the license matters, but the funding model matters more. Single-vendor open source projects backed by VC are essentially on a countdown timer. Either they find a sustainable model that doesn't require closing the source, or they eventually pull the rug.
Community-governed projects under foundations (Ceph under Linux Foundation, for example) tend to be more durable even if they're harder to set up initially. The operational complexity of Ceph vs MinIO was always the tradeoff - but at least you're not going to wake up one morning to a "THIS REPOSITORY IS NO LONGER MAINTAINED" commit.
Will https://github.com/chainguard-forks/minio hold the fork?
AGPL is dead as a copy-left measure. LLMs do not understand, and would not care anyway, about regurgitating code that you have published to the internet.
I wonder how many of the 504 contributors listed on GitHub would still have contributed their (presumably) free labor if they had known the company would eventually abandon the open source version like this while continuing to offer their paid upgraded versions.
Tangentially related, since we are on the subject of Minio. Minio has or rather had an option to work as an FTP server! That is kind of neat because CCTV cameras have an option to upload a picture of motion detected to an FTP server and that being a distributed minio cluster really was a neat option, since you could then generate an event of a file uploaded, kick off a pipeline job or whatever. Currently instead of that I use vsftpd and inotify to detect file uploads but that is such a major pain in the ass operate, it would be really great to find another FTP to S3 gateway.
I was recently migrating a large amount of data off of MinIO and wrote some tools for it in case anybody needs that https://github.com/dialohq/minio-format-rs
I heard that one of the reasons for this was that Minio was not happy people were including it in their commercial products without attribution
This is pretty predictable at this point. VC-backed open source with a single vendor always ends up here eventually. The operational tradeoff was always MinIO being dead simple versus Ceph being complex but foundation-governed. Turns out "easy to set up" doesn't matter much when you wake up to a repo going dark. The real lesson is funding model matters more than license. If there's no sustainable path that doesn't involve closing the source, you're just on a longer timeline to the same outcome.
I use three clustered Garage nodes in a multi cloud setup. No complaints.
I've moved my SaaS I'm developing to SeaweedFS, it was rather painless to do it. I should also move away from minio-go SDK to just use the generic AWS one, one day. No hard feelings from my side to MinIO team though.
This has been on the cards for at least a year, with the increasingly doomy commits noted by HN.
Unfortunately I don't know of any other open projects that can obviously scale to the same degree. I built up around 100PiB of storage under minio with a former employer. It's very robust in the face of drive & server failure, is simple to manage on bare hardware with ansible. We got 180Gbps sustained writes out of it, with some part time hardware maintenance.
Don't know if there's an opportunity here for larger users of minio to band together and fund some continued maintenance?
I definitely had a wishlist and some hardware management scripts around it that could be integrated into it.
Looks like they pivoted to "AI storage", whatever that means.
On my side, I feel disappointed on two different counts.
- Obviously, when your selling point against competitor and alternative services was that you were Open Source, and you do a rug pull once you got enough traction, that is not great.
- But also they also switched of target. The big added value of Minio initially is that it was totally easy to run, targeting the possibility to have an s3 server running in a minute, on single instances and so... That was the perfect solution for rapid tests, local setups and automatic testing. Then, again once they started to get enough traction, they didn't just move to add more "scaling" solutions to Minio, but they kind of twisted it completely to be a complex deployment scalable solution like any other one that you find in the market. Without that much added value on that count to be honest.
We moved to garage because minio let us down.
Fair enough.
I've used minio a lot but only as part of my local dev pipeline to emulate s3, and never paid.
So far for me garage seems to work quite well as an alternative although it does lack some of the features of minio.
Is there not a community fork? Even as is, is it still recommended for use?
My use case for minio was simply to test out uploading things to s3 for work related apps.. I loved that web ui too.
Looks like i'm gonna give seaweedfs a whirl instead of hunting down the docker image and sha of the last pre-enshittified version of Minio
Took them how many weeks to go from „maintenance mode” to unmaintained?
They could just archive it there and then, at least it would be honest. What a bunch of clowns.
We just integrated minio with our strapi cms, and our internal tool admin dashboard. And have about two months worth of pictures and faxes hosted there. Shit. Ticking time bomb now.
I will have to migrate, the cost of "self hosting" what a pain!
omg move to rustfs
We moved to Garage. Minio let us down.
Lmao, that was fast.
[dead]
I ran a moderately large opensource service and my chronic back pain was cured the day I stopped maintaining the project.
Working for free is not fun. Having a paid offering with a free community version is not fun. Ultimately, dealing with people who don't pay for your product is not fun. I learnt this the hard way and I guess the MinIO team learnt this as well.