Mocks do that.
If you want to not totally change what you are doing in your app between environments, point it at an actual S3 bucket in all environments.
This post does not even mention the S3 API as a replacement for a filesystem.
But is that really something you do in an enterprise application?
What if you write a file with the same name from two servers to the bucket? What about latency? What if the connection / mount fails, how would the application even notice?
Never tried it, I don't think it fits our needs.
- 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:
- running a system using on locks will fail
- cache behaviors work fine for the "humans browsing files" usecase but not so much for other casesI 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
garage server --single-node --default-bucket
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.
(I work on SeaweedFS)
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
On the other hand, this means that it's bound by filesystem naming rules - e.g. you can't have an object named "abc/", or a pair of objects named "a" and "a/b".
Sadly most new projects do not offer posix anymore.
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.
Actually, AI does help a lot to setup all variations of testing scenarios and uncover edge case bugs. It's more helpful than vibes.
And you do need to be systematic to examine AI generated code. There are no shortcut for it.
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.
(I work on SeaweedFS)
Do you have plans to improve the docs? Some of the info I needed was inside GitHub issues / discussions.
Overall very cool project. One of these days I'll reach out about enterprise support for my usecase.
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.
Was the backend for an archiving service and we found it to work well on baremetal machines and seamlessly integrated with existing services that used the S3 api.
This was on an internal network so YMMV when it comes to running on the open internet especially with the CVE mentioned in the post.
When I tried minio 5 years ago it choked pretty quick on storing billions of objects
- Filesystem backend - Encrypted S3 backend - Compressed S3 backend (Saving a ton of money here) - Cross backend replication - Full IAM - Full GUI with OIDC auth
- slop copy [1]
[0] https://github.com/beshu-tech/deltaglider_proxy/graphs/contr...
I made it explicit Deltaglider was created by SWEs, aided by Fable 5.x.
Also, I asked Fable to un-slop the copy of the website, using this excellent skill https://github.com/blader/humanizer
Check it out, once again: https://deltaglider.com/
But no, I'm also not about to start one or try to make something like SeaweedFS a community supported project that has a chance to be picked up by the CNCF, so I'm part of the problem.
The S3 API is pretty well-documented so getting something compatible with it is trivial for modern AI tools.
Garage is good but has weird tooling and a terrible searchable term. You'll receive lots of garage doors and electrical gate results when searching for issues with it.
The biggest problem with Garage is the metadata on an sqlite. If you have a single file and that sqlite corrupts then all your data is unaddressable and treated as pile of anonymous blocks. If you have multiple servers you can rebuild the metadata but if you have only one server you REALLY need to make sure that file is backed up.
So if you use S3 as a backup you have to keep a backup of your backup.
RustFS is closer to Minio, but I hate the way they log stuff. They basically use journald as a metric database dumping json formatted lines about library calls and how long they took. Its hard to make sense of those logs. Its the kind of log not meant to be human readable but to render on a dashboard.
Why not just publish these as a prometheus endpoint?
Also high CPU usage for no reason. I also noticed RustFS constantly trashing disk and keeping 10% CPU usage while looping some health check I have no idea how to disable (I've tried RUSTFS_SCANNER_ENABLED=false and others with no results). And of course lots of json metrics on journald.
I personally prefer garage because my backup box sit at my office and I like not needing to listen to HDD sounds all day every day while Rustfs loops its health check.
AWS_ACCESS_KEY_ID=admin AWS_SECRET_ACCESS_KEY=secret S3_BUCKET=my-bucket ./weed mini -dir=./data
That's it.
The S3 endpoint is at http://localhost:8333, my-bucket exists, and admin/secret are valid credentials.
It also starts an Iceberg REST catalog and S3 Table Buckets for Iceberg and Lance tables, with table maintenance jobs.