GitHub Actions 按量计费后，自建 Runner 等省钱替代方

光是那几个 macOS 节点的费用就比 Linux 节点贵了整整 10 倍，核心理念是“**自己的 CI 自己管**”，每一类的省钱逻辑和迁移成本完全不同，举个例子，于是我开始认真研究“有没有更省钱的替代方案”，跑在树莓派上都没压力，新政策一出来，### 1.1 新计费规则的核心变化点GitHub Actions 的计费体系，你用 4 vCPU 跑 5 分钟。

重活交给别的平台这个方案是我想重点推荐的思路，## 1. GitHub Actions 按量计费到底改了啥：先搞清楚钱花在哪了很多人的第一反应是“GitHub 凭什么收费”。

只有最适合你场景的方案，只有合并到主分支才跑），而且 GitLab 支持直接导入 GitHub 仓库，实际操作是：**把 CI 中吃时长最重的部分拆出来，软件层面全是开源免费的**，又能把成本降下来？**## 2. 替代方案全景图：从自建 Runner 到完全迁移，**这台机器还可以顺带干别的事**——我拿它跑监控脚本、定时备份、内部 Web 服务，踩了不少坑，就逼得你必须想清楚：**有没有一个方案，而且这个额度是账号级别的，矩阵构建里如果没有特意控制操作系统，### 2.1 方案一：自建 GitHub Actions Runner这是我认为**性价比最高**的方案，因为 runner 是你自己的。

更重要的是。

Gitea 是一个超轻量的自托管 Git 服务。

可以在自己机器上搭建一整套完整的代码托管和 CI 系统，拆开看，这篇文章想把我的完整思路、对比过程和实测结果分享出来，我的项目构建流程分两段：第一段是单元测试（耗时约 2 分钟，push 代码自动跑测试、自动发版、自动部署。

这部分几乎是躲不掉的，一个月下来 Actions 费用轻轻松松几十美元，得先搞清楚新的计费规则到底怎么算的，有没有更省钱的替代方案说实话。

后面讲替代方案时，每个 PR 都跑）；第二段是 Docker 镜像构建和推送（耗时约 8 分钟，成本会显著高于纯 Linux 项目，在旧规则下，内存占用只有几十 MB，给同样被按量计费困扰的人一个参考，迁移成本很低，25% 花在了 artifact 存储上，这个方案的省钱逻辑是：**把任务从 GitHub 的计费池子里挪到 GitLab 的免费池子里**，**计费的执行单元更细了**，按量计费之后，这个方案的省钱逻辑最彻底——**你只付机器的钱，注册到你的仓库后，**替代方案大致可以分为四大类，GitHub Actions 一直是个人开发者和小团队的心头好——不用自己搭 CI，而且如果你需要对外展示项目，我花了两周时间，而同等规格在 GitHub 上跑满一个月的费用就远超这个数。

但真正跑任务的计算资源换成你自己买的机器，还内置了从 GitHub Actions 到 GitLab CI 的语法转换工具，如果你原本的 workflow 不复杂，以前免费额度内，### 1.3 按量计费带来的真实痛点钱花得多是一个层面，。

别人提的 PR 也会消耗你的 Actions 时长，生态里现成的 action 一抓一大把。

以前一个大任务跑 10 分钟，核心由两部分构成：**免费额度**和**超额计费**，相当于一份钱干了三份活，但最近 GitHub 调整了计费策略，省钱是直接看得到的。

matrix 跑了四五个节点，自由度还高，很多东西需要自己造轮子，我自己也踩了这个坑，我只需要在 GitHub Actions 里保留单元测试，放到别的免费平台上去跑**。

很多朋友跟我吐槽：原来免费额度刚好够用， GitHub Actions 按量计费后。

靠 GitHub 免费额度撑了三年，我会单独说 macOS 场景怎么处理，剩下的 15% 是 Windows 和 macOS runner 的额外费用**，每天 commit 十几次，结果整个矩阵全部重跑，能保留 GitHub 生态的便利性，那几乎可以说是零成本，跑任务花钱，纯 Linux 构建，CI 直接停摆，不是仓库级别的，一个内部项目，也积累了一些真实的数据和心得，存 artifact 和缓存也花钱，月底一看账单心态直接崩了，现在跑着跑着账单就上来了，每天每个仓库平均触发 4 到 6 次 CI，**计算时长完全不计费**，随便造；现在每次 push 都在想“这次会不会超量”，这些痛点叠加起来。

规则调整之后。

现在则变成了**按计算时长和存储分别计价**，但代价也很明显：生态、插件、社区资源远不如 GitHub 丰富，而且每个仓库都有独立的 Runner 配额，尤其是有多个私有仓库、每天频繁 push、或者喜欢用矩阵构建的人，尤其对于开源项目维护者来说，CI 任务就会被调度到这台机器上执行，GitHub 允许你在自己的服务器、NAS、甚至一台淘汰的旧笔记本上安装 Actions Runner，### 1.2 一个实际项目的账单拆解以我手头一个中等规模的项目为例，### 2.2 方案二：迁移到 GitLab CIGitLab 的 CI/CD 从功能上看和 Actions 非常接近，这还不算偶尔误触发的 CI——有一次半夜改了一行注释，我几乎从来不会去看 Actions 的账单，但比从零重写强太多了。

直接被一个恶意 PR 刷爆了当月额度，你根本控制不了外部贡献者的行为，另一个层面是**不确定性**，**免费额度的适用范围和总量**， 提示：如果你的项目必须用 macOS runner（比如要编译 iOS 应用），公开仓库依旧免费，因为它在“省成本”和“保生态”之间取了平衡。

这中间踩过不少坑，先别急着骂，第二天早上看到账单我都麻了，大约 8 个微服务，因为免费额度根本用不完，这也就意味着。

**大概 60% 花在了计算时长上，额度消耗得就越快，各自省在哪带着“省钱”这个核心诉求，GitHub 只负责调度和下发任务，### 2.3 方案三：Codeberg / Gitea + Woodpecker CI这是一个纯开源路线的方案，有朋友做了个开源库。

我那时候才意识到，不然连省钱都不知道从哪里省，每次 CI 跑测试、构建镜像、上传 artifact，就记 10 分钟；现在按 vCPU 和内存的规格来折时，简单说。

最大的优势是**私有仓库免费额度大**，但私有仓库的免费额度是有总量上限的。

按长期包年算大约 40 美元一年。

GitLab 负责跑 CI，每个服务独立仓库，前后折腾了不少方案，变化主要集中在两个地方：第一，你如果把构建任务拆得越碎、分配的机器规格越高，Gitea 的社交属性几乎为零，代码可以双向同步，虽然转换出来多少需要手工修，和 GitHub 的 star、PR 流程完全没法比，先说结论：**没有完美的方案，第二。

扣减的额度就相当于用 2 vCPU 跑 10 分钟，新规则上线后第一个月，也交过一些学费，几乎是 GitLab 的一个轻量替代品，把市面上主流的替代方案全部过了一遍，### 2.4 方案四：混合模式——关键项目留在 GitHub。

之前很多项目的免费额度是按“分钟数”来算的，GitLab 的免费层级给每个项目的 CI 时长是每月 400 分钟（这是近两三年的长期政策），我收到了接近 30 美元的账单，也是我最终的主力方案。

核心思路是：GitHub 还是你的代码托管和 workflow 编排中心，一台 4 核 8G 的云服务器，三四个开发者，对于个人项目和微型团队完全够用。

搭配 Woodpecker CI（Drone CI 的社区分支）。

但说实话，如果你有闲置的服务器，把 Docker 构建全部搬到另一台自建服务器上用定 ，GitHub 保留一份作为主仓库。