They've been anti-open source for a while, they clearly don't see a profit motive without killing off their open source side. Anyone selfhosting or into open source should consider MinIO dead, and migrate. Hopefully someone forks it.
this post was submitted on 26 Apr 2026
161 points (98.2% liked)
Selfhosted
58868 readers
1399 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
Hopefully someone forks it.
people did, and then proceeded to do nothing with it.
I don't like minio's moves here or the way they communicated it but they weren't wrong when they said the community was not contributing in a significant way.
Garage seems like a viable alternative.
Garage has one big flaw. Access control tools are nearly non existent.
Garage has been great in my homelab. It's not quite as 1:1 with S3 but it does all the basics with some really nice features.
Where they lose comparability they have a good explanation too
load more comments
(1 replies)
Was pretty much clear since last year. At the latest in December when they switched to "maintenance mode". And now they archived it.
https://blog.vonng.com/en/db/minio-is-dead/
Alternatives include Garage, SeaweedFS (and RustFS).
Edit: RustFS looks very sketchy. Read object Object's comment below before using it.
Rustfs is sketchy as fuck though.
Thanks for pointing it out. Yeah it does. I just copy-pasted what I found and didn't check.
For posterity because I didn’t explain why/how it’s sketchy:
- they just found a hardcoded key that skips all security that was in the wild for like two years
- significant vibe coding means nobody actually understands the codebase. Hence not finding the backdoor key
- some of the documentation is only in Chinese, which isn’t sketchy in itself, but given the backdoor key does seem fucking sketchy.
- they have an X link you cannot remove from the admin console
- the admin console has minor but stupid bugs: you can’t go from a bucket to the list of buckets, auth is janky, etc.
Just because it’s good a good name doesn’t make it good pedigree (which is a bone I have with rustXYZ named projects). The fact nobody caught serious backdoors for years is damning.
If you’re running this offline, it might be fine for you. I still run it inside my vpn behind auth but I’m looking to move off.
Thx very much. That's valuable info. I edited my comment and crossed it off my list of software to evaluate for future projects. I already got the vibe-coding and a bit of sketchiness by scrolling through the latest commits and issue tracker.
Versity S3 Gateway is another option that's trying to focus on simplicity. https://github.com/versity/versitygw
Out of all these, SeaweedFS is the most scalable. Seaweed's design is based off some of Facebook's whitepapers about their warm storage system, and it works especially well for use cases that have a very large number of small files (like images).
Versity S3 Gateway is Apache‑licensed, backed by a commercial entity. Their contribution agreement forces you to give up copyright to them. It will follow the same path as Minio over time.
Their contribution agreement forces you to give up copyright to them.
The license just looks like the standard Apache license though, which doesn't require this. With the Apache license, contributors still own the copyright to their code, but they license it to the project. Did you see a document in the repo that says something different?
Check their contribution rules. https://github.com/versity/versitygw/wiki/Contributing-Changes
quoting
All new files in the change should have the versitygw copyright and license headers.
Interesting - I didn't see that. They say "You can add your own copyright as well", so you don't have to give up your rights to the code. They do still need to comply with the terms of the Apache license.
Of course their closed source alternative is called AIStor and it is crazy expensive because everyone now needs to pivot to AI
Oddly enough right before I saw this post some alternatives were in my news feed.
https://itsfoss.com/news/minio-moves-away-from-open-source/
Highlights are:
SeaweedFS
Garage
RustFS
I've honestly never understood the need for s3 buckets. WebDAV satisfies my needs. I'm sure there are some use cases that require S3, but for the life of me I can't think of one off the top of my head right now.
Many cloud providers offer S3-compatible storage, so it's a common protocol to use in applications. There are even some databases like SlateDB that fully rely on object storage for everything. Being able to have local S3 compatible storage is useful if you want the storage of your local machine while still doing so over a widely compatible protocol.
A quick web search shows slatedb supports WebDAV through Rust's object_store interface, or at least it does at first glance.
WebDAV is a wonderful standard and it is compatible with all kinds of things that seem to be overlooked. S3 has turned into this monster of a thing that's "owned" by AWS vs a nice usable RFC that anybody can implement and know if it actually changes.
object_store does indeed also support WebDAV among a variety of other protocols, Apache Druid or Apache Pinot probably would be better examples. My only experience with WebDAV is with Nextcloud and hasn't been that great because it has been very slow, probably should look into it sometime.
EDIT: Apparently it supports CAS, and even has a locking mechanism
S3 is not made for you. It's made for entities that need to store millions of objects, with thousands of different rules, reading/writing from hundreds of machines without coordination, and with consistent, low latency. Now that some software use that as a storage layer, having an implementation for you is useful
So, it's mostly used for overengineering?
No, it's made for entities managing data for thousands/millions of people. “overengineering" implies a specific scope, it's not the one you think about
In my experience I've mostly seen it used for a local equivalent of S3 to plop in your dev environment. It's pretty good if your prod depends on S3 and you don't want to deal with the cost and latency of using actual S3 buckets during development.
I use an external S3 provider so that I only pay for the storage I use for the services I host. It's dirt cheap, 0.00002750€ per GiB hour (excluding tax). Self-hosting something like MinIO for your app gives you the option of switching to an external provider later on, and it gives you flexibility in the location of the storage.
Shit, I am actually building a webtool and thought Minio could be a good part to be a file storage in it. What's an good alternative?
Edit: I try "garage"
...a hard disk? you can just write data to a file
Not if you want to validate S3 compatibility for an actual future use case or, * can you imagine*, just for the fun of it.
i'll give you the second case, but nobody should plan for putting stuff on aws with the world as it looks right now...
Practically every other object storage provider offers an S3-compatible API.
I use S3 with OVH at my workplace. So it's not just aws / google.
load more comments
(6 replies)
S3 compatibility is nice I guess if you need S3 compatibility but also... why would you need that?
sshfs does everything I need and compatibility is almost native.
SSHFS is a hack and has nothing to do with the proposal of S3 compatible backends
So enlighten me then, save me from my terrible hack that is working fine for me and tell me what it DOES have to do with. I thought S3 was a remote filesystem you can use, essentially Amazon's proprietary version of webdav where you get a http bucket you can only access with aws proprietary tools. What's the attraction? Clearly it seems like people love it, and I am getting dunked on for asking an honest question, which feels a bit unhealthy and unpleasant for the self-hosting community.
Am I supposed to be familiar with AWS infrastructure as a prerequisite for being here?
S3 is made for scaling. At an individual scale it doesn't matter. At scale, S3 moves maintenance time away from managing individual issues about something not working or slow here and there towards configuring and maintaining a consistent piece of architecture
That's great for production AWS managed services, but that still sounds like the opposite of self-hosting to me, I don't need scaling like that, I'm not lying when I admit I'm using sshfs (which was a slightly tongue-in-cheek counterpoint to s3) and despite everyone dunking on it, it is in fact working perfectly at my scale. I know I've been downvoted to purgatory but I still stand by my original comment. I don't understand why you would need S3 or S3 compatibility in a self-hosting context. The closest someone has come to explaining it is the guy who said choice is good... like, yeah, it's good to have the choice I guess, but... still doesn't seem like a great choice for self-hosting. I appreciate you trying to explain it but I feel like everyone is missing the self-hosting context here. For a little home lab I simply don't see the value. Why are people promoting AWS and AWS-adjacent services here?
ok, to start with, if you need a POSIX interface to the filesystem, you already have an SSH connection to that server, and don't need much stability across multiple clients, SSHFS may do just fine. For a homelab, that is likely the case.
now, if you're hosting a web server that needs data distributed across drives/nodes, data redundancy, and the usage is primarily programmatic, closer to a CDN's or machine learning pipeline than a single user browsing files; then you want an S3-compatible solution. The S3 API makes it easier to plug it into your application, while allowing you to migrate to a different one - which I'm actually currently doing for a MinIO deployment at work.
load more comments
(1 replies)
S3 is designed for being used by applications via API, for example you can easily save and retrieve files from it even with a JavaScript application. It is much more difficult to do the same with sshfs
If instead you use it mounted on a computer, S3 is worse because each time you need to list its contents that's an API request, if you have hundreds of thousands of files then it's thousands of API reuqests
SSHFS is very unreliable. At least use NFSv4 or even SMB/CIFS.
Sshfs has way more overhead and doesn't do remotely the same thing
load more comments
(2 replies)
view more: next ›