Alternatives to MinIO for single-node local S3

Original Article ↗ Hacker News Discussion ↗

Self-hosted alternatives to MinIO for a single-node, S3-compatible object store are proliferating, with projects like Garage, RustFS, SeaweedFS, VersityGW, LocalStack, and various lightweight tools (s3fs, rclone serve, s3proxy, hs5, S2, etc.) all getting attention. Commenters weigh trade-offs around ease of setup, API compatibility (including conditional PUT/ETag semantics), performance, metadata durability, logging, and local development vs. production parity. Many note that MinIO’s licensing and ecosystem shifts have created a vacuum, leading to forks like Silo and a broader search for simple, reliable S3 stand-ins for dev, homelab, and smaller-scale production use.

Why local S3 instead of just the filesystem or real S3?

  • Some tools only speak S3; a local endpoint avoids changing app behavior between dev/CI and prod.
  • Local S3 lets customers choose: same S3 API, but either cloud or on-prem (e.g., a Docker container).
  • Filesystems and S3 solve different problems: hierarchical semantics, locking, NFS quirks, very large flat directories, and caching behavior can diverge from object store expectations.
  • Others argue you should abstract storage yourself and plug in either S3 or filesystem, or just always use real S3 buckets even in non-prod.

MinIO changes and the resulting “vacuum”

  • Many moved away from MinIO after licensing and “crippling” changes, though older versions still work in production for some.
  • A fork, now called “silo,” aims to be a stable, CVE-patched MinIO-compatible drop‑in; some report flawless migration and recommend it strongly.

Commonly mentioned alternatives

  • Garage: liked for stability and multi-node setups; some use it in homelabs and dev. Criticisms: setup is more complex, metadata on SQLite is a single point of failure, and it’s eventually consistent (unsuitable for Iceberg/conditional PUT workloads).
  • RustFS: praised as MinIO‑like, simple, and production‑proven by some; others hit many bugs and dislike logging/CPU behavior. Recent CVE raised concern about long‑term popularity.
  • Versity GW: repeatedly praised as simple, stable, and tightly mapped to the filesystem; good for homelabs and dev, with static website hosting. Filesystem mapping also imposes filename constraints.
  • SeaweedFS: viewed as powerful and fast with strong S3/IAM features and a very simple weed mini S3 mode; some report doc gaps and occasional instability or over‑rapid feature growth, though maintainers say docs and testing are improving.
  • Other tools mentioned: S2, rclone serve s3, s3fs on a local dir, LocalStack, Scality/Zenko, hs5 (focus on correctness and conditional operations), Incus’s built‑in S3, JuiceFS, Filestash gateway, s3proxy, custom homegrown S3 services.

API guarantees and advanced features

  • Conditional PUT/GET/DELETE and correct ETag behavior matter for systems like Iceberg and Litestream‑style locking.
  • Some implementations (RustFS, hs5, MinIO/silo) are said to handle conditional semantics correctly; Garage is explicitly eventually consistent and not suitable for these use cases.
  • Support for newer S3 features like locking is described as uneven across projects.

Operational and ecosystem concerns

  • Experiences range from “rock solid” to “corrupted and lost files” depending on project and setup.
  • Some are uneasy about single‑file metadata stores and the need to back up the S3 system’s own metadata.
  • There is disappointment that there is no CNCF‑style standard/community S3 project despite its centrality to cloud-native stacks.
  • Trust in projects backed by entities in specific countries (e.g., China) is debated; others counter that open-source transparency mitigates such concerns.