MinIO 停更后本地 S3 存储该换谁：7 个候选方案的实测结果与避坑点

原文来源：rmoff.net — 一位数据工程师把本地 S3 存储从 MinIO 逐个换成 7 个候选方案，实测配置难度并给出选型建议。

为什么要换

2025 年底，MinIO 背后的公司决定放弃这个项目，转去做别的商业方向。这件事的波及面比想象中大：大量软件演示靠 MinIO 在本地模拟 S3，很多构建流水线靠它验证 S3 兼容性。这些环境一夜之间失去了维护者。

作者 Robin Moffatt 的需求很具体，也很典型——他只想给本地 demo 找一个最简单的替代品。筛选条件是：

• 必须有 Docker 镜像。演示大多以 Docker Compose 形式分发，没人愿意自己构建镜像。
• 必须提供 S3 兼容。用 MinIO 的全部意义就是替代真实 S3 写入。
• 必须免费，强烈偏好开源许可证（Apache 2.0 这类）。
• 单节点部署要简单。
• 社区或商业后盾要清晰活跃。作者的原话是："谁都能 vibe-code 出一坨无人维护的代码，或者一时兴起 fork 一个项目——但 MinIO 一直是那根定海神针，我们不想半年后再来一遍这套流程。"
• 开发体验好、配置顺滑、文档齐全可以额外加分。

要说清楚的是，他看的是"单机本地 S3"这个场景，不涉及多节点、分布式存储、生产支持成本、图形界面这些。拿 MinIO 当生产环境自管 S3 的读者，这篇的结论不能直接套用。

测试基线长什么样

原始栈是一个很简单的 Docker Compose：DuckDB 负责读写 Iceberg 数据，Iceberg REST Catalog 做元数据，MinIO 提供 S3 存储，mc（MinIO 的 CLI）负责自动创建 bucket。

验证方式也很直接。往 DuckDB 里插入三行数据：

INSERT INTO cat.test.products VALUES
(1, 'Widget', 9.99), (2, 'Gadget', 19.99), (3, 'Doohickey', 14.99);

数据就会以 Iceberg 格式落到 S3 上，用 mc ls 能看到 parquet 和 avro 文件。每个替代方案都配了一个 test.sh，跑一遍就能确认"写入是否真的落到了对象存储里"，而且能看到具体文件名和大小。这套"先建立可验证基线、再逐个替换"的做法，值得抄。

七个候选，逐个说

S3Proxy —— 最难的地方是它太老了

版本 3.0.0，Apache 2.0，Docker Hub 500 万次以上拉取，GitHub 2100 颗星。

配置难度：非常容易。 作者给的是双赞，几乎是最轻量的选择。

要注意的坑：它依赖的 jclouds 项目在 2025 年中进了 Apache Attic（也就是退役）。如果你只用本地存储，作者认为影响不大——但这是个需要自己判断的长期风险。整个项目基本是单人维护，第一次提交在 2014 年。

RustFS —— 快但是太新

版本 1.0.0-alpha.79，Apache 2.0，10 万次以上拉取，GitHub 1.97 万颗星（涨得很猛）。

配置难度：容易。 自带图形界面。

坑在哪：前不久爆出一个挺严重的安全漏洞，劝退了一批人；项目还处于 alpha 阶段；网站做得很漂亮，但好几个链接指向同一个页面，透出一股"刚刷完漆"的味道。做本地 demo 影响没那么大，反正换掉也容易。

SeaweedFS —— 本次的实际选择

版本 4.06，Apache 2.0，GitHub 2.95 万颗星，500 万次以上拉取。它从 2018 年的 0.91 版本开始就支持 S3。

配置难度：容易。 快速上手文档够用，主要的改动就是换 Docker 镜像；认证需要一份自己的配置文件，作者直接内联进了 Compose。他发完文章后项目方还回复说会去掉这个额外要求，下周的版本就会带上——这个响应速度本身就是加分项。

还有个问题：官网信息稀少，还带一个"pricing"入口，首页标题写着 SeaweedFS Enterprise，甚至找不到 GitHub 链接——第一次看很容易误判成商业软件。另外核心贡献者基本只有一个人。

Zenko CloudServer —— 名字比配置难

版本 9.2.8，Apache 2.0，GitHub 1900 颗星。以前叫 S3 Server，属于 Scality 的 Zenko 工具集。

配置难度：容易。 替换 MinIO 挺顺。真正的门槛在辨认它到底是哪个东西——cloudserver、zenko、scality 三个名字混在一起，作者花了一点时间才理清自己要跑的是哪个。另一个别扭之处是官方文档指向的 Docker 镜像已经过时。商业公司背书，维护者约 10 人。

Garage —— 能用，但完全不是"替换"

版本 1.0.0，AGPL 许可，GitHub 2500 颗星，由 NGI/NLnet 资助。

配置难度：很难。 作者直说这个是他找朋友帮忙才搞定的。除了 garage 容器，还需要另一个容器做初始化配置，加一份 TOML 配置文件。最典型的一道坎是 key ID 校验：必须以 GK 开头，后面跟 12 位十六进制字符——"生产环境的卫生标准是到位了，但对本地演示来说纯属负担"。

作者特意补了一句公道话：如果把它当成一项新技术来评估，这个评价完全不公平——能支撑分布式运行的系统，配置学习曲线陡是正常的。问题在于他的需求是"MinIO 的即插即用替代"，而 Garage 不是。

Apache Ozone —— 四节点起步

版本 2.1.0，Apache 2.0，GitHub 1100 颗星。2015 年作为 HDFS 的一部分诞生，2020 年从 Hadoop 拆出来独立（对比表最后一列“仓库首提交”是代码仓库的首次提交，与项目诞生年份不是同一口径）。

配置难度：很难。 它确实能当 MinIO 的替代品，但一点也不轻量——作者和 Claude 都没能想出四节点以下的部署方式。"浑身散发着 Hadoop 的气息"，不适合他这个场景。优点是治理最正规：唯一一个由基金会（Apache 软件基金会）持有的项目，贡献者 30 人以上。

Ceph Object Gateway —— 直接放弃

作者看了一眼安装说明就退出了。Ozone 已经够重了，Ceph 显然不是能塞进本地演示 Compose 栈里的轻量容器。

横向对比表

拉取量是个有用但不绝对的信号：少数下游项目把它放进高频 CI 流水线，就能把这个数字显著拉高。

作者的最终选择

• SeaweedFS：用。
• S3Proxy：用。
• RustFS：大概会用，但项目太新、还是 alpha。
• CloudServer：可能用，介意它属于一套更大的工具集。
• Garage：不用，配置对一个本地演示来说过于复杂。
• Apache Ozone：不用。

他还留了两条选型时的通用考量：治理——所有项目都开源，但只有 Ozone 归属基金会，其余理论上都能像 MinIO 那样随时改许可证；社区健康度——巴士系数（bus factor）是多少？有几个项目历史悠久很健康，但只有一个贡献者，一旦他放弃，社区里会不会有人 fork 并继续维护？

两个后续更新

2026 年 1 月 30 日，Justin Cormack 撰文分析了 RustFS 和 Garage 的实现细节与功能。

2026 年 3 月 2 日，Ruohang Feng 把 MinIO fork 成了 pgsty/minio，承诺维护一个稳定、持续打 CVE 补丁的分发版本。

如果你手里的 MinIO 演示环境还没动，现在至少有两条路：换掉它，或者等这个 fork。考虑到 MinIO 当年也是从"轻量、好上手"起家的，第二种选择未必不划算——只是这次你得自己盯许可证和补丁节奏了。