PGSTY Silo 推荐，MinIO 停更之后的一行式迁移方案

用 MinIO 自建对象存储的人，2026 年过得不太平。上游的收缩有整条时间线，2021 年服务器端许可证从 Apache 2.0 改成 AGPLv3，2025 年年中社区版管理 Console 被移除，10 月停发社区版预编译二进制与容器镜像，12 月初宣布进入维护模式，2026 年仓库归档，9 月 11 日 Docker Hub 上的 minio/minio 与 minio/mc 整库消失。老部署的安全更新一下子没了着落。PGSTY Silo 是社区给出的接续方案之一，从 MinIO 源码 fork 而来，主打把迁移成本压到改一行配置。我把它的官网、Docker Hub 页面和 Hacker News 上的两轮讨论都读了一遍，这个项目值得认真看看。

仓库的身世先交待两句。它前身为 2025 年 10 月创建的 pgsty/minio，2026 年 8 月 6 日更名 pgsty/silo，首个 Silo 版本同日发布，旧仓库冻结在 8 月 4 日的版本上作为存档。兼容性对照的基线是上游 2025 年 12 月 3 日的源码。

主要功能

Silo 由 Pigsty 作者冯若航（Vonng）维护，仓库在 GitHub 的 pgsty/silo，AGPL-3.0 开源，用 Go 写成，GitHub API 显示星标 3300 多。它的兼容承诺列得很具体，S3 API、Admin API、SigV4 签名、/minio/* 路由、MINIO_ 环境变量、minio_ 指标、x-minio- 头字段、.minio.sys 磁盘格式全部保留。官网的原话是，改名的是产品与交付面，协议与你的数据不变。

迁移方式确实配得上一行式这个说法。Docker 用户把镜像 minio/minio 换成 docker.io/pgsty/silo，环境变量、命令参数和数据卷都不用动，旧的 minio server /data 写法也能被识别。原生部署场景，silo 包可以与 minio 包并存安装，systemd 服务从 minio.service 换成 silo.service，/etc/default/minio 照旧读取，权限位还能靠 drop-in 保持原来的 UID 与 GID。写代码的人也有份，Go 模块路径保持原样，依赖 minio 客户端库的项目编译不用改。Dokploy 作者在官网留下的评价是 drop-in replacement，环境变量、服务端命令与 /data 磁盘格式全部照旧。

解决了什么需求

存量用户的声音最能说明这个项目的价值。Hacker News 用户 spapas82 在 8 月的讨论里写道，自己在改名前已经用了两个多月，直接装在现有 MinIO 部署上，无需任何改动，还带回了被上游移除的完整管理 Console。他的部署规模不小，迁去别的存储系统非常困难且危险，原话称这个 fork 对他是 a godsend。博主 Simon Späti 在自己的笔记里称它为 MinIO 的 1:1 替代品。

生态跟进也在发生。作者 8 月的博文列出了 30 多个已切换的项目，包括 RAGFlow、Dokploy、Grafana Loki 的 Helm chart 与 nixpkgs。自家的 Pigsty v4.5 更进一步，对象存储模块只部署 Silo，配置项 minio_type 仅接受 silo 一个值。Docker Hub 页面显示镜像拉取量为 10 万次以上（作者 8 月博文的口径是超过 50 万次，两个数字口径不一，以 Docker Hub 量级显示为准）。仓库议题区目前开着 11 个 issue 与 1 个 PR，日常维护看得出在跑。

版本与安装

当前最新版本为 RELEASE.2026-09-16T00-00-00Z，2026 年 9 月 16 日发布，发布节奏大约一到两个月一次。安装渠道覆盖多架构 Docker 镜像（amd64 与 arm64）、Linux/macOS/Windows 二进制、RPM/DEB/APK 包、Kubernetes Helm chart，镜像内置兼容客户端 mcli。每版附带校验和、SBOM 与签名。截至 8 月，项目累计修复 14 个安全问题（官网口径），8 月的一次审计又发现 12 个同类缺陷并处理。

注意事项

这个项目的底色要交待清楚。核心维护者是一个人，官网明说不承诺续写上游完整路线图，没有响应与修复的 SLA，也没有商业支持，生产环境建议固定版本、开 TLS、做独立备份。开发方式也有争议，官网承认大部分代码与初审由编码代理完成，强调人类审阅每个 diff 并决定取舍。HN 用户 KomoD 半开玩笑说主要贡献者是 Claude 和 Codex，另一用户 Lucasoato 质疑文档的 AI 痕迹过重。这些声音与 spapas82 那类实际跑在生产上的反馈并存，怎么权衡取决于你对单人项目和 AI 辅助开发的接受度。容器部署记得锁死版本号，别用 latest 标签跟着滚动。

与 MinIO Inc. 的关系也值得知道。仓库免责声明写明这是独立社区维护的 fork，与 MinIO 公司无隶属、无背书。上游归档日期存在两种说法（GitHub 横幅显示 4 月 25 日，作者博文写 2 月 12 日），大概率经历了归档再解档的反复，以 GitHub 页面为准。

总结

Silo 给了 MinIO 存量部署一条改动最小的活路，兼容清单和迁移文档都做得扎实。单人维护加 AI 重度参与是它的风险面，也是它能把安全修复跑出高频率的原因。数据无价，迁移前照官方建议做好备份，校验和顺手核对，别省这一步。

来源

• GitHub 仓库 https://github.com/pgsty/silo
• 官网 https://silo.pgsty.com/
• Docker Hub https://hub.docker.com/r/pgsty/silo
• 作者博文 Silo is coming https://vonng.com/en/db/silo-is-coming/
• 作者博文 Long live Silo https://vonng.com/en/db/long-live-silo/
• Hacker News 讨论（MinIO is now community-forked as Silo） https://news.ycombinator.com/item?id=49287196
• Hacker News 讨论（Show HN: Silo） https://news.ycombinator.com/item?id=49198572
• It's FOSS 报道（媒体来源） https://itsfoss.com/news/minio-moves-away-from-open-source/
• minio/minio Discussion #21326 https://github.com/minio/minio/issues/21326