News Hacker|极客洞察

206 2 天前 blacksmith.sh
💸GitHub 对 Actions 控制平面开始收费,自托管运行器也被征费
自家服务器跑 CI 也要给 GitHub 交税,合理吗?

🎯 讨论背景

GitHub 宣布自 2026 年起对 GitHub Actions 的“控制平面”按分钟收取平台费(公开仓库仍免费,但私有仓库及自托管 runner 的调度将计费),触发社区对其商业化方向的担忧。讨论建立在 Actions 架构的二元划分:control plane(调度/编排)与 runners(实际 compute),此次收费把“调度价值”货币化,即使 compute 在用户侧也被计费。评论同时关注计费粒度(按运行分钟、向上取整)、GH runner 的性能问题(如 macOS Intel 长队、safe_sleep、文件传输瓶颈)以及是否应迁移到 GitLab、Forgejo、Codeberg 或采用第三方/自建控制平面(WarpBuild、Blacksmith、Depot 等)。许多人把这次变动与 Microsoft 收购后 GitHub 的商业化和价格上扬趋势联系起来,权衡迁移成本、性能与信任等实务因素。

📌 讨论焦点

平台费与对第三方/自托管的财政惩罚

许多评论把 GitHub 宣布的 $0.002/分钟平台费解读为一种货币化策略,评论认为这会财政性地“惩罚”使用第三方或自托管 runner 的客户,从而把这些 runner 定位为受控的生态伙伴而非替代方案。有人总结这是“三管齐下”的动作:推出廉价 1‑core runner、下调 GitHub 托管 runner 价格,并对自托管加收少量费用,再辅以 vnet 集成和销售推动以鼓励托管方案。评论指出这会改变成本比较的直觉——即使某些第三方仍更便宜,定价方向和销售策略会把客户导向 GitHub‑hosted。整体上,这被看作 GitHub(及其母公司 Microsoft)通过定价调整来强化托管依赖的典型商业化行为。

[来源1] [来源2] [来源3] [来源4] [来源5]

第三方与自托管仍有成本优势与优化路径

WarpBuild 的创始人和其他评论者给出实务角度:即便加上 GitHub 的 $0.002/min“自托管税”,像 WarpBuild、Blacksmith 这样的第三方或自托管方案在大量场景仍比 GitHub‑hosted 更便宜且更快。具体优化建议包括把关注点放在减少 CI 用分钟数(用更快或更大 vCPU 的机器、减少 shard 数量、合并短任务等)而非盲目降低单价;举例说明 bare‑metal 单核 + NVMe 在某些工作负载上远胜云主机。Depot 创始人也提到可以用不同的控制平面触发作业(不依赖 GitHub webhooks),这说明存在技术路径在成本与可用性上竞争 GitHub 的方案。

[来源1] [来源2] [来源3] [来源4] [来源5]

计费细节与对小型团队的冲击

评论里多人强调计费粒度和并发模型会放大影响:GitHub 按运行分钟计费且通常向上取整,短且频繁的子任务(例如多个 linter)会导致每次提交被多次计费,从而远超表面估算。有人贴出实际数字:自托管环境突然增加了 200–300 美元/月,另有约 20 人团队估计年增支约 12k 美元,表明小型团队相对受伤更重。虽然有人承认控制平面确实有运维成本,但评论普遍质疑在多 job/多 runner 并发场景下该价格是否合理,担心它更倾向于把自动化密集型小组织挤出原本的免费或低成本选项。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]

迁移与替代方案

大量讨论集中在替代路径:企业和个人正在评估迁往 GitLab(被提到不会向 BYO runner 收费)、Forgejo/Codeberg/Sourcehut 等开源托管,或采用 Woodpecker、actions‑runner‑controller 在自有基础设施运行 CI。评论也提到更激进的做法——用 webhooks 或自建控制平面来规避 GitHub 的控制平面计费和可用性限制,Depot 的团队称已有非 webhooks 的触发与调度方案可提高可靠性。总体结论是迁移可行但有迁移成本;部分人愿意用开源堆栈或第三方服务以避免锁定与额外平台费。

[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]

性能与稳定性问题放大对平台不满

许多评论将这次定价与 GitHub 被 Microsoft 收购后的商业化轨迹相联系,认为公司更愿意通过定价而非修复核心问题来变现。技术抱怨集中在 GitHub Actions 的速度与可靠性上:macOS Intel runner 长时间排队、文件传输成为瓶颈、还有被提到的 safe_sleep 导致 runner 无限挂起直至超时等具体 bug。有人把 Actions 称为 Azure Pipelines 的模仿品,并认为如果平台在可观收益下不解决这些长期存在的问题,用户信任与使用体验只会进一步下降。

[来源1] [来源2] [来源3] [来源4] [来源5]

📚 术语解释

控制平面 (control plane): GitHub Actions 中负责事件接收、作业调度和运行器编排的服务层,与实际执行作业的 compute(runners)分离。此次收费就是针对这部分的“平台”功能按分钟计费。

自托管 runner (self-hosted runner): 用户在自己或第三方基础设施上运行的 Actions 执行环境,用来执行 CI/CD 作业,但仍受 GitHub 控制平面调度。新定价对这类 runner 的调度时长也会收取平台分钟费。

运行分钟/平台分钟 (runtime/platform minutes): 按作业在 runner 上运行的时间计费的度量单位,通常按分钟粒度计且可能向上取整;短任务或大量并行任务会因粒度问题被多次计费。

actions-runner-controller: 一个在 Kubernetes 环境中动态管理 GitHub Actions self‑hosted runners 的开源控制器,用于在 k8s 集群里自动扩缩、分配 runner,评论中被拿来比较成本与性能。