文章

• 续命 MinIO：承诺兑现
• MinIO 已死，MinIO 复生
• MinIO已死，谁能接盘？
• MinIO已死

续命 MinIO：承诺兑现

两个月前，我在《MinIO 已死，MinIO 复生》里立了一个 flag，承接上游的烂摊子，跟 CVE、修 Bug。 那篇文章上了几个小时的 Hacker News 头条。鼓励不少，质疑也不少：一个人，真维护得了这种项目吗？

这个问题其实问得很好。因为真正见真章的时刻，不是点 fork 按钮，也不是改 README 文档，而是当安全漏洞真砸下来的时候。

现在，这件事可以交账了。

4 月 15 日到 17 日，三天时间，pgsty/minio 发布了 RELEASE.2026-04-17，连续修掉并关闭了 4 条 CVE 加几条同期披露的安全漏洞，OIDC JWT 算法混淆（CVSS 9.8）、LDAP 登录用户名枚举与暴力破解、复制头元数据注入导致对象不可读、S3 Select 超大记录打穿内存，以及两条 unsigned-trailer 写入路径上的签名绕过。

A promise made, a promise kept.

当时我把话说得很清楚：不做新特性，只保障供应链；遇到可复现问题和安全漏洞，会积极跟进和修补。这件事，现在算是交账了。

上游发生了什么

2025 年 12 月，MinIO 把开源仓库改成 维护模式。README 里写着 “安全修复会逐例评估”。 到 2026 年 2 月，仓库直接归档，首页变成了 “当前仓库已经不再维护”。但同一个仓库的 SECURITY.md 还留着：“我们总会为最新版本提供安全更新”。

而最近一个月，MinIO 又暴漏出四个高危漏洞，两个中危，覆盖最后的开源版本。

与此同时，上游官方仓库距离最后一次发布已经过去 184 天。 他们披露漏洞，但只在商业版本中修复。对于开源版用户，他们给的建议就一条，“升级到商业版 AIStor”。

顺便一提，MinIO 入门起步价约 10 万美元/年，400 TiB，单价基本跟 AWS S3 差不多，简直离大谱，毕竟这是纯软件。

一种很精致的玩法。仓库归档了，道义责任撇清了；但 CVE 通告照发，既能刷一波 “我们很负责任” 的存在感，又恰好能把用户赶进商业版的羊圈。

挺聪明的。只是还得有人得把这坑填上。

这次修了什么

这篇文章我不想写成漏洞分析报告。具体每一条的 CVSS 分数、攻击链、PoC 代码，我在 发布注记 里都一一列了，感兴趣的朋友可以去看。这里只说一句话版本：

• CVE-2026-33322（OIDC JWT 算法混淆，CVSS 9.8）：在特定 IdP 配置下可以伪造任意身份，包括 consoleAdmin。攻击者只要知道 OIDC ClientSecret，数学上就能签出一张 “我是管理员” 的通行证，MinIO 会乖乖验证通过。影响范围从 2022 年 11 月到今年 3 月，三年半。
• CVE-2026-33419（LDAP STS 登录枚举与暴力破解）：攻击者可以先用登录接口枚举出真实用户名，再无速率限制地爆破密码，最后直接拿到 STS 凭证。整个链条从头到尾没有一道闸。
• CVE-2026-34204（复制头元数据注入）：普通 PUT / COPY 请求里夹一些 X-Minio-Replication-* 头，就能把对象写成永久不可读状态，数据还在，但你再也读不出来。
• CVE-2026-39414（S3 Select 内存耗尽）：一条恶意请求，就可以把 MinIO 进程吃到 OOM。
• GHSA-hv4r-mvr4-25vw / GHSA-9c4q-hq6p-c237：unsigned-trailer 路径上的两条签名校验绕过，匿名或伪造签名的请求可以在某些路径下成功写入对象。

再加上 go-jose、go.opentelemetry.io 和 Go 1.26.2 自身吸收的一连串标准库与依赖 CVE，这一版本聚合了接近二十条安全条目。

有的能伪造身份拿到高权限访问，有的能把登录入口拿去枚举和爆破，有的能把对象写成永久不可读，有的能用一条请求把服务吃到 OOM，还有的能在缺失签名校验时直接写入对象。这不是小修小补，这是实打实的维护责任。

这次是怎么修的

在之前那篇文章里，我明确说过我会用 AI Coding Agent 来维护这个项目，事实上我也是这么做的。这一轮修复里，我扮演了一个 Blind Manager 的角色。

简单解释一下我的工作范式。具体到每一条漏洞，流程大致是：

1. Codex 先打铁：根据 CVE 描述和相关代码路径，产出第一版补丁。
2. Claude Code 做 review：站在对抗视角挑毛病。
3. 回到 Codex：我要求它，如果你同意 Claude Code 的意见，那就返工；如果不同意，那就反驳，把理由写清楚。
4. 把所有思路摊开，再交给 Claude Code 做一轮 review。必要时来回再跑几轮，直到两边收敛。
5. 进行测试：依然是类似的对抗操作，由 Codex 设计测试用例，Claude 补充。然后由 Codex 去实际执行并产出结果，再由 Claude Code review。
6. 我来定夺：看 diff，跑测试，做最后决策与验收。

这个过程中，我自己不写一行代码。我的工作是定义问题、约束边界、挑方案、看 diff、跑验收、拍板。

公开提交页上，你能直接看到 Vonng、Codex、Claude Code 三个名字同时出现在几条关键安全提交的 Co-authored-by 里。这不是作秀。这就是 2026 年一个人维护一个中型基础设施项目的真实样子。

这种协作模式有几个实际的好处。

第一，两个 agent 对抗能筛掉大部分“听起来都对、实际上不对”的方案。 单独一个 agent 在修复安全漏洞时会有一种 “幻觉级自信”，写出一份解释流畅、看起来干净的补丁，但漏掉了一个边界条件。让另一个 agent 从敌对视角审视它，这种方案很难活过第一轮。

第二，逼出显式的权衡。 两家不同实现路径撞上了，自然就要回答 “为什么你选 A 而我选 B”。这个对话本身就是在把隐性假设显性化，而显性化的假设，才是我作为 Blind Manager 能拍板的东西。

第三，真正的维护是“补丁打补丁”，而不是一把梭。 拿 LDAP STS 这条洞来说，首版修复推出来以后，很快发现成功请求不该消耗限流额度、默认不该信任 X-Forwarded-For、限流账户要按 “源 IP + 归一化用户名” 双维度算账。 然后又连着补了三次提交才算收敛干净。这个过程如果没有 agent 的火力支持，单个 maintainer 要一边读代码一边迭代，成本是完全不一样的。

有些事还是要人来拍板

但也正因为这个模式运转得不错，maintainer 唯一的不可替代性，就凸显在那些 AI 给不出最后答案的地方。

最典型的就是 OIDC 那条 fix。表面上，它是一个 JWT 算法混淆漏洞；但实质上，它是一个兼容性和安全性之间的取舍。

简单解释一下。JWT 的签名算法分两类：非对称（RS256、ES256 这类，签名用私钥、验签用公钥）和对称（HS256 这类，签名和验签用的是同一个密钥）。OIDC 的标准姿势是 IdP 用自己的私钥签 token、MinIO 用公开的 JWKS 拿到公钥来验签。公钥是公开的，攻击者拿不到私钥，所以没法伪造。

而 HS256 这类对称算法的问题在于：签名和验签用的是同一个密钥。这个密钥就是 MinIO 自己也存着的 ClientSecret。于是攻击者只要拿到这个 “共享秘密”，就既能当裁判又能当运动员。自己用它签一张 token，MinIO 拿自己存的同一个密钥一验，当然通过。

这在教科书上是 JWT 的经典反模式，但历史代码就是这么走过来的。修法有几条路可选：

• 继续容忍这条历史路径，只在某些条件下收窄：保留向后兼容，但安全边界依旧模糊。
• 严格 JWKS-only，拒绝 HS256 等对称签名 token：一刀切、安全边界清晰，但少数本来就配得模糊的用户会感到配置失效。

两个 agent 可以给我列出每个方案的 trade-off，可以写好任何一个方案对应的补丁，但它们不会替我决定。最后我的选择是后者，恢复严格的 JWKS-only 验证路径，明确拒绝不该接受的 HS256。

这个决定也许会让少数模糊配置失效，但安全边界终于清楚了。AI 可以提三个方案，真正承担后果的人还是 maintainer。

这就是 Blind Manager 模式的上限，也是下限：机器负责穷尽方案，人负责选择方向。

不是情怀，是必需

我一直说，这个 fork 不是情怀，也不是 cosplay。它存在，首先是因为这是我自己要用的东西。

MinIO 是 Pigsty 的生产依赖。我需要可用的二进制、完整的控制台、持续可得的包，以及真正有人处理的 CVE 补丁。也正因为我自己在用，所以这条线没有太多空话空间：它不是拿来讲故事的，而是拿来顶生产环境的。

这也决定了我的策略很保守。不会去追求 “新特性很酷”，也不会把仓库弄成另一个方向的实验场。我的目标一直都很明确：保持兼容，守住供应链，在该修的时候把问题修掉。

到现在，这个分支在 GitHub 已经有了 1300 star，在 Docker Hub 也累计了 五万+ 下载。数字本身不算什么惊人的成就，但它至少说明了一件事：需要这条线的人，并不只有我自己。

对已经在用 MinIO 开源版的人来说，迁移到这个分支的成本其实很低：

• Docker 镜像：把 minio/minio 换成 pgsty/minio，一行的事。
• RPM / DEB：GitHub Release 里都有，或者用 pig 一键装。
• 源代码仓库：pgsty/minio
• 文档镜像站：silo.pigsty.cc
• 英文文档：silo.pigsty.io

你不需要换掉整个系统，也不需要重新学习一套对象存储；多数情况下，只是把一个失去维护的上游，替换成一个还会继续交付补丁的分支。 如果你需要完整的生产级部署方案，Pigsty 里也提供了开源免费、开箱即用的 MinIO 生产级高可用部署支持。

承诺是什么

两个月前那篇文章发出去以后，有人私信我，说这事看着挺悲壮。其实不是。

写那篇文章的时候我没有赌气，发这个版本的时候我也没有激动。从头到尾，这就是一件普通得不能再普通的事，用的东西坏了，自己修一下。仅此而已。

只是到了 2026 年，“自己修一下” 这件事的门槛，被 AI Coding Agent 重新定义了。一个人，加两个 agent，加一点点判断力，足以把一个六万 star 的中型基础设施顶起来。这不是我厉害，这是时代变了。

以前我们谈论开源的韧性，谈的是 “社区”，几十上百个志愿者众筹时间。现在这套剧本还在，但底下多了一层保险：哪怕社区散了，只要有一个人还愿意按下 fork 按钮，项目就能续命。

承诺是什么？承诺不是 “我有激情”，也不是 “我有道义”。承诺是 “下一个 CVE 出来的时候，我还在”。

下一个 CVE 出来的时候，老冯还在。

就这样。

MinIO 已死，MinIO 复生

MinIO 开源仓库正式归档，不再维护。一个时代落幕，但开源的精神不死。 老冯 Fork 了 MinIO，复活了管理控制台，重建了二进制分发渠道，让 MinIO 浴火重生。

如果你正在用 MinIO，把 minio/minio 换成 pgsty/minio ，其他一切照旧。

MinIO 的死亡证明

2025年12月3日，MinIO 在 GitHub 上宣布进入"维护模式"。我写了一篇《MinIO 已死》。

2026年2月12日，MinIO 在 GitHub 首页将状态从"维护模式"更新为 “不再维护”，随后正式将仓库归档（Archived）。Read-only，不接受 PR Issue，不接受任何贡献。 一个拥有六万 star、超过十亿次 Docker 拉取的项目，变成了一座数字墓碑。

如果说12月是 临床死亡，那 2月的这个提交就是 正式开具了死亡证明。

今天（2月14日），一篇题为《How MinIO went from open source darling to cautionary tale》的长文引发了广泛传播，详细复盘了 MinIO 从开源宠儿到反面教材的完整堕落时间线。

Percona 创始人 Peter Zaitsev 也在 LinkedIn 上表达了对开源基础设施可持续性的忧虑。国际社区的共识已经形成：MinIO 完了。

不是 “不更新了” —— 是 彻底的、不可逆的、官方盖棺定论的死了。

回顾这18个月的时间线，你会发现这不是一次意外死亡，而是一场蓄意的、分阶段的自毁：

一家融了1.26亿美元、估值十亿美金的公司，花了五年时间，亲手把自己建立的开源生态一砖一瓦地拆干净。

这比跑路还让人难受 —— 因为跑路至少是一次性的，MinIO 选择了凌迟。

但开源不死

故事到这里，按照正常剧本应该是一声叹息，然后大家各回各家。

但我想讲一个不一样的故事 —— 不是悼词，是复活。

MinIO 公司可以归档一个仓库，但它归档不了 AGPL 协议赋予社区的权利。

讽刺的是，AGPL 正是 MinIO 自己选的。他们当年从 Apache 2.0 换成 AGPL，是为了在保留开源名份的同时拿它当武器打 Nutanix 和 Weka。 但开源许可证 是双刃剑 —— 同一把刀，如今也 保障了社区 Fork 的完全合法性。 代码一旦以 AGPL 发布，许可就不可撤回。你可以把仓库设为只读，但你收不回已经发出的许可证。

这就是开源协议设计的深意：公司可以抛弃项目，但不能带走代码。

所以 —— MinIO 已死，但 MinIO 也可以复生。

但也先别急着热血沸腾。Fork 谁都会，点一下 Fork 按钮的事。 真正关键的问题不是 “能不能 Fork”，而是 有没有人真的能把它当成生产组件来维护。

我本来并不想接这个摊子 —— 但我在 MinIO 进入维护模式后等了一两周，社区里没有人站出来说 “我来”，我就只能自己上了。

简单介绍一下背景：我一个人维护着整个 Pigsty 项目 —— 一个全功能的 PostgreSQL 发行版，451 个扩展，支持 14 个 Linux 发行版的交叉构建。 我同时维护着 270+ PG 扩展、六七款 PG Fork、几十款 Go 软件（Victoria/Prometheus 等）的全平台构建工作流，还是游刃有余的。

我对 MinIO 也不陌生。2018年，我们在探探内部就维护过一个 MinIO 的内部分支（当时还是 Apache 2.0）， 支撑了约 25 PB 数据，是当时国内最早、最大的 MinIO 部署之一。

更关键的是，MinIO 在 Pigsty 中是 真实使用的组件， 很多用户将它作为 PostgreSQL 的备份仓库默认跑在生产环境里。

这不是一个 “要不要做” 的问题，而是 不做不行。 早在2025年12月 MinIO 宣布维护模式时，我就已经自己动手创建了修复了 CVE 的二进制。

pgsty/minio RELEASE.2025-12-03T12-00-00Z

我们做了什么

截至今天，我们做了三件事。

1. 复活管理控制台

这是社区最愤怒的一刀。

2025年5月，MinIO 把完整的管理控制台（Admin Console）从社区版中移除，只留下了一个残废的对象浏览器。 用户管理、桶策略、权限配置、生命周期管理…… 一夜之间全没了。想要？掏钱买企业版。

我们把它弄回来了。

讽刺的是，这甚至不需要逆向工程。你只需要把 minio/console 子模块的版本号改回去就行了。 也就是说，MinIO 当初做的事情就是 改了一个依赖版本号，把完整控制台换成了残废版。功能都在那，代码都在那，他们只是给你关上了门。

他们拆了门窗，我们给装回去了。

2. 重建二进制分发

2025年10月，MinIO 停止分发预编译的二进制文件和 Docker 镜像，只留源码。“请用 go install 自己编译” —— 这是他们给用户的交代。

对于绝大多数用户来说，开源软件的价值不只是一份源码副本 —— 供应链的稳定性才是命脉。 你需要的是一个可以写进 Dockerfile、放进 Ansible Playbook、塞进 CI/CD Pipeline 的稳定制成品，而不是每次部署前先装个 Go 编译器。

我们重建了完整的分发渠道：

Docker 镜像

pgsty/minio 已上线 Docker Hub，docker pull pgsty/minio 即可使用

RPM / DEB 包

为主流 Linux 发行版构建了与原版规格一致的安装包。

CI/CD Pipeline

GitHub 上全自动化构建流程已经搭建完毕，确保供应链持续稳定。

如果你在用 Docker 镜像，把 minio/minio 简单换成 pgsty/minio 就好了

喜欢原生 Linux 安装的朋友，可以直接从 GitHub Release 页面下载 RPM/DEB 包。 老冯的 pig （PG扩展包管理器）也可以简单的免翻墙安装。你也可以自己配置启用 pigsty-infra APT/DNF 软件仓库来安装。

curl https://repo.pigsty.cc/pig | bash; 
pig repo set; pig install minio

一切照旧。

3. 复活社区版本文档

MinIO 的官方文档同样面临风险 —— 原本的链接已指向它们的商业产品 AIStor。

所以我们基于 minio/docs 进行了 Fork，修复了失效链接，恢复了被删除的控制台文档，部署在：https://silo.pigsty.io

文档采用与原版相同的 Creative Commons Attribution 4.0 协议，完整保留了所有内容，并持续进行必要的维护更新。

我们的承诺与原则

一些话需要提前说清楚，免得产生误解。

我们不做新特性，只保障供应链

MinIO 作为一个 S3 兼容的对象存储，功能已经足够完善。 它是一个已经完成的软件，它不需要更多花里胡哨的新特性，它需要的是一个稳定可靠、持续可用的版本。

我们做的核心事情就是：确保你随时可以拿到一个能用的、完整的、带管理界面的 MinIO 二进制制成品。 RPM、DEB、Docker 镜像 —— CI/CD Pipeline 自动构建，与你现有的基础设施无缝对接。 不用担心某天 docker pull 拉不到镜像，不用担心 yum install 找不到包。

前提是 MinIO 别用商标武器来搞我，搞我那我就只能重命名了。

这是真实使用的版本，不是归档备份

可能有人会想：这只是又一个 Fork 备份而已吧？不是。 MinIO 在 Pigsty 中是真实使用的组件，很多用户将它作为备份仓库跑在生产环境里。 我们使用的就是自己构建的版本 —— 如果出了问题，我们会第一时间发现，第一时间修复。 我们自己构建的版本，已经在自己的生产环境中用了三个月。吃自己的狗粮，是最好的质量保证。

我们会修 Bug 并跟进安全更新

如果你在使用中遇到问题，欢迎在 pgsty/minio 提交反馈。 如果是我们构建的版本中可复现的问题，以及安全漏洞（CVE），我们都会积极跟进和修补 —— 但请不要将此视作商业 SLA 承诺 —— 我们尽最大努力，以开源社区的方式运作。

在 AI 编码能力突飞猛进，以及决定不做新特性的前提下，我认为只是修复 BUG/漏洞的工作量是完全可控且可以接受的。

商标问题很难搞，但走一步算一步

商标声明：MinIO® 是 MinIO, Inc. 的注册商标。 本项目（pgsty/minio）为社区独立维护的 AGPL 开源 Fork， 与 MinIO, Inc. 无任何关联、从属或背书关系。 本文中对 “MinIO” 的使用仅用于指代该开源软件项目本身，不暗示任何商业关联。

AGPLv3 虽然允许我们合法 Fork 和分发，但商标法是另一个领域。 虽然我们已经在所有地方明确标注了这是一个独立的社区维护版本， 但 MinIO 公司可能会以商标侵权为由对我们提出异议，要求我们停止使用 “MinIO” 这个名字。

如果 MinIO 方面对商标使用提出异议，我们会配合更名。（大概会叫 silo, stow 之类的） 但在此之前，我们认为在 AGPL Fork 中描述性使用原项目名称是合理的， 毕竟我们也不想把所有的 minio 给重命名了 —— 这对用户没有任何帮助。

AI 改变了游戏规则

可能有人会问：一个人能维护得了吗？

2026 年了，情况和五年前不一样。AI 编码工具正在改变开源维护的经济学。

一个复杂 Go 项目的 bug 定位和修复，在 Claude Code 的辅助下，成本已经降低了不止一个数量级。 以前维护一个复杂基础设施项目需要一个专业团队，现在一个自带 AI 助理的老司机就够了。

你想，马斯克砍到 30 人的工程团队就能维护 X/推特 这种级别的系统。 维护个 MinIO 真没什么大不了的 —— 你只需要有测试验收能力就够了。

老冯行，老冯自己就上了。

Just Fork it!

MinIO 公司可以归档一个 GitHub 仓库，但它归档不了六万颗 Star 背后的需求， 归档不了十亿次 Docker Pull 背后的依赖。这些需求不会消失，它们只会寻找新的出口。

HashiCorp 的 Terraform 被 Fork 成了 OpenTofu，活得好好的。 MinIO 的情况其实更有利 —— AGPL 比 BSL 更友好，社区 Fork 没有任何法律风险。 公司可以抛弃项目，但开源协议的设计就不允许代码死掉。

git clone 是开源世界最强大的魔法。当一个公司决定关门的时候，社区只需要两个字：

Fork it.

参考阅读

• MinIO 已死
• MinIO 已死，谁来接盘
• 从AGPL到Apache：Pigsty 协议变更的思考。

MinIO已死，谁能接盘？

前天 MinIO 宣告进入维护模式，老冯写了一篇《MinIO 已死》聊了聊这个话题。 很多朋友也问我，MinIO 既然摆烂躺平了，有谁能接 MinIO 的班？

大方向的话，台面上的替代品无非就那几个：Ceph、RustFS、SeaweedFS、Garage…… 老冯把这些方案都打好了 Linux 上的 RPM/DEB 包，挨个试了一遍。

总结一句话：没有完美替代。

各有各的问题 —— Ceph 功能全但太复杂；SeaweedFS 针对小文件优化但需要独立元数据库；Garage 小巧玲珑但功能简陋；RustFS 兼容 MinIO 但竟然还是 Alpha。

MinIO 替代品速览

MinIO 是 AWS S3 的开源替代，所以从单纯的 对象 CRUD 功能 上来讲，任何兼容 S3 API 的对象存储系统都可以作为 MinIO 的替代品。 但如果考虑到非功能类特性 —— 可靠性，可运维性，复杂度，工具链，生态成熟度，运维 SOP 这些，想要 “平替” 掉 MinIO 确实不容易。

这里我们不聊商业存储，云厂商的对象存储服务，只聊开源项目的话，大体上会有这些选择：

Ceph 可能是企业用户的最佳选择，但学习曲线陡峭，适合有专人运维的团队，不像 MinIO 一个二进制走天下。 很多用户并不需要分布式块存储和分布式文件系统的功能，而且运行还需要额外的 Podmon，不如 MinIO 爽利。

SeaweedFS 质量不错，针对海量小文件场景做优化，O(1) 磁盘寻址，小文件场景性能碾压。 但它需要一个独立的元数据库来存储文件元信息，这就带来了外部依赖。如果你需要一个"通用对象存储"，它不是最佳答案。

Garage 是欧洲 Deuxfleurs 团队的作品，拿过欧盟 NGI 资助，适合自托管爱好者和边缘计算场景。 非常轻量（10MB），但 S3 兼容性太弱，没有版本控制，跨区域复制，IAM 这些，不适合企业场景。

RustFS 是唯一一个瞄准"MinIO 替代"生态位的项目，但成熟度不足 —— 竟然还是 Alpha。

RustFS 是否可以替代 MinIO

在所有号称"MinIO 开源替代"的项目中，老冯本来最看好 RustFS，所以特地花了些时间测试。 我在 Pigsty 中尝试将 MinIO 换成 RustFS，大部分逻辑可以复用，但还是有些区别：

• RustFS 对证书名称有特殊要求
• RustFS 的健康检查接口与 MinIO 有所不同
• RustFS 不支持 mc admin 管理命令，无法配置详细的 IAM 策略。这一点对企业用户而言比较重要。

总的来说，跑起来了，但老冯思考再三，还是把这个分支给放弃掉了。因为把 Alpha 版的软件用在生产环境实在是太不像话了。 我是比较期待 RustFS GA 版本出来之后，再来做一次评测。

RustFS 是否会重蹈 MinIO 覆辙

当然，RustFS 这个项目虽然看上去很有潜力，但也存在一些问题。例如，RustFS 是否会重蹈 MinIO 覆辙？ 特别是，RustFS 在很多雷点上，跟 MinIO 十分相似。

老冯请 AI SOTA 三件套（GPT5-pro, Claude4-Opus, Gemini3-pro）对 RustFS 的风险进行了全面的分析评测。

其中 Gemini 对 RustFS 项目提出来了几项相当严重的指控，老冯又请 Claude 核实了一遍。

RustFS 这些风险信号与当年的 MinIO 几乎一模一样：Apache 2.0 + 版权转让型 CLA + 单一商业公司控制。 考虑到这些因素，老冯对 RustFS 的评级从 “乐观期待”，下调为 “谨慎观望”。

所以，应该怎么做？

老冯的 PostgreSQL 发行版 Pigsty 里面集成了 MinIO 作为对象存储的解决方案。 这完全是一个可选的模块，主要作用是 —— 存储 PostgreSQL 备份，以及在其他业务软件需要对象存储的时候提供一个 —— 比如自建 Supabase 。

考察了现有的生态替代品之后，老冯确实是不想再折腾换 MinIO 的事情了，也许会提供一个用 pgbackrest 自己的备份服务器替代掉 MinIO 的选项。

老冯觉得目前最优的方案，还是继续使用 MinIO 的最新版本，锁定版本，做好网络隔离。 等待半年左右，看看社区生态的发展再做打算。如果那时候 MinIO 有人接手，或者 RustFS GA 可用了，再做调整也不迟。

当然，RustFS 也可以抓住这个机会，抢占 MinIO 的生态位，并真的实现一个更好，更安全，协议更友善的 MinIO 版本。 机会不等人，老冯觉得这个窗口也就几个月时间，错过了就是错过了。

继续使用 MinIO 的注意事项

如果要继续使用 MinIO，有这么几个注意事项。第一是应该用什么版本。 虽然说，MinIO 20250422 版本是最后一个功能完整（带有控制台 GUI）的版本，但老冯还是建议使用最新的版本。

因为从 20250422 到现在（2025-12-08）这段期间，MinIO 有一个比较严重的 CVE 安全漏洞。

CVE-2025-62506: Privilege escalation via session policy bypass (HIGH)

这个漏洞允许低权限用户创建一个新的账户实现权限提升。不过如果是在内网环境中，并且做好网络隔离的话，这个漏洞的风险也是相对可控的。 这个漏洞已经在 MinIO 20251015 版本中修复了，但是 MinIO 很鸡贼的从这个版本开始移除了二进制，只提供源代码。

不过老冯觉得还好，因为 MinIO 是一个 Go 语言项目，编译就一条命令，跨平台编译 goreleaser 一把梭也很简单。 流程我已经跑通了，其实很简单，老冯就直接 Fork 了 MinIO ：然后用 MinIO 自己的打包器做了 2025-12-03 的 RPM/DEB 包，起码不会带病上岗。 把 MinIO 重新从一个 “源码发行版” 恢复成一个二进制发行版。https://github.com/pgsty/minio

不过，安全漏洞和BUG还是得有人来修的，MinIO 自己说还是会看情况修安全漏洞。 老冯觉得，社区里如果有人愿意接手 MinIO 的话，现在还真是一个非常好的机会。 从 20250422 版本作为基础，CherryPick 重要的 Bug 和安全修复的话，然后开始维护一个 MinIO 社区版本。

说到底，MinIO 经过这么长时间的社区打磨，已经是一个相当成熟稳定的对象存储系统了 —— 基本上算是一个 “已完成的软件”。 需要的不是更新跟进S3各种花里胡哨的新功能（S3 Vector/S3 Table），而是扎扎实实的修 Bug 和安全漏洞。

这种维护状态的软件，搞一个 LTS，社区自发维护起来并不难。如果 MinIO 团队不愿意继续维护，老冯觉得社区里会自发涌现出接棒的人选 —— 毕竟现在有很多商业存储硬件公司都在用 MinIO。 比起自己从零瞎搞一个对象存储，接手一个成熟的项目，反而是更省事的选择。

题外话与更新（2026-02-14），MinIO 官方仓库已经彻底归档并不再维护。 我创建了一个 Fork：pgsty/minio / 文档 https://silo.pigsty.io。 搭建了 CI/CD 提供 RPM/DEB 二进制包与 Docker 镜像，基于最后的上游版本 2025-12-03 构建，恢复了 2025-05 阉割的控制台能力。

MinIO已死

2025年12月3日，是个值得在开源软件历史上记一笔的日子。 MinIO 官方在 GitHub 上更新项目状态，宣布 MinIO 开源项目进入“维护模式” 。 这基本上宣告了 MinIO 作为一个开源项目的死亡。

MinIO 这家公司，终于完成了从“屠龙少年”到“恶龙”的华丽转身。

从屠龙勇者到新的恶龙

民主化时代（2014–2019）：对象存储的 Apache

MinIO 成立于2014年，其创始愿景极具理想主义色彩——做“对象存储领域的 Apache”。在那个 AWS S3 统治云存储的年代，MinIO 以其极致的轻量化（单个静态二进制文件）和对 S3 API 的 100% 兼容性，迅速赢得了开发者的青睐。

在这一阶段，MinIO 采用宽松的 Apache 2.0 许可证，鼓励开发者将其集成到各种应用中。其核心价值主张是“让任何硬件都能变成 AWS S3”。这种开放策略极其成功，MinIO 官方宣称其 Docker 镜像下载量超过10亿次，成为全球部署最广泛的对象存储服务 。此时的 MinIO 是云原生技术栈的宠儿，是 Kubernetes 环境中标配的存储后端。

许可证武器化（2019-2025）：AGPL 攻防战

社区关系的第一次重大裂痕出现在2019年至2021年间。MinIO 宣布将其核心许可证从 Apache 2.0 变更为 GNU AGPLv3 。

虽然官方解释称此举是为了防止云厂商（如 AWS、Azure）“白嫖”代码并将其包装为专有服务——这是开源界常见的防御性手段。 这一时期，MinIO 从社区的守护者转变为激进的知识产权捍卫者。 2022 年， MinIO 公开指责 Nutanix Objects 产品侵犯其许可证，撤销了Nutanix 的使用授权；2023 年， MinIO 以类似理由起诉高性能文件系统厂商 Weka。 这些法律行动虽然在法理上具有争议，但释放了一个明确的信号：MinIO 不再欢迎未经付费的商业集成。这为2025年的全面封锁奠定了法律和心理基础。

阉割控制平面（2025-05）

2025年5月，当时 MinIO 决定从社区版代码中移除 MinIO Console——这是一个集成了存储桶管理、身份与访问管理（IAM）、监控和日志审计的关键图形用户界面（GUI）。 此次剥离后，开源版 MinIO 仅剩下一个基础的“对象浏览器”，仅具备查看和下载文件的能力。

而身份策略管理，站点复制配置，生命周期管理等核心运维功能被完全移至商业企业版。 这一变更将社区版 MinIO 从一个功能完备的存储管理系统降级为一个单纯的数据平面组件，剥夺了其作为独立产品在生产环境中使用的控制平面能力

中断二进制分发（2025-10）

2025年10月15日，当时，正值一个关键安全漏洞（CVE-2025-10-15T17-29-55Z / GHSA-jjjj-jwhf-8rgr）被披露之际，MinIO 停止了向 Docker Hub 和 Quay.io 发布更新的 Docker 镜像 。 这一时间点的选择具有极高的战略意味。在重大安全漏洞爆发期间切断二进制分发，实际上是将安全性变成了一种“勒索”筹码。

这一决策直接切断了绝大多数企业级用户的自动化部署链路，使得依赖 docker pull minio/minio 或 helm install 的标准 CI/CD 流程瞬间失效。 对于那些缺乏 Go 语言编译环境或内部容器镜像仓库维护能力的团队而言，这实际上等同于不可用。

维护模式（2025-12）

2025年12月3日，MinIO, Inc. 在其官方渠道及 GitHub 仓库中正式更新了项目状态，宣布 MinIO 开源项目进入“维护模式”。 README 上写到：以后不再提供功能更新改进，不再审Issue合 PR，重大安全问题看情况。 不再提供 RPM/DEB 包与 Docker 镜像，不再加新功能，需要维护的企业用户请切换到商业版本 AIStor 上。

技术影响：对开源生态的破坏

MinIO 进入维护模式对现有技术栈造成了即时且深远的破坏。

CI/CD 管道的断裂与自动化危机

成千上万的 Helm Charts、Ansible Playbooks 和 Terraform 脚本依赖于 minio/minio 或 bitnami/minio 镜像。 随着官方停止发布镜像，Bitnami 等第三方打包商也因无法获取上游稳定代码而被迫停止更新 。

• 连锁反应： 新环境的部署将直接失败；自动扩缩容组（Auto-scaling groups）在拉取新节点时会因找不到镜像而挂起。
• 修复成本： 企业必须重写所有的部署脚本，指向私有镜像仓库，并建立内部的构建流程来从源码编译 MinIO。

安全真空：CVE 管理的私有化

停止发布二进制文件最致命的后果是安全补丁的滞后。以2025年10月的漏洞为例，MinIO 实际上扣留了二进制补丁 。

• 风险暴露： 缺乏专门安全团队的中小企业将被迫继续运行含有高危漏洞的旧版本。
• 合规噩梦： 对于受 PCI-DSS、HIPAA 或 SOC2 监管的企业，无法获得供应商签名的安全更新意味着合规性失效。

运维复杂度的指数级上升

UI 的移除不仅是用户体验的倒退，更是运维成本的增加。 过去只需在 Console 中点击几下即可完成的存储桶策略配置、用户权限分配，现在需要运维人员熟练掌握 mc 命令行工具或编写复杂的 JSON 策略文件。 这无形中提高了使用门槛，使得 MinIO 不再适合作为轻量级的内部工具使用。

背后的原因：资本与商业化的压力

MinIO 的技术决策根本动力来自于资本市场的估值逻辑。截至2025年，MinIO 已累计融资1.26亿美元。 其中最具决定性的是2022年1月完成的1.03亿美元 B 轮融资，由英特尔资本（Intel Capital）、软银愿景基金2期和 General Catalyst 领投。 这轮融资将 MinIO 推上了10亿美元估值的“独角兽”宝座。

在风投逻辑中，10亿美元的估值意味着公司必须展现出通往IPO的明确路径，通常要求年经常性收入（ARR）达到1亿美元以上，并保持高速增长。 2025年2月，MinIO 宣布其 ARR 在过去两年增长了149% 。虽然增速可观，但要支撑如此高的估值，仅靠自然转化已不足够。

停止开源支持，是将庞大的用户基数强制转化为付费客户的最直接手段。

2025年，MinIO 进行了全面的品牌重塑，推出了“MinIO AIStor”，将自己定位为“企业 AI 的数据基石”。 公司管理层意识到，通用对象存储（用于备份、网盘）的市场已是一片红海，且利润微薄；而生成式 AI（Generative AI）对高性能数据吞吐的需求（Exascale AI）才是下一个增长爆发点。 通过优化 AI 工作负载并专注于服务财富500强企业 ，MinIO 实际上决定剥离低价值的开源用户群体。 维护模式的开启，标志着 MinIO 正式从一个广泛的开源项目转型为一家服务于高端 AI 客户的垂直软件供应商

MinIO 已经不是几个极客在车库里写的玩具了，它是一家融资了 1.26 亿美元、估值超过 10 亿美金 的商业公司。 它的背后站着 Intel Capital，站着 软银愿景基金。 当你拿了风投那么多钱，你的老板就不是用户，而是投资人。 投资人要的是什么？是 ARR（年度经常性收入），是 增长率，是 IPO。 你跟投资人说：“我有10亿次 Docker 下载量！” 投资人会问：“这10亿次下载，给你付了一毛钱吗？”

现实就是这么残酷。那帮用免费版 MinIO 的中小企业、个人开发者，在资本眼里就是低价值资产。 你们提 Issue 报 Bug，群里问东问西，消耗的是昂贵的工程师工时，带宽和服务器资源，而你们 永远不会转化为付费客户。 MinIO 的管理层很清楚，他们的真正金主是那些搞 AI 大模型 的 500 强企业。 那些训练 GPT、跑自动驾驶数据的公司，需要的是 AIStor，是极致的性能，是 7x24 小时的 SLA 。

所以，开启“维护模式”，本质上是一次资产剥离。MinIO 决定切掉这块“坏肉”（免费用户），把所有资源集中到能产奶的“金牛”（企业级 AI 客户）身上。 从商业策略上讲，这叫聚焦。 从对投资人的交代上讲，这叫负责。 只是从开源上来说，这叫缺德。

老冯的感想

老冯大概从 2018 年开始使用 MinIO ，当时还是 Apache 许可证，我们搞了几个几 PB 的对象存储，用来存放视频，图片，备份 —— 可能是那时候国内最大规模的部署实践。 老冯也编写了 MinIO 部署监控，扩缩容的 Playbook ，算是做过一些贡献 —— 现在还能在 Pigsty 中开源提供。

作为开源创业者，老冯不是不能理解这种改变的动机。 但是站在开源贡献者与用户的立场 —— 老冯也知道很多兄弟现在心里只有一句话：“我从未见过如此厚颜无耻之人。”

开源协议虽然不是卖身契，但它是一种社会契约。 开发者贡献代码、用户贡献测试场景和口碑，大家一起把项目捧红。 MinIO 享受了十年的社区红利，靠着“全球下载量第一”的虚荣指标拿到了融资， 转头就对这就帮把它捧上去的用户说：“你们是搭便车的，滚蛋。” 这种行为破坏了开源社区最底层的信任。

这种“养套杀”的手段，比币圈的 Rug Pull 还要恶心。币圈割的是钱，MinIO 割的是全球数万家企业的技术栈 —— 用户的选择其实不只是一个二进制，而是一个软件生态和设计哲学。等大家都上车了，把迁移成本堆高到无法承受，然后突然抽走梯子。 这种模式，开源专家 Tison 在《诱导转向的伪开源战略》已经聊的很透聊。

诱导转向的核心问题在于 欺骗，既然 MinIO 背叛了社区，社区也会抛弃它。Garage、SeaweedFS 甚至 RustFS，替代品有很多。江湖路远，后会无期。 如果要说老冯的感想是什么，那么就借用《银河系漫游指南》里海豚临走时说的那句话吧：

—— “So long, and thanks for all the fish.” —— 再见，多谢你们的鱼了。

题外话与更新（2026-02-14），MinIO 官方仓库已经彻底归档并不再维护。 我创建了一个 Fork：pgsty/minio / 文档 https://silo.pigsty.io。 搭建了 CI/CD 提供 RPM/DEB 二进制包与 Docker 镜像，基于最后的上游版本 2025-12-03 构建，恢复了 2025-05 阉割的控制台能力。