GitHub Actions 自托管运行器涨价计划延期
简而言之：我们决定推迟此前宣布的自托管 GitHub Actions 计费变更，以便重新评估方案。同时，托管运行器的价格仍将于 2026 年 1 月 1 日下调最高 39%。
我们认真阅读了各位的反馈。
- 我们决定推迟此前公布的自托管 GitHub Actions 计费变更计划，以便重新评估方案。
- 托管运行器价格仍将于 2026 年 1 月 1 日下调最高 39%。
运行Actions控制平面确实存在实际成本。我们同时正在投资自托管运行器，以确保其在客户环境(特别是复杂企业场景)中实现大规模运行。尽管这些背景因素至关重要，但此次调整未能充分纳入更多用户的意见，实属失策。
我们需要改进GitHub Actions。为此，我们将投入更多时间与开发者、客户及合作伙伴深入沟通。我们已开启讨论通道收集直接反馈，并将据此完善GitHub Actions路线图。我们将通过GitHub Actions及整个平台的持续交付，全力赢得您的信任。
以下为2025年12月16日原始公告
现正式宣布GitHub Actions定价与产品模式的更新。
过去，自托管运行器用户可免费使用GitHub Actions的大部分基础设施与服务。这意味着这些核心服务的维护与升级成本，主要由GitHub托管运行器的定价进行补贴。此次定价调整旨在使成本更紧密地与实际使用量及每位用户获得的价值挂钩，同时推动平台的持续创新与投资。绝大多数用户(尤其是个人及小型团队)不会面临价格上涨。
我们将推出 GitHub Actions 费用计算器，帮助您精准预估未来费用。您可通过Actions定价计算器预估未来费用。96%的客户账单金额保持不变。受此次调整影响的4%用户中，85%的用户费用将降低，其余15%用户的中位数增幅约为13美元。
GitHub Actions 对公共仓库仍将免费开放。2025年数据显示，开发者在公共项目中免费使用了总计115亿分钟的Actions服务(价值约1.84亿美元)，我们将持续投入资源，为用户提供快速、可靠且可预测的体验。
背景说明
2018年推出Actions时，我们未曾预料其会如此受欢迎。截至2024年初，该平台日均运行约2300万个任务，现有架构已无法可靠支撑增长曲线。为提升功能迭代速度，我们首先需要增强可靠性并现代化支撑GitHub Actions的传统框架。
我们的解决方案是重构支撑GitHub Actions任务和运行器的核心后端服务，目标在于：提升运行时可用性与抗基础设施故障能力，增强性能表现，减少内部限流机制，并充分利用GitHub更广泛的平台投资与开发者体验优化成果。这项工作已初见成效，即使在新平台的最后稳定化阶段，我们仍能从容应对当前规模。
自八月起，所有GitHub Actions任务均在新架构上运行，日均处理量达7100万次(较初始阶段提升逾3倍)。单个企业每分钟可启动的任务量达到旧架构支持量的7倍。
与所有产品一样，GitHub的目标始终是满足客户需求，同时为企业提供灵活性和透明度。
此次变革更好地支持了CI/CD必须更快、更可靠的世界，提供了更优缓存、更灵活的工作流、坚如磐石的可靠性，强化了核心体验，同时使GitHub Actions能够为GitHub开放、安全的代理工作负载平台提供动力。
具体变更内容
GitHub托管运行器降价
即日起，我们对所有Actions实施公平定价策略，降低GitHub托管运行器价格及客户平均支出。根据所选机器类型不同，GitHub托管运行器的净成本最高可降低39%。
此次降价源于所有运行器规格约40%的降价幅度，同时新增每分钟0.002美元的GitHub Actions云平台计费。对于GitHub托管运行器，新的Actions云平台费用已包含在降价后的计量价格中。
在公共仓库中使用标准的GitHub托管或自托管运行器仍将免费。此变更不会影响GitHub Enterprise Server的定价。
您账户中显示的降价幅度取决于您最常使用的机器类型——小型运行器的相对降价幅度较小，大型运行器的相对降价幅度较大。
此次降价使高性能计算更易于满足高负载 CI 工作流及依赖快速安全执行环境的代理任务需求。
完整定价更新详情请参阅文档中更新的 Actions 运行器价格。
本次价格变更将于2026年1月1日生效。
GitHub Actions 云平台计费机制说明
我们将在 GitHub 托管型和自托管型运行器上，对所有 Actions 工作流引入每分钟 0.002 美元的云平台使用费。新版 GitHub 运行器定价已包含此项费用。此调整不会影响公共仓库中的 Actions 使用，亦不涉及 GitHub Enterprise Server 客户。
此举旨在使定价与使用模式相匹配，并确保两种托管模式下服务质量随使用量增长保持一致。
该政策将影响自托管运行器定价(自2026年3月1日起生效)。
深化对Actions自托管体验的投入
我们将加大对自托管体验的投入，确保自动扩展功能不仅适用于Linux容器场景。未来12个月内，我们将推出全新的扩展方案、新增平台支持、Windows支持等功能。以下是新年度的预览内容：
GitHub Scale Set客户端
这款全新客户端为企业提供轻量级Go SDK，可构建定制化自动扩展方案，无需复杂的Kubernetes操作或依赖ARC。它能无缝集成现有基础设施(容器、虚拟机、云实例或裸机)，同时管理任务队列、安全配置和智能扩展逻辑。客户由此获得官方支持的灵活自动扩展方案，减少配置摩擦，并将 GitHub Actions 的应用场景从工作流扩展至自托管 Dependabot 和 Copilot 编码助手等领域。
多标签支持
我们为 GitHub 托管的大型运行器和自托管运行器(包括由 Actions Runner Controller (ARC) 及新版 Scale Set Client 管理者)重新引入多标签功能。
Actions Runner Controller 0.14.0
即将发布的版本带来重大体验优化：精简的 Helm 图表简化 Docker 配置、增强日志记录、更新指标体系及规范化版本要求。同时宣布弃用旧版 ARC，为迁移至更可靠、可维护的架构提供清晰路径。客户将受益于简化的设置流程、增强的可观测性及长期支持保障，从而降低运维摩擦并提升可扩展性。
Actions数据流
操作数据流将提供近乎实时的权威性GitHub Actions工作流和任务事件数据源，包含元数据(如特定工作流运行中执行的操作版本)。该功能通过将事件数据集成至监控和分析系统，助力企业提升可观察性与故障排查能力，实现合规性与运营洞察。通过提供大规模结构化高保真数据，该服务消除了对人工日志解析的依赖，赋能团队主动管理可靠性与性能。
核心价值
代理程序正拓展团队自动化能力边界，但持续集成/持续交付仍是现代软件交付的核心命脉。本次更新既为每位开发者带来更快速可靠的 CI/CD 体验，又为 GitHub 代理平台构建了可扩展、灵活且安全的执行层。
我们的目标是确保 GitHub Actions 持续满足大型企业与个人开发者的需求，通过清晰的定价体系、更强劲的性能表现，以及面向未来十年软件开发的产品方向实现这一目标。
常见问题
为何使用自有硬件会被收费？
历史上，自托管运行器客户能够免费使用 GitHub Actions 的大部分基础设施和服务。这意味着这些核心服务的维护和升级成本，主要由 GitHub 托管运行器的定价来补贴。通过更新定价策略，我们将成本与实际使用量及为每位 Actions 用户创造的价值更紧密地挂钩，同时推动平台的持续创新与投资。绝大多数用户(尤其是个人及小型团队)不会面临价格上涨。
您可通过Actions定价计算器预估未来成本。
新版GitHub托管运行器定价如何？
请查阅GitHub Actions运行器定价参考，了解将于2026年1月1日生效的新定价。所列价格已包含新版Actions云平台每分钟0.002美元的费用。
问：为何采用0.002美元/分钟作为云端自托管运行器的定价？
经用户反馈及市场同类自托管CI解决方案对比，我们认定按分钟计费最为公平精准。此方案既能为轻度及重度用户提供快速灵活的工作负载以保障最佳终端体验，又可实现可持续运营，避免对客户造成显著影响。
本次定价调整涉及哪些 GitHub Actions 任务执行场景？
- 在私有仓库中运行且使用标准 GitHub 托管或自托管运行器的任务
- 所有在大型 GitHub 托管运行器上运行的任务
公共仓库中使用标准 GitHub 托管或自托管运行器仍保持免费。GitHub Enterprise Server 定价不受本次调整影响。
价格变更何时生效？
GitHub托管运行器的降价将于2026年1月1日生效。自托管运行器的新收费标准将于2026年3月1日开始适用。价格变更将在上述日期对所有客户生效。
我的套餐免费配额会改变吗？
自2026年3月1日起，自托管运行器将计入免费配额，其消耗的可用配额将按当前标准运行器(Linux/Windows/MacOS)的定价规则计算。
自托管运行器的使用会消耗我的免费配额分钟数吗？
是的，计费的自托管运行器使用量将消耗您套餐关联的免费配额分钟数。
此定价变更如何影响 GitHub Enterprise Server 客户？
本次定价变更不影响 GitHub Enterprise Server 用户。在 GitHub Enterprise Server 自托管运行器上运行 Actions 作业的客户，可继续免费托管、管理、排查故障并使用 Actions 及其相关实现。
能否通过 Azure 对私有仓库的自托管运行器使用量进行计费？
可以，前提是您拥有与 GitHub Enterprise 或组织关联的有效 Azure 订阅 ID。
此次变更对 GitHub 客户的整体影响如何？
96% 的客户账单金额保持不变。在受影响的 4% Actions 用户中，85% 的用户账单金额将减少，其余 15% 的用户(涵盖所有受影响群体)账单金额中位数增幅约为 13 美元。
GitHub是否考虑了对个人开发者的影响，而不仅限于企业级客户？
在过去一个月仅在私有仓库使用GitHub Actions的个人用户(免费及Pro计划)中，仅0.09%将面临价格上涨，中位数涨幅低于每月2美元。需注意：此影响是在用户已使用当前套餐包含的免费分钟数(可享超过33小时的GitHub计算资源)后测算的，且不影响其免费使用公共仓库的权益。另有2.8%的用户群体将因此次调整而降低月度成本，其余用户不受影响。
如何计算我的GitHub Actions新月费？
GitHub Actions提供当前及过往年度的详细使用报告。您可结合此历史使用数据与将于1月及3月实施的费率调整，估算新定价结构下的费用。我们已创建Python脚本，助您基于完整使用报告计算价格调整后的预期费用。
我们还更新了操作定价计算器，使您更轻松地估算未来成本，尤其当您的历史使用量有限或无法代表预期未来使用量时。
补充资源
- 查看GitHub Actions运行器定价文档，了解自2026年1月1日起生效的新版GitHub托管运行器费率。
- 有关 GitHub Actions 即将发布的版本详情，请参阅GitHub 公开路线图。
- 如需估算预期 Actions 使用成本，请使用全新更新的Actions 定价计算器。
- 查看当前或历史 Actions 使用情况，请参阅文档查看和下载详细使用报告。
- 若需将现有自托管运行器迁移至 GitHub 托管运行器，请参阅文档中的SHR 到 GHR 迁移指南。
本文文字及图片出自 Pricing changes for GitHub Actions
我的理论：某些经理的KPI是增加GitHub Runner分钟数的销售额。于是他们做了些市场调研——虽不足以看清全貌，却已足够危险——发现部分公司出于成本考虑使用自托管Runner。于是他们采取双管齐下的策略：降低GitHub Runner成本，同时对自托管Runner收费，以此激励用户迁移。
这种策略注定失败，实际用户或许早已洞悉其中破绽：
(a) 某些场景下无法迁移至GitHub Runner。对我们而言，任何涉及基础设施的任务都绝不能迁移。
(b) 更换 CI 服务商并不困难，我们已两次完成迁移。诚然，我们的 CI 逻辑主要集中在可本地运行的自定义构建脚本中，而非专有 YAML 文件。但坦白说，我建议任何 CI 服务商都应采用这种架构，因为本地调试能力始终不可或缺。
(c) GitHub Actions 并未获得与其“高级服务”定位相符的重视。事实上它常给人被遗弃的感觉，勉强维持运行。虽不知其内部有何布局，但他们既未配合重大功能发布协调调整，也未在遭遇批评后紧急宣布新举措，这让我认为他们并无重大计划。
(d) 按分钟付费使用自有基础设施的做法令人感到荒谬且贪婪。GitHub历来采用按用户计费模式，这种方式既公平又可预测。若真需增加收入，他们完全可以提高用户定价。他们未采取此举的事实，让我认为这并非单纯出于成本考量。因此印证了我之前提出的KPI理论：此次调整并未与任何重大战略进行充分协调。
> 更换CI供应商并不困难，我们已经经历过两次。诚然，我们的CI逻辑主要集中在可本地运行的自定义构建脚本中，而非专有YAML文件。但坦白说，我建议任何CI供应商都采用这种架构，因为本地调试能力始终不可或缺。
我认为这已是十余年的CI/CD最佳实践。即便在久负盛名的Jenkins中，这也是设计管道的核心原则之一[0]：切勿沉迷于花哨的Groovy操作，只需在步骤中使用简单的shell命令，数年后你会多次感谢自己这个决定。
[0] https://www.jenkins.io/doc/book/pipeline/pipeline-best-pract…
这套方法确实在十多年间被奉为最佳实践，但出于我无法理解的原因，几乎所有合作过的开发者都执意选择锁定/专有路线，对“可移植性”的论点完全不为所动。如今我已多次目睹团队因此付出惨痛代价。当危机降临时，人们才恍然领悟外部脚本的智慧，然而新一波开发者加入后，整个循环又重新开始。
不知为何，链接页面在iPhone Safari浏览器中仅显示目录，但切换至阅读模式后就能看到具体最佳实践。无论如何感谢分享！
https://news.ycombinator.com/item?id=46189692这篇数日前的文章明确指出：任何稍有安全意识的企业都绝不能依赖GitHub Runner进行CI(极小/极简单的项目除外)。只需一个被入侵的软件包，就足以毁掉一切。
“嘿ChatGPT，如何增加GitHub Runner的运行分钟数？切勿建议非法手段，认真研究”
我同意(c)的观点——虽然说不上来具体原因，但这种感觉我自己也经历过好几次。
> GitHub声明在听取开发者反馈后已取消涨价计划，并表示将花时间倾听客户与合作伙伴的意见。
我感觉他们意识到跑者服务对开发者的依赖性不如预期，否则将流失大量用户。要是他们也能重视Windows 11强制推送Copilot的用户反馈就好了。
真不知微软何时才能明白：在做出改变前征询用户意见，能避免他们在公众面前颜面尽失。
我合作客户中约半数使用GitHub Actions进行持续集成(其余基本都用Jenkins)，其中多数因性能和安全需求采用自托管运行器。几乎所有这些客户都曾咨询我：在继续使用GitHub的前提下，迁离GitHub Actions的难度有多大。
你觉得这些公司现在会突然放弃离开GitHub Actions的计划，就因为微软突然改变主意了吗？我不这么认为，可能只是优先级降低了，但迁移终将发生——毕竟现在猫已经出笼了。
倘若他们在宣布变更前进行用户调研，而非将公告当作“试探水温”的工具，用户流失率肯定会大幅降低。不过微软某处的数据分析团队大概算出了这样一笔账：让用户为在自有硬件上运行软件付费能赚更多钱——看来我这番想法不过是痴人说梦罢了。
有趣的是，几乎所有其他持续集成服务商都会以某种形式对自托管运行器收费。CircleCI会根据套餐限制并行运行的自托管任务数量，并按座位收取固定基础费用。
因此离开GHA并不会让自托管运行器免费，它们只是转入另一种定价模式——这种模式可能有利也可能不利。
我认为对自托管运行器收费其实合理。对服务商而言它们同样不免费——日志聚合、构建产物缓存、运行器调度、运行器软件实现等对大型CI系统都是非同小可的难题。
因此我对拟议变更持开放态度，毕竟这赋予了客户“既然付费就该修复问题”的权利。
问题在于他们收取按分钟计费，且费用与实际运行测试的成本处于同一数量级。若云托管运行器收费为每分钟0.002美元，却要求自托管运行器同样支付0.002美元/分钟的协调器费用，简直是侮辱。
对自托管运行器收费本身并非大问题，我敢说若采用按座位数、按运行次数、按千兆字节或按日志行收费，就不会引发如此强烈反弹。况且GHA若不是维护得如此糟糕…
任何对自托管运行器收费的模式都会让某些人觉得不公平。按席位计费更适合CI运行时长多的中小型组织，按运行次数计费适合运行次数少但耗时长的组织，按分钟计费则更适合频繁进行小规模运行的组织。
据我观察，批评声浪主要源于对收费事实本身的愤怒。
我认为对通用GHA基础设施收费是合理且公平的，毕竟自建运行器用户同样会使用这些基础服务。
我怀疑他们并非想通过收费盈利，而是试图以此作为强制手段推动用户使用利润率更高的托管运行器——但这一策略并未奏效。多数反馈并非“该死，这让替代方案在经济上毫无吸引力”，而是“只要不用那些糟糕的托管运行器，我当然愿意支付这些费用”。
这取决于用户是否使用其他CI服务商或自行运行Jenkins。
但需注意，Circle CI的费用是已知成本。而目前唯一确定的是GitHub将开始收费，其新定价模式尚不可知。
完全自建CI系统是另一种权衡。软件本身免费(前提是使用自由软件)，但你将承担运维开销。我并非认为这是不合理的选择，但绝非零成本的替代方案。
GitHub控制计划的成本与运行器成本并不等同。然而新方案似乎将自托管分钟与托管分钟等同计算——自托管分钟同样计入2000分钟的免费额度。
> 其实我对拟议变更持开放态度，因为这赋予了客户“既然付费就该修复问题”的权利。
目前我为GitHub Actions付费却毫无申诉渠道(除了离开)。付钱根本改变不了现状。
若GitHub Actions不再如此不稳定且令人沮丧(无论托管或自托管运行器，我两者都用)，我更愿意付费。至少自托管运行器成本更低且性能更优。
> 若GitHub Actions不再如此不稳定且令人沮丧(无论托管型还是自托管型运行器，我两者都用过)，我更愿意付费。
这确实是我考虑离开GHA的原因之一。该产品模块的投入不足显而易见。不过他们确实宣布了价格调整后将投入大量资源开发新功能(对我们而言很实用)，我会关注产品亟需改进的方面是否有所变化。
GitLab此时登场，其自托管运行器堪称免费啤酒般的慷慨(维护成本存在，但运行器数量无上限，且除按用户计费外无其他收费)。
然而。
GitLab过去曾证明，在吸引足够多用户迁移后，他们完全乐于将价格抬高至GitHub之上。
是的，GitLab 确实仍提供免费的自托管运行器。不过另一方面，GitHub 有免费组织方案而 GitLab 没有。所以严格来说自托管运行器是免费的，但你需要为开发者席位付费。
不过我们已经为 GHA 的“控制平面”付费了。
这无异于说我们应该按PR和Issue付费——毕竟这些功能不可能完全免费，对吧？
具体如何付费？基础组织方案是免费的，包含GHA访问权限和2000分钟免费时长。
升级方案后可获得更多免费分钟数——这些分钟数会被免费运行器的消耗所抵消。官方尚未明确自托管运行器消耗免费分钟的具体速率，但至少对我们而言，此次变更将大幅消耗免费分钟。
> 你倒不如说我们应该按PR和Issue付费，毕竟那部分总不能免费吧？
你曲解了我的意思。我只是说基于这些理由我接受这个方案。这是我的个人立场，并非要求你效仿或认同。
我为GitHub Pages支付(相当可观的)费用，因为目前它确实提供了物有所值的服务。我宁愿看到GHA成为盈利项目，也不愿它沦为二流服务长期拖延——就像他们宣布改版前那样。
租个专用服务器，安装Gitea，配置Gitea动作运行器。私有化、安全可靠、低成本的Git托管服务，兼容99%的动作。
微软在90年代曾对此极为重视。据《Showstoppers》记载：正式发布前，微软向外部开发者提供了三批次NT 3.1测试版。
如今的理念是快速迭代、打破常规(只要别砸到钱包或腿)。
我也是这么想的。昨天刚配置好Forgejo，今天就打算评估它的运行器，甚至考虑直接用专用的CI工具如啄木鸟。
开源仓库的处理方案尚未确定，但私有仓库我已着手迁移。
出于隐私考量(特别是担心私有仓库被用于训练AI)，我本就计划这么做，这次事件恰好成了推动力。
> 要是微软能听取关于Windows 11和强制推送Copilot的反馈，或许真能有所突破。
Copilot可以直接卸载吗？我的Surface Laptop 7装W11系统里根本找不到它。
强制更新Windows后它又出现在我设备里了，真烦人。而且电视端似乎也即将强制推送，还无法卸载。
> https://www.tomshardware.com/service-providers/tv-providers/…
因此推测他们会继续在操作系统中强制推送该服务并不为过。
为何用户必须采取行动抵制？优质产品无需强迫推广，在Windows数十个广告位中投放一条烦人的广告就足够了。人们甚至愿意为ChatGPT和Claude付费，而这些工具既没有操作系统广告位，也不强制安装。
目前如此
我已经跳槽了。更换源代码托管服务其实相当简单，构建流程依然运行良好。
太棒了！你转投哪家平台？
最明显的“全功能”方案是GitLab——只要硬件够用且不介意些许臃肿，所有必要功能都集成在单一平台。
个人认为，对于仍需网络协作的小型项目，Gitea/Forgejo + Woodpecker CI 组合堪称极简轻量且易于维护的解决方案。
我正在自建Forgejo。其他CI工具有哪些我可能需要却缺失的功能？
若您使用内置的Actions/CI/或其他类似工具且运行良好，那就继续用吧，不必刻意更换 🙂
我坚持使用Woodpecker主要是因多年习惯使然。两者方案都未见重大缺陷，不过我已许久未深入研究，或许有人掌握更(近期)的细节。
我真心喜欢Gitlab CI。虽然不怀念管理自有Gitlab服务器的日子，但他们的CI产品确实比Actions更胜一筹。
我们也跳槽了。Forgejo的表现令人惊艳。
> 要是他们能听听关于Windows 11和强制推送Copilot的反馈就好了
我觉得他们会得出相反的结论。Copilot没让他们流失多少用户，因为Windows用户被生态系统锁死无法离开。他们会试图让GitHub陷入类似境地，然后再搞这种破事。
我觉得自己完全能够设计并实现一套CI工作流系统，其性能将远超GitHub Actions(至少针对单一组织的工作流而言)。而部署该系统的复杂度，仅比托管GitHub Actions自托管运行器略高。
技术栈架构如下：
Postgres 作为任务队列和状态追踪器，整个控制平面状态都存储于此。即便在大型组织中，其事务处理频率也极其低。
数据采集代理：监控仓库推送和PR动态。
任务代理。在沙箱环境中运行，从GitHub获取输入参数，执行实质性的工作流步骤。该代理不接触任何机密信息——所有操作均通过JSON输出、二进制大对象输出，或针对无法采用JSON输出模式的操作而设计的组织专属API实现。
结果处理组件。该组件作为连接数据库的简单服务，接收JSON任务结果并执行后续操作(主要包括对PR添加评论或更新CI状态仪表盘)。对于持续交付工作流，构建产物将发送至指定的注册库。
配置系统：以文件形式存在于某个位置(例如独立于CI运行仓库的Git仓库中)。(GitHub将Actions配置嵌入仓库的模式在我看来完全错误。)
大致如此。
我并非声称能在周末复制GitHub Actions的功能。但我也无意如此。这将是一个单租户系统，仅支持组织实际使用的功能。甚至像单点登录这类常规功能都无需考虑——因为整个系统本身就不存在用户概念 🙂
在当前环境下，我不明白为何此文被如此多地反对。
我猜是因其人工智能驱动的思路。这类关键基础设施，总需要多双眼睛把关才能做得更好。提出“我直接用Claude重构，无需了解底层架构”这类不负责任的观点，难免触动某些神经，还可能引入底层漏洞、可利用点等隐患。
虽然对被点赞的用户不公平，但我认为值得探讨我们该如何划定界限。
编辑：我认为AI是工具而非替代品。
唉。我本该说明“氛围编码”部分的含义。这个项目整体代码量其实很小，完全可以由人类编写——既无需投入海量开发时长，借助AI辅助(全程人工闭环)还能更快完成。
我的核心观点是：GitHub Actions本身是个特殊产品。许多大型云服务看似解决简单问题，实则需求远比表面复杂，而替代方案并不复杂。但GitHub Actions尤其堆砌了大量冗余功能，却未能有效解决核心问题；定制化的小型方案反而更优。
1. 宣布涨价引发负面舆论。
2. 发布博客假装理解用户诉求并采纳反馈，同时“暂停”涨价以平息舆论。
3. 待负面舆论浪潮平息数月后，趁旧闻不再引发新报道时悄然实施涨价。
不行，当变革实质如此剧烈且直接影响用户实际收益时，这种策略行不通。若他们拖延数月再尝试，用户账单将立即上涨，必然引发新一轮愤怒。不知GH下一步会怎么做，但若重蹈覆辙，必将适得其反。
若有人给你时间消化，你愿意妥协的程度可能超乎想象。
关键在于给予足够时间，让你从愤怒/震惊/恐惧转向接受。这如同魔法般屡试不爽。
> 呃，这种方法在某些时候行不通……
听起来像是心理过程中的另一个经典阶段——否认。否认阶段你会告诉自己“不可能发生”来寻求安全感，而实际上你已悄然迈向接受——接受即将离开的现实，或接受必须付出代价的结局。
当他们最终推行时(他们必定会推行，历来如此)，所有人都有充足时间计算利弊，要么制定应对方案，要么吞下苦果。
若数月后你仍在抱怨，那便是咎由自取，毕竟早已得到警告。
大量证据表明事实并非如此。
这种情况屡见不鲜，Atlassian推行“仅限SaaS”策略就是典型案例。
听起来他们正加紧供应商锁定策略，确保产品与其他解决方案的兼容性下降。
我担心这会成为必然结局。
如果真是这样，那他们根本不了解开发者。几个月后我们抱怨的程度会和现在一样激烈。
自从鲍尔默时代以来，他们就没表现出理解开发者的迹象。
听起来像是聊天监控。
我也这么认为。
个人觉得这完全是小题大做。他们的定价在我看来很合理。太多人习惯不劳而获了。大多数公司最终会接受新价格，因为开发和部署替代方案所需的时间成本(计入工程成本后)远高于直接支付给GH的新费用。
不，这里涉及的资金规模相当可观。通常自建服务器的人都在满负荷运行跑者(否则按分钟计费更划算)。因此新政策将使他们的服务器成本翻倍。试想某公司每月自建跑者开支1.5万美元，现在还要额外支付GitHub每月1.5万美元的费用。
面对这种金额，很多人会选择转投他处。
我们为运行器配备专用服务器，每台配置16+核CPU和64GB+内存，月均成本低于2000美元。此次定价调整产生的费用将超过现有服务器开支。
官方声明如下：https://x.com/github/status/2001372894882918548
"我们已阅读各位的帖文并听取反馈。
"1. 现决定推迟此前公布的自托管GitHub Actions计费变更，以便重新评估方案。
"2. 托管运行器价格仍将于2026年1月1日下调最高39%。
"运行Actions控制平面确实存在实际成本。我们同时正在投资自托管运行器，以确保其在客户环境中实现大规模运行，尤其针对复杂的企业场景。尽管这些背景因素至关重要，但此次调整未能充分纳入更多用户的意见，实属失策。
“我们需要改进GitHub Actions。首先将投入更多时间与开发者、客户及合作伙伴深入沟通。我们已开启讨论通道收集直接反馈，并将据此制定GitHub Actions路线图。通过在GitHub Actions及整个平台的持续交付，我们正全力赢取大家的信任。”
工作之余，我只是个断断续续的程序员。在某些使用Actions的副业项目中，我常经历灵感迸发的几天高效推进，随后便是数周/数月/数季度的完全停滞。
免费Actions的取消并不让我特别困扰，支付可能微不足道的费用也完全没问题，但我实在不愿绑定信用卡——万一账户遭入侵，可能面临无限额扣款风险。出于类似顾虑，我已关闭个人AWS账户。
是否有办法仅预存20美元的一次性额度？这笔钱大概能用到2027年，让我安心放任项目运行。若账户遭入侵或配置失误导致失控，我完全愿意认赔这笔钱，让这些风险极低的玩具项目构建失败。
在GitHub设置消费限额，若超额收费就申请退款。
可以参考CircleCI的模式——主要依赖付费用户支撑核心产品，同时提供免费方案。微软目前似乎正在探索降低GitHub免费用户成本的方案，毕竟他们的实际盈利可能来自其他业务板块和产品。
作为偶尔收到过巨额AWS账单的用户，我赞同AI服务商采用预付信用额度系统，并希望其他平台也能效仿。
目前有多家“虚拟信用卡”服务商，允许用户生成附加卡并设置消费限额及授权人。具体可用性因地区而异。
问题在于若系统出错，你仍可能收到巨额账单——当服务商在每日/每周/每月结算时尝试扣款失败，
此时你仍欠款未付，对方会要求你用其他卡支付。若拒绝，他们将启动催收程序，可能导致你的信用评级受损，甚至面临诉讼等后果。
我希望向公司预付一定金额，当资金耗尽时自动知晓并及时充值。虽然可以设置月度限额(https://github.com/settings/billing/budgets)，但像我这样每年有几次需要投入一两周时间处理个人项目的人，这种方式并不适用。
我知道AWS、Azure和GCP都支持全球限额功能。例如Azure在订阅中就提供此项。不确定是否仅限于按月续费模式。预付整笔金额的版本固然便利，但若资金耗尽可能引发服务中断风险。或许这就是未提供该选项的原因？
我想说这条评论颇具洞见。我也渴望采用按需付费模式，这样就能安全地尝试各类SaaS服务。
可惜这不符合SaaS企业的利益诉求——他们更倾向于复制健身房会员模式，让70%不常使用的用户补贴30%高频用户。
现实情况是，你并非他们的目标客户。他们瞄准的是那些已有自建运行环境的企业用户，这类客户根本不考虑切换到Actions服务。
有件事我不明白。GitHub Actions不就是“获取仓库→执行操作→保存结果”吗？这和编写Bash脚本实现“克隆仓库→处理内容→推送变更”有何区别？若Actions变成付费功能，岂不是会催生大量“我在xyz重现了GitHub Actions”的ShowHN帖子？
没错，理论上任何CI/CD工具(GitHub、GitLab、Jenkins等)本质都是带封装的shell脚本。但这种封装至关重要——它关乎便利性：如何与仓库集成、如何处理变量/密钥/缓存、部署安全性等等。有人摸索出方法并推广，其他人再学习应用，因此切换工具总会带来各种麻烦。但这绝对可行——我经手过大量管道迁移，对中小型乃至中等规模项目而言，这绝非阻碍。
其优势之一在于提供全托管服务，无需担心控制平面管理和调度任务。
当然存在成本——尤其当提供托管运行器时(需投入资金购置基础设施运行任务)
另一优势在于可控制代码共享对象。若已使用GitHub托管源代码，则无需额外信任GitHub Actions或新增管理/支付对象
那YAML地狱该去哪里受罪呢？？
在k8s上自己动手搞。那个生态里YAML似乎是无法避免的。:)
没错，已有若干工具能实现相同功能。GitHub Actions的核心价值在于提供日志记录和构建产物存储服务。
这个改动实在奇怪。毕竟能自行搭建运行器的团队，完全可以轻松跳槽到其他CI平台，彻底避开这些费用。
就像Bash脚本，但多了调试功能。
Github Actions堪称最难调试的工具之一，而Bash脚本绝非如此
抱歉，发现前文有误。正确表述应为“它类似于Bash脚本，但不具备调试功能”。我个人并不推崇GHA，认为无人监督的Claude代码本可构建更优的CI系统。
没错，但Bash脚本不具声明性，这似乎很糟糕。
(声明式CI？为什么？？？)
简单明了的语句加几个条件判断就被视为有害。来看看这个被生硬塞进YAML的怪异供应商专属DSL吧。
所谓“推迟”，不过是改天再做罢了。
大势已定。是否继续使用并信任微软，取决于你。
需要说明的是，将某项计划推迟至原定时间之后执行，正是“推迟”的定义。然而，对任何供应商的依赖都属于技术债务，此时审视并评估是否该开始偿还债务，始终是明智之举。
更合适的链接在此：
https://github.blog/changelog/2025-12-16-coming-soon-simpler…
或 https://github.com/orgs/community/discussions/182186
本地运行的操作若使用了GitHub资源(用于日志记录、维护等)，产生相应成本似乎合情合理。具体收费标准尚待商榷。
这是经典的SaaS平台困境。若免费提供，终将耗尽资金——且总有人会通过规模化套利造成实质性损失；若收费，计费系统便会沦为复杂难解的计数器与费率组合，用户根本无法估算和理解。
这绝对不是按分钟计费
按分钟计费本质上只是种人性化的表达方式。按小时、按秒、按天计费最终总金额可能相同，只是数字不同而已。若非要选，按分钟计费比按小时更合理，因为未使用的分钟不会产生费用。
但为何不改为“按摄入日志GB计费”或“按触发任务计费”(或两者兼顾)？这些模式才真正反映GitHub的成本结构——而非按分钟收费。
问题在于计费单位是“按时长”
完全可以改为按工作流计费，与时长无关
那为何除自托管动作外，仓库大小、webhook等所有功能都采用固定定价？
根据推文[1]：
"我们已阅读各位的帖子并听取反馈。
1. 现推迟已公布的自托管GitHub Actions计费变更，将重新评估方案。
2. 托管运行器价格仍将于2026年1月1日下调最高39%。
我们确实存在实际成本"
^ 推文全文更长，但Discord展开预览时在此截断。最后那句堪称致命一击，可怜的老微软啊
1. https://x.com/i/status/2001372894882918548
> 我们承担着真实成本"
我记错了吗？行动运行器里不是有个会让CPU无限循环的漏洞吗？
> https://github.com/actions/runner/issues/2380
> https://github.com/actions/runner/issues/3792
他们不是花了数年才修复这个吗？还是说这无关？
他们讨论的是运行Actions控制平面和调度器的成本——这些组件并不在运行器本身执行。
托管GitHub涉及各种成本，因此企业用户采用按座位计费模式。若现有价格过低，他们随时可以调高。但在此基础上对自有基础设施的每分钟使用额外收费，在我看来实在贪婪。更令人质疑的是，这项收费竟与GitHub维护力度较弱的功能绑定。
最终我在k8s集群上实现了自托管原型https://woodpecker-ci.org/。仅耗费数小时AI时间(Claude Code)就完成开发。Woodpecker提供Helm图表，可连接GitHub并将状态检查结果推送至提交记录。
欢迎反馈或分享技巧，目前进展颇为顺利。好奇其他人的使用体验如何。
看到“5秒广告”的提示，才不会等30秒去读那该死的文章。
可能是企业用户涌入所致，我公司原本死寂的全球开发运维群昨天因此炸开了锅，消息量激增数百条。
太好了，这下我有更多时间迁移出去了。
官方亲口承认：https://resources.github.com/actions/2026-pricing-changes-fo…
这场抗议的声势远超微软预期。虽然对自托管服务收费有其逻辑，但对消费者而言实在说不通。
在自家服务器上运行的Action Runner居然按分钟收费，这种赤裸裸的寻租行径简直厚颜无耻…
按动作收取固定费用尚可理解。GitHub在启动/停止API调用时确实存在微小成本，但若我的构建在自托管运行器上耗时8小时，对GitHub而言成本与10秒耗时并无差异。
这正是自托管运行器的核心价值所在。
或许其他平台存在更多抗议，但坦白说我对Hacker News上看似平静的反应感到困惑。
没错，按分钟计费才是真正的问题所在。这让我觉得他们故意先推出最糟糕的方案，好让用户被迫接受后续调整的工作流程。
我甚至不明白他们怎么敢这么做。你掌控着提供响应的服务器，完全可以篡改起止时间数据坑他们一把，说不定还能在他们烂代码里找漏洞，逼得他们给你补费。
我觉得他们自掘坟墓的具体方式有三点(在极客圈可能不算问题)：
在创纪录停机的一年宣布涨价，时机实在不妙…
https://archive.ph/3nsGi
> 尽管去年我们为支持开源项目免费提供了115亿构建分钟(约合1.84亿美元)
有趣，我正试图估算他们每年在免费操作上的支出。原以为大概在1亿美元左右。这是我看到的第一个实际数字。
我认为1.84亿美元这个数字应该是收购价格而非GitHub的实际成本，考虑到竞争对手提供相同服务的价格仅为其3-10分之一，我估计实际总成本可能更接近8000万美元。
即便如此仍是巨额资金，我认为任何竞争对手都难以企及。
好奇这8000万美元中有多少是安全睡眠脚本这类垃圾代码
建议更新文章链接：
GitHub Actions定价更新 https://github.com/orgs/community/discussions/182186
是啊，能不能别再把推特当作公司官方通讯渠道了？总会有博客公告的，这次明明有GitHub讨论页。
那条更新来自匿名“管理员”。而X平台链接直接指向GitHub(疑似？)负责人。
他们也更新了原始资源页面，但新网址更符合我们的需求https://resources.github.com/actions/2026-pricing-changes-fo…
另请参阅：
– https://news.ycombinator.com/item?id=46304379
– https://news.ycombinator.com/item?id=46305216
嗯，还是太晚了，还是要离开。
或许是我理解有误，但自托管的GitHub Actions比托管在GitHub上的版本更耗资源？
GitHub Actions或许存在某些创新用途，吸引用户入驻平台似乎颇具价值。
太好了，个人项目的迁移可以暂缓了。
或者说，你有了更多时间来执行迁移。他们绝对会再次突然涨价，这可是微软啊。
这是经典策略：抛出极端改动方案，假装“听取反馈”，然后在后期推出他们原本就打算收取的价格。
我感受到的信号正是如此，他们甚至毫不掩饰，只是在推迟某种必然的涨价措施。
正如云平台无关性意味着你应能在不同云端初始化基础设施，这同样适用于你的持续集成/持续交付(CI/CD)。作为资深系统管理员，我的建议是：立即将CI/CD与运行平台分离。
https://www.slingacademy.com/article/git-post-receive-hook-a…
另一项技巧是将容器化方案与之结合——我目前使用system-nspawn，但原理同样适用于其他容器工具。
谁能想到呢
相关动态：
初期开发与市场反响：
GitHub Actions定价调整
https://news.ycombinator.com/item?id=46291156
庆幸七年前就迁移到GitLab了。
与Actions无关。这条推文的作者Jared Palmer发展得不错。我记得他是Turborepo的作者，几年前被Vercel收购了。
https://jaredpalmer.com/about