In late 2025 the company behind MinIO decided to abandon it to pursue other commercial interests. As well as upsetting a bunch of folk, it also put the cat amongst the pigeons of many software demos that relied on MinIO to emulate S3 storage locally, not to mention build pipelines that used it for validating S3 compatibility.
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. In practice that means the following:
-
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. Several of the tools discussed below have a wide range of features, S3 support being just one of them. Others offer S3 alone and that’s it. For my purposes either is fine, so long as any additional features and support don’t add to the complexity or weight of deployment. |
What I’m not looking at is, for example, multi-node deployments, distributed storage, production support costs, GUI capabilities, and so on. That is, this blog post is not aimed at folk who were using MinIO as self-managed S3 in production. Feel free to leave a comment below though if you have useful things to add in this respect :)
| 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
(1, 'Widget', 9.99),
(2, 'Gadget', 19.99),
(3, 'Doohickey', 14.99);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
[2026-01-12 14:35:55 UTC] 2.7KiB STANDARD 188ee032-8576-4f46-9834-1cac6d3080a3-m0.avro
[2026-01-12 14:35:55 UTC] 1.6KiB STANDARD snap-2633370813252912097-95ad4df0-3243-4cfb-a736-8f785aac100c.avroIn each of the samples I’ve built you can run the test.sh to verify it.
❯ ./test.sh
░▒▓██████████████████████████████████████████████████▓▒░
▒ ▒
▓ ___ ▓▓▓▓▓ ▓
█ ___( o)> ┌───────────┐ ▓▓▓▓▓▓▓ ▒▒▒▒▒▒▒ █
█ \ <_. ) │ DUCKDB │ ▓░Local S3 ░▓ ▒▒▒▒ █
█ --- └───────────┘ ▓▓ MinIO ▒▒▒ █
▓ ┏━━━━━━━━━━━━━┓ ░░░ ▓
▒ ≋≋≋≋≋≋≋ ┃ ICEBERG ┃ ≋≋≋≋≋≋≋≋ Smoke test ▒
░ ≋≋≋≋≋≋≋ ┗━━━━━━━━━━━━━┛ ≋≋≋≋≋≋≋≋ ░
░▒▓██████████████████████████████████████████████████▓▒░
1. Checking MinIO buckets (before)...
[2026-01-14 12:48:41 UTC] 0B warehouse/
2. Creating Iceberg table and inserting data...
[…]
3. Verifying data in DuckDB...
[…]
┌───────┬───────────┬───────────────┐
│ id │ name │ price │
│ int32 │ varchar │ decimal(10,2) │
├───────┼───────────┼───────────────┤
│ 1 │ Widget │ 9.99 │
│ 2 │ Gadget │ 19.99 │
│ 3 │ Doohickey │ 14.99 │
└───────┴───────────┴───────────────┘
4. Checking MinIO bucket contents (after)...
[2026-01-14 12:49:07 UTC] 493B STANDARD data/019bbc8d-7d44-7b6b-af71-0ab99d3a0124.parquet
[2026-01-14 12:49:07 UTC] 2.7KiB STANDARD data/c37ab68c-8aaf-44a4-88e6-bc02a01daf5c-m0.avro
[2026-01-14 12:49:07 UTC] 1.6KiB STANDARD data/snap-1988745121468861337-95e77212-9571-423f-bb71-ce8f1b4282f0.avro
[2026-01-14 12:49:07 UTC] 1.0KiB STANDARD metadata/00000-8bf22118-d262-47a9-986c-721d2b99a846.metadata.json
[2026-01-14 12:49:07 UTC] 1.7KiB STANDARD metadata/00001-5cad6fc5-fe54-41bc-8131-4d6f900d20e7.metadata.jsonMinIO 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.
I’ve left the MinIO S3 client, mc in place since that’s no big deal to replace if you want to rip out MinIO completely (s3cmd, aws CLI, etc etc).
S3Proxy 🔗
Version tested: 3.0.0
-
✅ Docker image (5M+ pulls)
-
✅ Licence: Apache 2.0
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 🔗
Version tested: 1.0.0-alpha.79
Ease of config: ✅✅
-
✅ Docker image (100k+ pulls)
-
✅ Licence: Apache 2.0
| Be aware that there was recently a pretty bad security vuln found in RustFS, which has put some people off from using it. The website looks pretty smart but several links resolve to the same page, giving it that "fresh paint" smell of a new project :) This might matter less for demos, if it’s easy to switch out. You’ll also note that the project is currently only 'alpha' release. |
RustFS also includes a GUI:
SeaweedFS 🔗
Version tested: 4.06
-
✅ Docker image (5M+ pulls)
-
✅ Licence: Apache 2.0
Ease of config: 👍
This quickstart is useful for getting bare-minimum S3 functionality working. (That said, I still just got Claude to do the implementation…). Overall there’s not too much to change here; a fairly straightforward switchout of Docker images, but the auth does need its own config file (which as with Garage, I inlined in the Docker Compose).
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!). But an OSS project it is, and a long-established one: SeaweedFS has been around with S3 support since its 0.91 release in 2018. You can also learn more about SeaweedFS from these slides, including a comparison chart with MinIO.
Zenko CloudServer 🔗
Version tested: 9.2.8
-
✅ Docker image (also outdated ones on Docker Hub with 5M+ pulls)
-
✅ Licence: Apache 2.0
Ease of config: 👍
Formerly known as S3 Server, CloudServer is part of a toolset called Zenko, published by Scality. It drops in to replace MinIO pretty easily, but I did find it slightly tricky at first to disentangle the set of names (cloudserver/zenko/scality) and what the actual software I needed to run was. There’s also a slightly odd feel that the docs link to an outdated Docker image.
Garage 🔗
Ease of config: 😵
Version tested: 1.0.0
-
✅ Docker image (1M+ pulls)
-
✅ Licence: AGPL
I had to get a friend to help me with this one.
As well as the garage container, I needed another to do the initial configuration, as well as a TOML config file which I’ve inlined in the Docker Compose to keep things concise.
Could I have sat down and RTFM’d to figure it out myself? Yes. Do I have better things to do with my time? Also, yes.
So, Garage does work, but gosh…it is not just a drop-in replacement in terms of code changes.
It requires different plumbing for initialisation, and it’s not simple at that either.
A simple example: The specified key ID is not a valid Garage key ID (starts with GK, followed by 12 hex-encoded bytes).
Excellent for production hygiene…overkill for local demos, and in fact somewhat of a hindrance TBH.
| Is this an entirely fair assessment? If I were looking at it as a new piece of technology in its own right, completely not! Many pieces of excellent technology, particularly those that can support running distributed, will have a steep learning curve for configuration. However, my requirement here is a simple drop-in replacement for MinIO—which Garage is not. |
Apache Ozone 🔗
Version tested: 2.1.0
-
✅ Docker images (1M+ pulls)
-
✅ Licence: Apache 2.0
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. It gives heavy Hadoop vibes, and I wouldn’t be rushing to adopt it for my use case here.
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 | Ease of config | Licence | Commercial Backing & Governance | Docker pulls1 | GH Stars | Date of first commit | Significant Committers |
|---|---|---|---|---|---|---|---|
|
(Git repo) |
👍👍 |
Apache 2.0 |
Single contributor (Andrew Gaul) |
2014 |
|||
|
(Git repo) |
👍👍 |
Apache 2.0 |
2024 |
||||
|
(Git repo) |
👍 |
Apache 2.0 |
Single contributor (Chris Lu), Enterprise option available |
2012 |
|||
👍 |
Apache 2.0 |
Scality (commercial company) |
5M+ (outdated version) |
2015 |
|||
|
(Git repo) |
😬 |
AGPL |
NGI/NLnet grants |
2020 |
|||
|
(Git repo) |
lol |
Apache 2.0 |
Apache Software Foundation |
2018 |
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. So, having tried them out, which of the options will I actually use?
-
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?
