MinIO 社区版是这样落幕的 — 用仓库记录复原的时间线，以及 Garage、SeaweedFS、Ceph RGW 的现状

引言 — 「默认选项」是怎么变成只读的
时间线 — 仓库自己留下的记录
什么变了，什么没变
替代方案的实际状态 — 截至2026年7月
那么，如果你现在还在用 MinIO
结语
参考资料

引言 — 「默认选项」是怎么变成只读的

本博客的2026年5月分布式存储梳理一文，把 MinIO 称为「事实上的 S3 协议参考实现」。那还是本地部署需要 S3 兼容存储时，随手装一个 MinIO 就开工的默认年代的说法。那篇文章发出去两个月后的今天，minio/minio 仓库已经处于归档(只读)状态。GitHub 的横幅文案原话是「archived by the owner on Apr 25, 2026」，而就在三天前，2026年7月14日，mc 客户端仓库也被归档了。

这件事激起的愤怒帖子有多少，不准确的总结就有多少。「改了许可证」(没有)、「代码转成私有了」(是归档状态但依然公开)之类的说法到处流传。所以本文追的不是舆论，而是记录 — 所有论点的依据都来自仓库自身的提交记录、发布说明、镜像仓库元数据和官方博客，社区反应也只作为反应来引用链接。后半部分会梳理真正的替代方案 Garage、SeaweedFS、Ceph RGW 截至2026年7月的实际状态，以及如果你现在还在跑 MinIO，手头有哪些选择。

时间线 — 仓库自己留下的记录

时间点	发生了什么	一手依据
2025-05-24	内嵌控制台被削减，移除 LDAP/OIDC 登录	发布说明
2025-09-07	Docker Hub 最后一次镜像更新	镜像仓库标签记录
2025-10-15	最后一次发布 + 「仅源码分发」声明	发布、提交 9e49d5e7a6
2025-10-16	高危漏洞 CVE-2025-62506 公开(修复仅收录于上述发布)	GHSA-jjjj-jwhf-8rgr
2025-12-03	README 声明进入「维护模式」	提交 27742d4694
2026-01-06	README 被替换成 AIStor Free/Enterprise 的说明	提交 be7800c813
2026-02-12	「THIS REPOSITORY IS NO LONGER MAINTAINED.」	提交 7aac2a2c5b
2026-03-20	minio/operator 被归档	仓库横幅
2026-04-25	minio/minio 被归档	仓库横幅
2026-07-14	minio/mc 被归档	仓库横幅

下面逐条来看。

2025年5月 — 管理功能从控制台中消失

RELEASE.2025-05-24T17-08-30Z 发布说明写明内嵌 UI 控制台已被弃用，转移到 object-browser 仓库，关于移除 LDAP/OIDC 外部 IdP 登录，它是这样写的 — 「these are now available as part of the AiStor Product.」也就是说，社区版二进制的 Web UI，从一个管理控制台缩水成了单纯的对象浏览器，而被移除功能的去向，正是发布说明自己点明的商业产品。同一份说明还建议付费客户升级到 AiStor。

反应完全在意料之中 — 当时的 HN 讨论帖(176 分)，以及第二天，也就是5月25日创建的控制台 UI 分支 OpenMaxIO，收获了大约 1,900 颗星。不过这个分支的最后一次 push 停在了2025年6月24日(以 GitHub API 为准，查询于 2026-07-17)。停滞超过一年，也没有任何发布。这也是一份数据，说明「宣布分叉」和「维护分叉」是两码事。再补充一点，发布说明当时指向的控制台新去处 minio/object-browser 仓库，截至今天已经是 404 — 已从公开仓库列表里消失。

2025年9~10月 — 镜像停更，最后一次发布落地

按镜像仓库元数据，Docker Hub 上的 minio/minio最后一次更新是2025年9月7日(标签 RELEASE.2025-09-07T16-13-09Z)。latest 标签也从那天起就没再动过。顺带一提，按 Docker Hub API，这个镜像的累计拉取次数大约是18亿次 — 由此可以感受到，停更的是一个多大规模的分发渠道。HN 讨论帖(733 分)记录了当时的反应。

2025年10月15日的RELEASE.2025-10-15T17-29-55Z，成了这个仓库的最后一次发布。同一天，README 提交 9e49d5e7a6宣布社区版此后「distributed as source code only」，并且对现有二进制文件明确表示「These legacy binaries will not receive updates.」最后一份发布说明给出的安装方法，本身就概括了新的分发模式。

# RELEASE.2025-10-15T17-29-55Z 发布说明给出的安装方法
go install -v github.com/minio/minio@RELEASE.2025-10-15T17-29-55Z

# 容器现在要自己构建
git clone https://github.com/minio/minio
cd minio && git checkout RELEASE.2025-10-15T17-29-55Z
TAG=myregistry.com/minio/minio:RELEASE.2025-10-15T17-29-55Z make docker

CVE-2025-62506 — 停止分发真正开始疼的地方

这最后一次发布并不只是一次收尾发布。它包含了 CVE-2025-62506 的修复，即公开编号为 GHSA-jjjj-jwhf-8rgr 的漏洞 — 通过服务账户、STS 的会话策略绕过实现权限提升，严重程度为高危。按公告口径，受影响范围是2025-10-15修复提交之前的所有版本。

到这里，停止分发的实际含义才真正清晰起来。

Docker Hub 的官方镜像早在五周前(9月7日)就已停更，所以 包含这个修复的官方公开镜像根本不存在。quay.io 那边也没有对应的发布标签(查询标签结果为空)。
直到2026年4月，quay.io 那边还偶尔会出现旧版本的 hotfix 标签。但比如说，2026-04-01 上传的那个 hotfix 标签，指向的提交 7aa24e772 在公开仓库里根本不存在(GitHub API 找不到这个 SHA)。也就是说，这是一个在公开代码树之外构建出来的镜像，社区没有办法用源码去核对它的内容。
结论是，对当初靠拉取镜像来用的用户来说，修补这个高危漏洞的官方途径只有一条 — 「自己从源码构建」。

「不再提供二进制文件」这句话听起来很抽象，但「公开的权限提升漏洞的修复不会以镜像形式抵达你」这句话就一点也不抽象了。这件事，正是让10月那次转折真正变得可感的实例。

2025年12月 ~ 2026年7月 — 从维护模式到归档连锁反应

12月3日的README 提交宣布项目进入维护模式，不再接受新功能、改进和 PR，只有致命的安全修复可能会被逐个审查(HN 511 分)。1月6日的提交在那个位置放上了 AIStor Free 和 AIStor Enterprise 的说明，2月12日的提交把横幅精简成了一句话 — 「THIS REPOSITORY IS NO LONGER MAINTAINED.」(HN 500 分)

之后归档接连而来。面向 Kubernetes 的 minio/operator在2026年3月20日，服务器本体 minio/minio在4月25日，命令行工具 minio/mc在7月14日。相比之下，minio-go、minio-py、minio-js 这类 SDK 仓库，截至本文写作时仍在活跃更新(minio-js 昨天还有 push) — AIStor 的客户同样需要 S3 客户端 SDK，所以产品边界到底划在哪儿，这个归档模式本身已经说得很清楚了。

什么变了，什么没变

把这件事记成一次「许可证 rug pull」是不准确的。按记录来梳理，是这样的。

没变的 — 许可证。 minio/minio 从头到尾都是 AGPLv3。仓库元数据、README、LICENSE 文件都没有变。不存在转向 BSL 或 SSPL 这回事。归档后的代码，如今依然可以在 AGPLv3 之下被任何人取走。

变了的 — 依次是四件事。 (1) 功能：社区版二进制中的管理控制台和外部 IdP 登录消失了(2025-05)。(2) 分发：官方二进制文件和容器镜像的提供结束了(2025-09~10)。(3) 维护：不再接受 PR 和 issue 了(2025-12)。(4) 仓库本身：变成了只读(2026-03~07，连锁归档)。

被拿出来当替代品的 — AIStor Free。 根据MinIO 的订阅层级公告，AIStor Free 仅限单节点，单节点容量没有上限，是免费的，但许可证限制再分发和转售(下载需要免费许可证密钥 — 以已归档 README 的说明为准)。多节点分布式配置从 Enterprise Lite 起步，按公告口径，超过 400 TiB 会自动转到 Enterprise。总之，AIStor Free 是一个「免费的、闭源的单节点产品」。它不是开源 MinIO 的后继者，而是另一个东西，也应该按另一个东西来评价。

没发生的 — 一次成功的服务器分叉。 HashiCorp Vault 转换许可证时，OpenBao 在基金会名下分叉出来并存活了下来。而截至本文写作时，MinIO 还没有出现这样的分叉。控制台 UI 分叉(OpenMaxIO)如上所述已经停滞，也没有确认到哪个分叉接手了服务器本体并获得了发展势头。社区评论(例如《MinIO Is Dead, Long Live MinIO》)也大多建议迁移到替代方案，而不是去分叉。在 AGPL、单一供应商 CLA 这种结构下，没有基金会背书，没有任何一方愿意接手一个大型 Go 代码库 — 这是这件事悄悄留下的教训之一。

替代方案的实际状态 — 截至2026年7月

S3 API 是事实上的可移植层，这一点在这种时刻最能体现价值。应用代码大多只需要换一下端点和凭证。问题在于，三个替代方案在服务端的运维特性上，都和 MinIO 相差不小。

Garage — 依然是最轻的那一档，如今还在争取迁移用户

Garage 是法国 Deuxfleurs 开发的一款 Rust 编写、轻量、地理分布式的 S3 存储，许可证是 AGPLv3(已在仓库 LICENSE 中确认)。看发布记录(以它自己的 Gitea 为准)：v2.0.0 发布于 2025-06-14 — 管理 API 全面改版(v2 端点)，把 replication_mode 拆成 replication_factor 和 consistency_mode 是个破坏性变更 — 之后 v2.2.0 和维护中的 v1 线上的 v1.3.1 在 2026-01-24 同时发布，最新的 v2.3.0 发布于 2026-04-16。

v2.3.0 的方向很能说明问题。它加入了 garage server --single-node 选项，可以立刻拉起一个单节点集群，还带了通过环境变量创建默认访问密钥和存储桶的引导流程，用发布说明自己的话说，是放宽了导入(imported)访问密钥的要求，专门为了方便从其他 S3 存储供应商迁移过来。这明显是冲着那批「在空文件夹里跑一个 minio server」起家的用户去的变化。

局限也写在设计文档里。官方 goals 文档明确说它不做纠删码，只做复制(duplication) — 意味着三副本复制就是三倍的存储开销。不打算添加超出 S3 API 范围的功能，也是一条明确的 non-goal。项目的规模也得考虑进去 — 按官网自己的资金说明，2025年的经费规模大约是 NLnet/NGI0 资助下的 1.5 个全职人力。对家庭实验室、小型组织、小容量的地理分布场景来说，这是个很好的靶子；对高密度、大容量的单数据中心存储来说，从设计上就不合适。

SeaweedFS — 三者中最活跃，也最依赖一个人

SeaweedFS 采用 Apache-2.0 许可证(星标约 3.3 万个)，发布节奏是三者中最快的 — 4.00 发布于 2025-11-03，此后每周都有更新，截至本文写作时最新版本是 4.39(2026-07-10)。光是 4.00 的发布说明里，就列了一长串 S3 表面的改进，比如 S3 IAM 配置文件支持。

它的架构不是 MinIO 那种单一二进制。按 README 的说法，核心是一个 blob 存储：中心 master 只负责卷的分布，元数据分散在各个 volume server 上；在此之上是一个独立的无状态服务器 Filer，负责加上目录和 POSIX 属性；S3 API 则是再往上一层的网关。纠删码也已经实现(README 里明确写了)。也就是说，它在大量小文件的工作负载上有真本事，代价是运维方需要理解的守护进程种类比 MinIO 多。

要坦诚指出的风险是集中度。按 GitHub contributors API，创始人 chrislusf 的提交数是 9,968 次，排除机器人后的第二名(530 次)跟他不在一个数量级上。这不代表项目在走向死亡 — 恰恰相反，它现在是三者中最活跃的 — 而是说明「巴士系数」的担忧是站得住脚的。如果你正是因为在 MinIO 上体会过单一供应商风险才要迁移，这一点值得权衡。

Ceph RGW — 分量重，但治理结构不一样

Ceph 的 RADOS Gateway(RGW)是 S3 兼容存储里经受时间检验最久的那一档之一。当前的稳定发布版是 Tentacle(v20.2.0，2025-11-18 GA)，截至本文写作时已经出到 20.2.2，Squid(19.2.5)、Reef(18.2.8)也在并行支持中。Tentacle 的发布公告在仪表盘改进部分列出了 RGW 多站点自动化、分层(tiering)、生命周期、通知、精细化复制 — 这是 RGW 运维层面持续在被打磨的信号。

权衡取舍还是那个众所周知的样子。哪怕你只需要 RGW，整个 Ceph 集群(mon、mgr、OSD)也会一起打包过来。cephadm 大大降低了安装门槛，但它依然是「有存储团队的组织」用的工具，而不是家庭实验室的工具。作为交换，它有一个和这次事件正好形成对照的优势 — Ceph 是一个由 Linux Foundation 旗下 Ceph Foundation 负责治理的多供应商项目，因为一家公司业务转型而导致分发中断的这类风险，在结构上就比较低。

其他

也有 RustFS 这样用 Rust 重写 S3 存储的新玩家(Apache-2.0，星标约 3 万个，截至 2026-07-17 确认当天有 push)。不过数据的耐久性是要靠时间而不是星标数来证明的属性 — 在把生产数据搬过去之前，请各自核实其过往记录。

那么，如果你现在还在用 MinIO

选择有四个。四个都有代价，「什么都不做」也是有代价的。

靠停更的二进制文件硬撑。 这意味着决定继续跑一份自2025-10-15起就没再打过补丁的软件。正如 CVE-2025-62506 所展示的，下一个漏洞的修复不会以镜像形式抵达你。只有在完全没有外部暴露的隔离环境中、并且设了明确期限的前提下，才说得过去。
靠源码构建来维持。 由于归档后的仓库不接受 PR，这条路径实质上就是自己维护一个私有分叉。Go 工具链和构建流水线，以及未来漏洞的回移(backport)判断，都得自己扛。
迁到 AIStor Free。 如果单节点就够用，而且你所在的环境能接受闭源许可证密钥，老实说这是摩擦最小的一条路。一旦需要分布式高可用，就进入付费区间了(Enterprise Lite，400 TiB 是分界线)。
迁移出去。 应用这一侧，得益于 S3 兼容性，大多只是换个端点的事，但数据本身的搬迁，以及 IAM 策略、生命周期规则的转译，是另一份独立的工作(mc 也被归档了，所以搬数据用 rclone 这类中立工具更稳妥)。方向如上文所述 — 家庭实验室、小规模、地理分布优先选 Garage；小文件量大、能接受快速发布节奏就选 SeaweedFS；看重组织规模和长期治理就选 Ceph RGW，这是默认的映射关系。

如果你在 Kubernetes 上的部署是搭在 minio/operator 之上的，这条线也得一并规划 — operator 仓库已于2026年3月20日被归档。

最后归纳一句。这件事的教训不是「MinIO 做得不好」，而是对一个老道理的再次确认 — 由单一供应商掌握 CLA 的开源基础设施，那家供应商的业务转型就直接决定了项目的命运。 在存储这种数据会物理性地落地扎根的层面上，这种风险会直接转化成迁移成本。挑选下一个依赖项时，请在功能表之外，也一并看看治理结构 — 是不是基金会所有，贡献者是否分散，规模是否真的达到了分叉可行的程度。

结语

只重新总结记录能核实的部分。MinIO 社区版是按这个顺序落幕的：2025年5月功能削减，9~10月停止分发(最后一次镜像9月7日，最后一次发布10月15日)，12月进入维护模式，2026年3~7月仓库连锁归档。许可证自始至终都是 AGPLv3，而转型的成本，以「高危 CVE 的修复始终没有通过官方公开镜像分发」这种具体形式，转嫁给了用户。官方后继产品 AIStor Free 虽然免费，但是一个仅限单节点的闭源产品。

替代方案在成熟度和性格上各不相同 — Garage 用小而清晰的设计(仅复制、不做超出 S3 的事)覆盖小规模、地理分布场景；SeaweedFS 提供快速的开发节奏和小文件优势(代价是创始人高度集中)；Ceph RGW 以运维分量为代价，换来基金会治理和经过验证的长寿命。没有哪一个是完全的后继者。这是这次梳理诚实的结论，所以最终的选择不该由基准测试决定，而应该由你的规模、团队和风险承受能力来决定。