9 月 11 日前后，不少人的 CI 在 docker pull minio/minio 这一步红了。
不是网络问题，也不是登录态过期------是 minio/minio 这个仓库从 Docker Hub 上被整个移除了，所有 tag 都返回 404 / pull access denied。
如果你本地或流水线里还留着一行 image: minio/minio，现在能跑起来只是因为缓存还在；下次 clean pull，它就会断。
下面把能核实的事实和时间线捋一遍，再说清楚你该怎么办。
到底发生了什么
- 2025 年 10 月 ：MinIO 社区版转为 "source-only" 分发------不再为社区版提供预编译二进制和镜像。最后一个带构建的镜像是 2025 年秋天的版本，最后一个 tag 是
RELEASE.2025-10-15T17-29-55Z（第 521 个 release）。 - 2026 年 4 月 25 日：GitHub 仓库被归档（archived），进入只读状态。
- 2026 年 3--4 月：社区针对 MinIO 发布了 7 个安全公告，其中 4 个高危，包括两个未授权对象写入漏洞（CVE-2026-41145、CVE-2026-40344，据 reptile.haus 复盘）------而这些公告里写明的"修复版本"在公开仓库里根本找不到对应的 tag。最后一个镜像与多个高危公告对不上修复版本：CVE-2025-62506（服务账号权限提升）在 reptile.haus 的口径里已于 2025-10-15 版本修复，但 Texera 邮件列表又称最终镜像仍携带该漏洞，两源冲突，谨慎起见不把它当作"已修"。
- 2026 年 9 月 11 日 ：Docker Hub 上的
minio/minio与minio/mc被移除，所有 tag 失效；bitnami/minio也同步消失。 - 现在 ：
quay.io/minio/minio还能拉到，但只停留在 2025 年秋天的冻结 tag，不再维护。
来源：Graylog #27370（9/12 报告 Docker Hub 404）、Apache DataFusion-ballista #2446（明确写明 "withdrew on 2026-09-11"）、Texera dev 邮件列表（9/12 确认 minio/minio 与 minio/mc 从 Docker Hub 移除）、reptile.haus 的复盘文章，以及多个在 9/12--9/14 把镜像源切到 quay.io 的社区 PR。
为什么这件事值得你停下来
在无数仓库的 docker-compose.yml、CI 配置、本地 dev 脚本里，都静静躺着 image: minio/minio。它长期跑在开发机和 CI 里，从没进过采购流程，也从没出现在风险登记表上。
所以它不是以"一次有计划的迁移"的形式退出，而是以"一次红掉的构建"的形式通知你的。
这恰好是对象存储作为"隐形基础设施依赖"的典型案例：你以为它稳，其实它已经一年多没人维护，而如今 AI 发现并利用漏洞的速度，比这快得多。
先自查，再动手
别等 CI 红。两步把风险摊开：
第一步，全仓搜一遍你到底在哪依赖了它：
bash
grep -r "minio/minio" ./ \
--include=docker-compose.yml --include="*.yml" --include="*.yaml" \
--include="*.github/workflows/*" -l只要搜出来，就说明这条链路还指着那个已经消失的镜像。
第二步，如果决定换，把镜像用 digest 钉死，别再信 tag：
bash
docker pull rustfs/rustfs:latest
docker inspect --format='{{index .RepoDigests 0}}' rustfs/rustfs:latesttag 会变、会删；digest 不会。对还在用的任何镜像都该这么做。
第三步，验证 S3 兼容性是否真的接得上（以 mc 为例）：
bash
mc alias set local http://localhost:9000 YOURKEY YOURSECRET
mc mb local/test
echo "hello" | mc pipe local/test/hello.txt
mc cat local/test/hello.txt能写能读，说明你的客户端代码不用改------因为大家都走的是通用 S3 API，不耦合 MinIO 本身。
替代品怎么选（客观列一下）
对象存储的救赎在于：几乎所有东西都通过通用 S3 API 跟 MinIO 通信，换是可以低成本的。常见选项：
| 项目 | 协议 | S3 覆盖 | 成熟度 | 是否接近 drop-in | 主要风险 |
|---|---|---|---|---|---|
| RustFS | Apache-2.0 | 广（multipart / 版本化 / 策略 / 生命周期 / SSE）；Object Lock、部分加密细节仍在补齐 | 年轻（2025 起，1.0 GA 于 2026-09） | 接近（MinIO 形态配置 + 自带 Web 控制台） | 项目新，能力仍在演进 |
| SeaweedFS | Apache-2.0 | 经 S3 gateway 核心较全；部分 IAM / 策略边界不同 | 2015 起生产验证 | 否（master + volume + filer + gateway） | 比单容器块存储重，迁移成本大 |
| Garage | AGPL-3.0 | 核心操作；版本化 / 生命周期不完整 | 中等 | 否（配置模型不同） | AGPL 许可 + 能力缺口 |
| Ceph（RGW） | 混合（LGPL / Apache） | 成熟 | 最高 | 否 | 运维复杂度最高 |
MinIO 的商业产品 AIStor 还在；消失的是社区版那条"不用多想就 docker pull"的默认路径。
结尾
一个累计拉取量级曾超过 10 亿次的镜像，静默从 Docker Hub 消失，没有大喇叭，只有红掉的 CI。
这件事真正的教训不是"某家公司改了商业模式"------AGPLv3 从没承诺过别的。而是：你 CI 和本地里到底躺着哪些"没人认领"的依赖，你真的清楚吗？
S3 API 兼容的好处是，你不锁定在任何一家。把这次断供当成一次体检，比当成一次危机更值钱。