一个 Nix 用户最怕的，不是某个工具停止更新。

更麻烦的是：它刚好替你做了那块你最不想碰的脏活。CI、远程构建、缓存、Mac builder。Garnix 这次停服，卡的就是这个位置。

Garnix 团队通过邮件宣布，将与 Shopify 合流。托管版 Garnix service 会在 2026 年 7 月 15 日关闭。代码库已经开源，用户可以自建实例，或寻找未来可能出现的共享实例。但同一天，Garnix 会删除全部用户数据，包括 build artifacts。

这不是明天断电。迁移窗口有一年多。

但也别把“代码开源了”理解成“服务有人接上了”。CI 从来不只是一个仓库。

停服信息很短，真正要紧的是数据和迁移

这次事件的事实并不复杂。

项目已知变化用户要做什么
团队去向Garnix 团队称将与 Shopify 合流不要写成收购，原文没有这么说
托管服务2026 年 7 月 15 日关闭依赖 garnix.io 的项目要安排迁移
代码Garnix 代码库已经开源可评估自建，但要准备运维和算力
数据同日删除全部用户数据和 build artifacts需要保留的构建产物要提前下载

最容易被忽略的是最后一项。

服务关闭不是只影响“以后不能跑”。它还会影响“以前跑出来的东西还在不在”。如果项目依赖 Garnix 上的 artifacts 做回溯、发布、缓存或排查问题，现在就该盘点哪些东西要留。

对维护者来说，动作很具体：

  • 下载需要保留的 build artifacts。
  • 查项目里哪些 workflow、badge、cache、remote builder 指向 Garnix。
  • 给迁移留出测试时间，不要等到关闭前一周。
  • 如果有 macOS 构建，单独列出来，不要和 Linux 构建混在一起估算。

这几件事不性感，但省命。

最痛的是 Mac builder，不是页面关掉

受影响最直接的，是三类人。

一类是用 Garnix 做 Nix CI 的项目维护者。CI 断了，PR 检查、构建验证、发布流水线都要改。

一类是把 Garnix 当远程构建服务的小团队。机器、缓存、队列、失败重跑，这些平时不显眼，迁移时都会冒出来。

还有一类更具体：本地没有 Mac builder，却依赖 Garnix 跑 macOS 构建的用户。

社区反馈里就有人提到，自己没有本地 Mac builder，但一直用 Garnix 给工作用 MacBook 上的 home-manager 做 Mac builds。这句话很实在。很多基础设施的价值，不在名字多响，而在它替你填了一个特别具体的坑。

迁移路线看起来有几条，但每条都有代价。

路线好处现实约束更适合谁
自建 Garnix 实例代码已开源，可控性更强要自己管机器、队列、缓存、权限、升级有运维能力的团队
等社区共享实例迁移成本可能较低目前承接程度不确定，SLA 也不清楚非关键项目、个人项目
换到通用 CI，再接 Nix 构建生态成熟，团队容易理解远程构建和缓存要重新设计，Mac 资源仍可能贵已有 CI 体系的团队
减少远程依赖，转本地或自有 builder可控，少受第三方影响初期投入高，Mac builder 尤其难长期维护项目或企业内部项目

这里的限制不能轻描淡写。

Linux builder 相对容易堆机器、上云、扩容。macOS 构建要面对硬件、授权、运维和稀缺性。对个人开发者和小团队来说，这往往不是“周末搭一下”就能补上的洞。

所以我不太买账那种“代码都开了，社区接上就行”的轻松说法。

开源解决的是“有没有源码”。没有解决谁来值班、谁来付机器、谁来维护缓存、谁来处理构建失败、谁来提供 Mac 构建资源。

铁路留下铁轨，不等于列车还会准点运行。

这个类比不完全一样，但结构很像：基础设施的价值，不只在可见资产，也在持续调度、维护和承诺。铁轨摆在那里，列车不会自己开。代码放在 GitHub 上，CI 也不会自己跑。

开源基础设施不能只靠善意续命

Garnix 这次处理得不难看。

提前给出关闭时间，开源代码，提醒用户下载 artifacts。这比突然关门体面得多。这个判断要公道。

但它也把一个老问题摆出来：开源基础设施商业化之后，最难留下来的往往不是代码，而是服务。

Nix 的强项是可复现、可组合、可声明。它很适合把复杂构建变成确定系统。

可真实项目里，确定性之外还有一层账：

  • 构建资源从哪里来？
  • 缓存谁来养？
  • 跨平台怎么跑？
  • 小团队不想维护的 CI 部分，谁来兜底？

Garnix 停服不会让整个 Nix 生态的 CI 崩掉。别夸大。受影响的是依赖 Garnix 托管服务的那部分用户。

但它至少说明一件事：Nix 生态如果要从聪明人的工具箱，走向更稳定的工程基础设施，就不能只靠几个团队的热情、创业公司的余温，以及“总有人会接盘”的想象。

“天下熙熙，皆为利来。”放在这里不是讽刺 Garnix，而是提醒社区看清激励。基础设施需要持续收入、组织承接和明确责任。没有这些，善意就会被误当成 SLA。

接下来最该观察的，不是有没有人转发“可惜”。

要看三件事：

观察点为什么重要
是否出现可靠共享实例决定小项目能不能低成本迁移
自建文档和运维路径是否成熟决定开源代码能不能变成可用服务
Mac builder 资源怎么承接决定最痛的用户是不是真的有退路

对项目维护者来说，现在不需要恐慌，但要开始动手。下载 artifacts，列依赖，拆出 macOS 构建，给迁移留测试窗口。

对小团队来说，更现实的选择是延后把关键流水线押在单一托管服务上。要么准备备用 CI，要么把远程构建和缓存的责任写清楚。省下来的运维成本，迟早会以迁移成本的形式回来。

这次真正关掉的，不只是一个托管页面。

它关掉的是一种舒服的幻觉：有人替你跑构建、养机器、扛稀缺资源，而且会一直在那里。