Show HN：开源的 x64 和 Arm GitHub runner

原文 ↗ Hacker News 讨论 ↗

Ubicloud 的开源 GitHub Actions runner 通过在 Hetzner 等裸金属提供商上运行，承诺将 CI 成本降低最多 10 倍并加快构建速度，引发了对 GitHub 定价和性能不满的团队的强烈兴趣，尤其是在 Linux 工作负载上。评论者围绕 Ubicloud 如何处理缓存、存储隔离、许可（包括转向 AGPL）和合规性展开追问，同时也指出了诸如 macOS 支持、SOC 2 以及可能与 GitHub 服务条款冲突等缺口。讨论将 Ubicloud 放在一个拥挤的第三方 runner 和自托管方案生态中，反映出对更便宜、更可控 CI 基础设施的更广泛趋势。

产品与定位

  • 运行在 x64/ARM 上的开源 GitHub Actions runner，基于裸金属服务商（尤其是 Hetzner）构建，宣传为比 GitHub 托管 runner 便宜约 10 倍且更快。
  • 被描述为更广泛的“开放、可移植云”的一部分，可自托管，也可作为托管服务使用。
  • 有反馈认为其表述有些含糊、过于营销化；有人建议更具体地解释它是什么、为什么更便宜，并收紧落地页文案。

性能、缓存与存储

  • 多位用户表示，相比 GitHub 托管 runner，速度大幅提升、成本明显下降，有时构建时间减半甚至更多。
  • GitHub 自家 runner 的 I/O 普遍被认为很差；迁移到 Hetzner 或自托管硬件通常可带来 5–10 倍的 I/O 提升。
  • 当前缓存是痛点：GitHub 托管缓存通过网络传输很慢；一些用户通过禁用缓存、重新计算来获得更快的构建。
  • Ubicloud 正在设计自己的缓存方案（Docker 层、包缓存）。有人建议为每个构建器提供本地持久磁盘，类似其他 CI 平台。
  • 讨论了存储架构：需要 copy-on-write/clone-on-attach，避免每次运行都复制约 86GB 的基础镜像；同时担心 CoW/CoA 的性能以及文件系统选择（ext4 vs btrfs、ZFS 替代方案）。

安全、数据清除与合规

  • Runner 是临时性的；VM 会在作业之间关闭，块设备会被移除。计划中未来还会为 GH runner 提供类似普通 VM 的“cryptoshredding”。
  • 有人担心块设备复用可能泄露数据；讨论中的一种缓解方式是静态加密，采用 KEK/DEK（但尚未在此完全应用）。
  • 一些人担心缺少 SOC2 及类似认证，尤其考虑到 CI 流水线会访问密钥和部署密钥。
  • 讨论了 GDPR 合规性和公司司法管辖区；线程中没有明确回答。

macOS Runner 与许可问题

  • macOS CI 成本是一个主要痛点。Apple 的许可要求（物理 Mac、24 小时最低租期）使托管 macOS 变得棘手。
  • 由于许可和硬件限制，Ubicloud 不打算支持 macOS；同时也提到了其他提供 macOS ARM 的服务商。
  • 还讨论了 GitHub 新的 M1 runner 以及第三方 macOS 方案。

法律 / GitHub ToS 与生态

  • 有人担心销售“托管 GitHub runner”可能与 GitHub Actions 的服务条款冲突。各方解读不同：
    • 一方认为 ToS 只是禁止把 Actions 变成商业 CI 平台，并未禁止第三方 runner。
    • 另一方则认为，将 runner 商业化用于 Actions 的产品可能仍处于灰色地带。
  • 文中提到了许多替代方案和相关工具（BuildJet、WarpBuild、RunsOn、Cirun、AWS/Hetzner Terraform 模块、自托管方案）。

许可与开放性

  • 项目最近从 Elastic license 切换为 AGPLv3；线程中提到并欢迎这一变化。
  • 一些文档仍引用 Elastic，需要更新；维护者表示这正在修正。

其他问题

  • 对未来支持 Windows 和 FreeBSD 感兴趣。
  • 有人请求支持私有出口网段 / 在客户 VPC 内运行，以便安全地访问内部资源。
  • 简要提到关闭缓存与网络密集型缓存对环境影响的影响；对此被认为复杂且难以量化。