The same argument can be made for the other side: the customer can also trivially mount the S3 bucket as a filesystem, if you decide to ship the tool with filesystem support instead.
Yup, same. We use RustFS in a production system with no issues. We switched over after MinIO license changes and after evaluating a few different stacks.
We have heavy concurrent usage, and we haven't had a single issue yet.
I did try seaweedfs ~half a year ago and I had issues with setting up users through terraform module (if I recall correctly, users endpoint were not correctly responding on delete), and lack of S3 expiry rules (you needed to use seaweedfs configuration or API for that). Other than that, I was pretty happy with it.
I've been using it for local development for a while now. My goal was to replace MinIO, which I could run and configure with a single Docker command. VersityGW works just as well for that.
I use that aswell since it can be used and expose a posix filesystem. This is helpful when we want to add s3 to existing storage like a nas. (Well we had some problems with it in the past tough)
Sadly most new projects do not offer posix anymore.
Filestash (https://github.com/mickael-kerjean/filestash) has a s3 gateway plugin that I made. It proxy the S3 traffic to any downstream storage: SFTP, FTP, another S3, SMB, NFS, IPFS, ...
Almost went past looking at this option, it has a far bigger ecosystem of both storage and auth plugins and otherwise looks to be more mature than I might have guessed from the passing comment.
How does that handle concurrency (e.g. updates being atomic, conditional PUT) and data consistency after a crash? Getting that right over generic backends sounds challenging, to say the least.
The title is 'for single node local S3' but what they actually mean is 'for minio-compatibility', which is an entirely different question.
When I abandoned minio a year or so ago, I also surveyed the options, and settled on Garage. It lacked the GUI, but felt about the same complexity as minio. Perhaps a smidge more complexity, as I moved to 3-node and 5-node separate instances of garage, running as containers under Nomad.
I don't recall it being onerous, but I was looking for some basic S3-alike capabilities, not just minio-alike.
(How many people set out to build an object storage system with some number of AWS S3 primitives, but primarily try to match a third-party proprietary system's foibles?)
> So, Garage does work, but gosh…it is not just a drop-in replacement in terms of code changes.
I think in terms of actual code that uses local S3, it pretty much was a drop-in replacement. (I have multiple distribution/registry, Grafana Loki / Mimir, influx3 - all backing onto my object storage system, and the config changes there were modest - key+secret, and url - just as you'd expect.)
In the decades that open-source projects have existed on GitHub—even those backed by the Chinese government—there has never been an instance of them containing spyware; conversely, we frequently see NSA hacking tools exploiting open-source projects to launch massive cyberattacks and cause data breaches. Reality isn't like American movies where Americans are always the heroes; in fact, those GIs are usually the ones doing the invading. To me, your statement sounds like a resident living under Nazi rule telling everyone, "There's actually a pretty good project over on the Allied side—if you choose to believe it."
> 2026-03-02: Ruohang Feng has forked MinIO to pgsty/minio and is promising to maintain a stable, CVE-patched, distribution.
This is what I went with.
I use it in end to end tests as an S3 simulator that starts and stops instantly and reads & writes to a local directory, - as you'd expect it's great in that role. No complaints. Given the fork's maintainer puts their real name on it & stakes their reputation, you'd assume it can be trusted - but my use case is simpler than most.
This is what I use. I had a minio instance that was replaced flawlessly with silo. This is an excellent project and needs more traction. All existing minio users must switch to Silo ASAP.
I had switched some projects to SeaweedFS's Docker image. It worked well. This is good to know there is a successor open source project that would require no code changes to use. Will evaluate.
It's nice to hear about other products, but OP made it sound like Minio disappeared and was not an option. Neither are true. Yes the company moved on but the old source is sitting there and that version is pretty good as-is. We're still using it in prod, no issues for us. The old container images are floating around and you're free to copy them to wherever.
If you need support or newer features, fork it or use ^ this fork.
It's nice, I am just afraid of the pace Chris Lu can maintain with LLM assistance. Too many features are added in each new release, no stabilization time at all.
Running Sentry on prem, I had to swap out their default SeaweedFS setup for Garage because the former kept failing under concurrent writes. I tried digging around for a bit, but found that the swap was easier and faster, Garage has also worked great for single node use cases (e.g. tested up to around 10 TB of data). I still think that SeaweedFS is a cool project, might have been a config issue or something, wasn’t worth tweaking.
The setup for Garage sucks, especially cause their Docker image doesn’t automatically create keys or buckets and permissions for you like for example various RDBMS images do. Doing that the first time manually was annoying, but their docs are pretty nice and an AI agent can build you your own Docker image with custom init in about 15 minutes.
Worst with it I’ve had were issues with hooking up WinSCP to it directly to browse saved satellite data, initial connections would hang for some reason, not sure what the problem was either.
Also used Zenko but kinda got the feeling that the project wasn’t as healthy and straight up felt abandoned (e.g. the outdated container images and such), though there is some activity.
Not without snapshot currently. I guess I could collect all writes in the (optional) WAL file while a backup is running, then the files would be consistent.
Is there any "local"/minio-esque object store properly implements the full conditional GET/PUT/DELETE spec, ETag, etc.? I have struggled to find this in the past.
I wouldnt use Garage for Iceberg, Iceberg relies on conditional PUT working correctly, while Garage is eventually consistent, so they don't provide the correct guarantee.
I run Scality S3 (Zenko Cloudserver in the blig) since about 2 years and it is quite capable and frequently updated. Just make sure to point it to the latest Github Registry, not the outdated Docker.com one.
I had previously used seaweedfs, which has more moving parts but seems more feature-rich. It was overkill for a homelab, so I went to garage.
Garage is very stable, but the metadata engine / file MUST live on NVMe. Otherwise it gets slow on small files. It also lacks features like per bucket retention settings and stuff. It really is "just" a S3 bucket.
85 comments
[ 0.24 ms ] story [ 40.0 ms ] thread- very flat structures: storing hundred of thousands of files in a single directory will fail
- designed for local disks and NFS is a leaky abstraction:
probably many more reasonsI wouldn’t say this if I hadn’t done this on the PB scale. On a file system! With billions of files!
People are blind to anything other than shitty cloud APIs now. It’s depressing.
Sometimes I also want a smaller version for when I don't need that performance but don't want multiple implementations of storage backends
Edit: before someone says NVMe, highly available across 3 fault domains
We have heavy concurrent usage, and we haven't had a single issue yet.
If we're just talking verifying S3 connectivity, simply spinning up "rclone serve s3" appears to be the simplest solution.
On flipside the project maintainers react very fast on any bug I submitted and it's fixed pretty quickly, so not really complaint, just warning
Also discussions few months ago here when healthcheks.io switched to it: https://news.ycombinator.com/item?id=47806348
https://github.com/versity/versitygw/#static-website-hosting
Sadly most new projects do not offer posix anymore.
https://garagehq.deuxfleurs.fr/
The title is 'for single node local S3' but what they actually mean is 'for minio-compatibility', which is an entirely different question.
When I abandoned minio a year or so ago, I also surveyed the options, and settled on Garage. It lacked the GUI, but felt about the same complexity as minio. Perhaps a smidge more complexity, as I moved to 3-node and 5-node separate instances of garage, running as containers under Nomad.
I don't recall it being onerous, but I was looking for some basic S3-alike capabilities, not just minio-alike.
(How many people set out to build an object storage system with some number of AWS S3 primitives, but primarily try to match a third-party proprietary system's foibles?)
> So, Garage does work, but gosh…it is not just a drop-in replacement in terms of code changes.
I think in terms of actual code that uses local S3, it pretty much was a drop-in replacement. (I have multiple distribution/registry, Grafana Loki / Mimir, influx3 - all backing onto my object storage system, and the config changes there were modest - key+secret, and url - just as you'd expect.)
This is what I went with.
I use it in end to end tests as an S3 simulator that starts and stops instantly and reads & writes to a local directory, - as you'd expect it's great in that role. No complaints. Given the fork's maintainer puts their real name on it & stakes their reputation, you'd assume it can be trusted - but my use case is simpler than most.
> Renamed from pgsty/minio to pgsty/silo, default branch master → main, on 2026-08-06
I had switched some projects to SeaweedFS's Docker image. It worked well. This is good to know there is a successor open source project that would require no code changes to use. Will evaluate.
It's nice to hear about other products, but OP made it sound like Minio disappeared and was not an option. Neither are true. Yes the company moved on but the old source is sitting there and that version is pretty good as-is. We're still using it in prod, no issues for us. The old container images are floating around and you're free to copy them to wherever.
If you need support or newer features, fork it or use ^ this fork.
The setup for Garage sucks, especially cause their Docker image doesn’t automatically create keys or buckets and permissions for you like for example various RDBMS images do. Doing that the first time manually was annoying, but their docs are pretty nice and an AI agent can build you your own Docker image with custom init in about 15 minutes.
Worst with it I’ve had were issues with hooking up WinSCP to it directly to browse saved satellite data, initial connections would hang for some reason, not sure what the problem was either.
Also used Zenko but kinda got the feeling that the project wasn’t as healthy and straight up felt abandoned (e.g. the outdated container images and such), though there is some activity.
One notable thing is that compared to MinIO (and others) it does not store the objects as individual files. I also have DuckDB directly integrated.
The readme has a comparison to Garage, seaweedfs, RustFS and Ceph.
Is there a safe way to make backups of the index.lmdb and data0 files without stopping the server?
Garage is very stable, but the metadata engine / file MUST live on NVMe. Otherwise it gets slow on small files. It also lacks features like per bucket retention settings and stuff. It really is "just" a S3 bucket.
No thanks.