Alternatives to MinIO for single-node local S3
Recorded: Sept. 15, 2026, 2:57 p.m.
| Original | Summarized |
Alternatives to MinIO for single-node local S3 rmoff's random ramblings Interesting Links Categories Home Alternatives to MinIO for single-node local S3 14 Jan 2026 Table of Contents MinIO baseline S3Proxy Comparison S3MinIOApache Iceberg In late 2025 the company behind MinIO decided to abandon it to pursue other commercial interests. In this blog post I’m going to look at some alternatives to MinIO. Whilst MinIO is a lot more than 'just' a glorified tool for emulating S3 when building demos, my focus here is going to be on what is the simplest replacement. Must have a Docker image. So many demos are shipped as Docker Compose, and no-one likes brewing their own Docker images unless really necessary. Must provide S3 compatibility. The whole point of MinIO in these demos is to stand-in for writing to actual S3. Must be free to use, with a strong preference for Open Source (per OSI definition) licence e.g. Apache 2.0. Should be simple to use for a single-node deployment Should have a clear and active community and/or commercial backer. Any fule can vibe-code some abandon-ware slop, or fork a project in a fit of enthusiasm—but MinIO stood the test of time until now and we don’t want to be repeating this exercise in six months' time. Bonus points for excellent developer experience (DX), smooth configuration, good docs, etc. I’m purely looking at the single-node local S3 experience. What I’m not looking at is, for example, multi-node deployments, distributed storage, production support costs, GUI capabilities, and so on. All of the code in this project can be found in this repo. MinIO baseline 🔗 My starting point for this is a very simple Docker Compose stack: DuckDB to read and write Iceberg data that’s stored on S3, provided by MinIO to start with. You can find the code here. The Docker Compose is pretty straightforward: DuckDB, obviously, along with Iceberg REST Catalog MinIO (S3 local storage) mc, which is a MinIO CLI and used to automagically create a bucket for the data. When I insert data into DuckDB: INSERT INTO cat.test.products VALUES it ends up in Iceberg format on S3, here in MinIO: $ mc ls minio/warehouse/test/products/data/ [2026-01-12 14:35:55 UTC] 693B STANDARD 019bb2a2-8ad5-7159-968c-3693c3578902.parquet In each of the samples I’ve built you can run the test.sh to verify it. ❯ ./test.sh ░▒▓██████████████████████████████████████████████████▓▒░ 1. Checking MinIO buckets (before)... 2. Creating Iceberg table and inserting data... 3. Verifying data in DuckDB... ┌───────┬───────────┬───────────────┐ 4. Checking MinIO bucket contents (after)... MinIO alternatives 🔗 Let’s now explore the different alternatives to MinIO, and how easy they are to switch MinIO out for. I’ve taken the above project and tried to implement it with as few changes to use the replacement for MinIO. S3Proxy 🔗 💾 Example Docker Compose Version tested: 3.0.0 ✅ Docker image (5M+ pulls) ✅ Licence: Apache 2.0 ✅ S3 compatibility Ease of config: 👍👍 Very easy to implement, and seems like a nice lightweight option. One thing I did notice was that one of the projects that S3Proxy uses, jclouds, was moved to the Apache Attic (i.e. retired) in mid-2025—although probably nbd if you’re only using local storage anyway? RustFS 🔗 💾 Example Docker Compose Version tested: 1.0.0-alpha.79 Ease of config: ✅✅ ✅ Docker image (100k+ pulls) ✅ Licence: Apache 2.0 ✅ S3 compatibility Be aware that there was recently a pretty bad security vuln found in RustFS, which has put some people off from using it. RustFS also includes a GUI: SeaweedFS 🔗 💾 Example Docker Compose Version tested: 4.06 ✅ Docker image (5M+ pulls) ✅ Licence: Apache 2.0 ✅ S3 compatibility Ease of config: 👍 This quickstart is useful for getting bare-minimum S3 functionality working. Edit: Straight after posting this blog, the project replied to say they’ll be removing this extra requirement, making it even easier to use! How cool is that :) This is completed in https://t.co/RQv387bbKb and will be included in the weekly release.— SeaweedFS (@SeaweedFS) January 14, 2026 SeaweedFS comes with its own basic UI which is handy: The SeaweedFS website is surprisingly sparse and at a glance you’d be forgiven for missing that it’s an OSS project, since there’s a "pricing" option and the title of the front page is "SeaweedFS Enterprise" (and no GitHub link that I could find!). Zenko CloudServer 🔗 💾 Example Docker Compose Version tested: 9.2.8 ✅ Docker image (also outdated ones on Docker Hub with 5M+ pulls) ✅ Licence: Apache 2.0 ✅ S3 compatibility Ease of config: 👍 Formerly known as S3 Server, CloudServer is part of a toolset called Zenko, published by Scality. Garage 🔗 💾 Example Docker Compose Ease of config: 😵 Version tested: 1.0.0 ✅ Docker image (1M+ pulls) ✅ Licence: AGPL ✅ S3 compatibility I had to get a friend to help me with this one. Could I have sat down and RTFM’d to figure it out myself? Yes. So, Garage does work, but gosh…it is not just a drop-in replacement in terms of code changes. Is this an entirely fair assessment? Apache Ozone 🔗 💾 Example Docker Compose Version tested: 2.1.0 ✅ Docker images (1M+ pulls) ✅ Licence: Apache 2.0 ✅ S3 compatibility Ozone was spun out of Apache Hadoop (remember that?) in 2020, having been initially created as part of the HDFS project back in 2015. Ease of config: 😵 It does work as a replacement for MinIO, but it is not a lightweight alternative; neither I nor Claude could figure out how to deploy it with any fewer than four nodes. Ceph Object Gateway 🔗 I took one look at the installation instructions and noped right out of this one! Ozone (above) is heavyweight enough; I’m sure both are great at what they do, but they are not a lightweight container to slot into my Docker Compose stack for local demos. Comparison 🔗 Everyone loves a bake-off chart, right? Name gaul/s3proxy RustFS SeaweedFS Zenko CloudServer (Git repo) Garage Apache Ozone 1 Docker pulls is a useful signal but not an absolute one given that a small number of downstream projects using the image in a frequently-run CI/CD pipeline could easily distort this figure. Summary 🔗 I got side-tracked into writing this blog because I wanted to update a demo in which currently MinIO was used. SeaweedFS - yes. S3Proxy - yes. RustFS - maybe, but very new project & alpha release. CloudServer - yes, maybe? Honestly, put off by it being part of a suite and worrying I’d need to understand other bits of it to use it—probably unfounded though. Garage - no, config too complex for what I need. Apache Ozone - lol no. I mean to cast no shade on those options against which I’ve not recorded a yes; they’re probably excellent projects, but just not focussed on my primary use case (simple & easy to configure single-node local S3). A few parting considerations to bear in mind when choosing a replacement for MinIO: Governance. Whilst all the projects are OSS, only Ozone is owned by a foundation (ASF). All the others could, in theory, change their licence at the drop of a hat (just like MinIO did). Community health. What’s the "bus factor"? A couple of the projects above have a very long and healthy history—but from a single contributor. If they were to abandon the project, would someone in the community fork and continue to actively develop it? Addendum 🔗 2026-01-30: Justin Cormack has written about some of the implementation details and functionality of RustFS and Garage 2026-03-02: Ruohang Feng has forked MinIO to pgsty/minio and is promising to maintain a stable, CVE-patched, distribution. On this page MinIO baseline S3Proxy Comparison © 2026 |
The author investigates alternatives to MinIO for single-node local S3 storage, focusing narrowly on scenarios where S3 emulation is used for local development demos, emphasizing simplicity, ease of Docker deployment, S3 compatibility, open-source licensing, and good developer experience. The baseline setup demonstrated involves a Docker Compose stack utilizing DuckDB, Apache Iceberg, MinIO for local storage, and the mc utility for management, which serves as a reference for this evaluation. The alternatives examined include S3Proxy, RustFS, SeaweedFS, Zenko CloudServer, Garage, Apache Ozone, and Ceph Object Gateway. All options are assessed based on how seamlessly they can replace MinIO in a local, single-node context without introducing unnecessary complexity. S3Proxy is presented as a lightweight option with strong S3 compatibility and an Apache 2.0 license, boasting excellent ease of configuration, although the author notes that some underlying components may have recently been retired. RustFS also meets the criteria for S3 compatibility and an Apache 2.0 license, but the author flags that it is in an alpha release and has recently experienced security vulnerabilities, making it a riskier choice despite its potential. SeaweedFS offers S3 compatibility and an Apache 2.0 license, and it includes its own user interface, positioning it as a viable, established alternative that simplifies configuration, although it does require configuration handling, which the project team is working to streamline. Zenko CloudServer, formerly known as S3 Server, is also compatible with S3 and licensed under Apache 2.0, being part of the Zenko toolset published by Scality. Garage, while S3 compatible, is assessed as being overly complex for the stated requirement, necessitating complex plumbing for initialization, and features an AGPL license. For more heavyweight solutions, Apache Ozone and Ceph Object Gateway are discussed. Apache Ozone is noted as being significantly heavier, possessing characteristics reminiscent of Hadoop, and is difficult to deploy with minimal nodes, suggesting it is not suitable for the lightweight local demo context. This distinction leads to the conclusion that while options like Apache Ozone and Ceph Object Gateway are powerful, they are not lightweight alternatives for the intended single-node, local S3 experience. In a comparative summary, the author ultimately favors SeaweedFS and S3Proxy as practical replacements. RustFS is considered a possibility, though its current status as an alpha release warrants caution. Alternatives like Garage and Apache Ozone are deemed unsuitable due to excessive configuration complexity or resource overhead, respectively. The author further emphasizes the importance of governance and community health when selecting a replacement, noting that while many projects are open source, licensing terms and long-term community support present important considerations. |