Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • For single-node local S3, I often just use `s3fs` mounting a local directory. MinIO always felt like overkill for simple dev.
  • 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.
  • 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 implemented this (HS5). Etags match the AWS S3 ones as well.
  • 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.

  • The very first thing Garage did after I installed it on a test three-node cluster is get corrupted and lose files.

    No thanks.

  • The trouble I had with SeaweedFS was that the docs I found were rather sparse. Garage, on the other hand seemed pretty well documented.
  • For testing/dev setups you can turn sync off and get some performance back but that's only useful for cases where losing data is okay.
  • We ran RustFS in production at a past job.

    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.

  • This has been my solution as well. It has recently been added as an integrated service via devenv:

    https://devenv.sh/services/rustfs/

    by rch
  • A weird target, the author has.

    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.)

    by Jedd
  • 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.
  • My https://github.com/uroni/hs5 is designed for this use case.

    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.

  • Very cool, I like the conceptual simplicity of it. Even I can understand it, at least at a surface level :-)

    Is there a safe way to make backups of the index.lmdb and data0 files without stopping the server?

  • 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.

  • SeaweedFS performance should be the fastest. Please create an issue if there are any performance issues with SeaweedFS, or you see it is slower than any alternatives.

    (I work on SeaweedFS)

  • A notable mention should also be Versity GW, https://github.com/versity/versitygw/
  • I've had good experiences with Versity GW too and it's a shame it's not more well known.
  • I'm quite pleased with it. It's also nice that it translates directly to the file system .
  • This is what I switched to as well, works nicely. Can have just a folder as a backend as well, which makes things pretty simple.
  • Use it for my homelab too, super nice and stable. Support also delivering static website/asset.

    https://github.com/versity/versitygw/#static-website-hosting

  • 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.

    by merb
  • +1 switched to versity for homelab, been simple and stable as a rock. Point at a directory per bucket and done.

    Also discussions few months ago here when healthcheks.io switched to it: https://news.ycombinator.com/item?id=47806348

  • Garage added an automatic configuration feature in v2.3.0 that makes it easier to set up single nodes:

      garage server --single-node --default-bucket
    
    https://garagehq.deuxfleurs.fr/documentation/quick-start/
  • I can vouch for Garage too. It was a lot simpler imo than minio and works great over a handful of servers in different DCs.
  • > 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.

  • I might have to try this. I’m currently pinned on the last non-crippled version of minio