Dora NodaIn mid-December 2025, GitHub published the best and the worst CI pricing news of the year in a single announcement. The good news: hosted runner prices would fall by up to 39% on January 1, 2026. The bad news: a new $0.002-per-minute "Actions cloud platform charge" would start applying to self-hosted runners — machines GitHub doesn't own, power, or maintain — on March 1. Developers revolted within hours, and GitHub postponed the self-hosted charge less than a day later. The cuts shipped; the tax never did.
That 24-hour reversal is the most instructive pricing episode CI has produced in years. It drew a bright line around a question every platform that ships builds will eventually face: how far can you push metering compute you don't own before the customers who own it revolt? This post runs the actual numbers — the new price list, the monthly-bill math, and a worked hosted-versus-self-hosted comparison — and then takes the design lesson seriously for any git-push PaaS deciding whether build minutes should be metered at all.
The 24-hour reversal, in 60 seconds
The timeline matters because of how compressed it is:
- Mid-December 2025: GitHub announces simpler Actions pricing. Hosted runner base rates drop across the board effective January 1, 2026, paired with a new $0.002-per-minute platform charge on all Actions workflows. For hosted runners the charge is folded into the reduced meter price; for self-hosted runners in private repositories it would begin March 1, 2026.
- Within hours: backlash erupts on Reddit, Hacker News, and GitHub's own community discussions. The top-voted Reddit reaction captures the mood: "Wait what?? When I use self hosted runner and pay for the infra I need to pay M$ as well?"
- Less than a day later: GitHub postpones the self-hosted billing change indefinitely "to take time to re-evaluate our approach," admits it "missed the mark" by not including more customers in planning, and opens a public feedback thread (community discussion #182186).
- January 1, 2026: the hosted-runner cuts take effect as planned. Free minute quotas stay unchanged, public repositories stay free, and GitHub Enterprise Server customers are untouched.
Nine months later the self-hosted charge has never taken effect. Postponed, in this case, has meant postponed indefinitely — but as we'll see in the final section, nothing about the underlying economics that motivated it has gone away.
What the new price list actually says
GitHub published the full old-versus-new table in github/roadmap#1196. Here are the runners teams actually use:
| Runner | Old (per min) | New (per min) | Change |
|---|---|---|---|
| Linux 2-core (standard) | $0.008 | $0.006 | −25% |
| Windows 2-core | $0.016 | $0.010 | −38% |
| macOS 3-core / 4-core | $0.080 | $0.062 | −23% |
| Linux 8-core (larger runner) | $0.032 | $0.022 | −31% |
| Linux 16-core | $0.064 | $0.042 | −34% |
| arm64 Linux 64-core | $0.160 | $0.098 | −39% |
| GPU Linux 4-core | $0.070 | $0.052 | −26% |
| Linux 1-core | $0.002 | $0.002 | 0% |
Two things stand out. First, the headline "up to 39%" lives at the top end of the large-runner catalog; the standard Linux 2-core runner most pipelines run on fell 25%. Second, the cheapest runners didn't move at all — Linux 1-core and arm64 Linux 2-core are unchanged, which puts a visible floor under the "rebalancing": the smallest meters had no room left to cut.
Translate that into monthly bills for a private repository running standard Linux 2-core minutes (gross, before the included free quota of 2,000–3,000 minutes on paid plans):
| Monthly minutes | 2025 bill | 2026 bill | Proposed self-hosted fee (counterfactual) |
|---|---|---|---|
| 5,000 | $40 | $30 | $10 |
| 20,000 | $160 | $120 | $40 |
| 50,000 | $400 | $300 | $100 |
| 200,000 | $1,600 | $1,200 | $400 |
The typical mid-size team in the middle rows saves $40–$100 a month from the cuts — real money, but not transformative. GitHub's own framing was that 96% of customers would see no change to their bill. The genuinely transformative column is the last one: the fee that never shipped. A team running 200,000 self-hosted minutes a month on its own hardware would have owed GitHub $400 a month for orchestration alone — one Reddit commenter ran their numbers and arrived at roughly $3,500 a month extra. That asymmetry, a modest discount on GitHub's compute paired with a brand-new meter on yours, is what detonated.
Why metering customer-owned compute revolted
GitHub's defense was coherent on its own terms: self-hosted runners still consume the Actions control plane — scheduling, orchestration, logs, workflow management — and those costs had historically been subsidized by hosted-runner pricing. At 70 million jobs a day and 11.5 billion free minutes served to public repositories in 2025, the control plane is genuinely expensive to run. Almost nobody in the feedback threads disputed that something has a cost. They disputed the meter. Three structural objections kept recurring:
1. Wall-clock billing mismeasures control-plane cost. The fee was denominated in the same per-minute unit as compute, including GitHub's per-minute rounding: run for 5 seconds, billed for a minute; run for 61 seconds, billed for two. But scheduling a job and storing its logs don't cost more because the job ran longer. As commenter Matthew Ary argued in the feedback thread, per-minute billing fundamentally misrepresents the costs involved — the billing unit for self-hosted shouldn't be time-based at all.
The community kept proposing alternatives that track actual control-plane consumption instead: flat per-job pricing, a free self-hosted allowance, billing on log volume.
2. Slower hardware pays more for the same job. Under a per-minute model, a team running donated older machines — one volunteer organization said exactly this — pays more than a team on fast silicon for identical work. "Slower builds directly result in higher costs," they wrote, calling the proposal backwards. A university research lab running an NIH-funded genetics desktop app said the charge would likely make its autoscaled self-hosted setup unaffordable, slowing "the pace of development and deployment of important cardiovascular genetics research." A meter that punishes the teams with the least hardware budget is a strange way to fund shared infrastructure.
3. Self-hosting is often mandatory, not a cost dodge. Multiple commenters pointed out that runners touching Vault, S3-compatible internal storage, or other sensitive systems can't be GitHub-hosted at all — the alternative is punching firewall holes for GitHub's fleet. "We shouldn't be penalised for choosing security over convenience," wrote Simon Oakes. When self-hosting is the secure architecture, a per-minute fee on it reads as a tax on doing the responsible thing.
Blacksmith CEO Aditya Jayaprakash gave the episode its sharpest summary: GitHub was trading lower-margin compute revenue for higher-margin platform revenue, establishing "a floor on what GitHub earns from CI, regardless of where jobs run." Rational — and precisely why it felt extractive to the people standing on that floor.
What self-hosting actually costs now
With the charge shelved, the economic gap between hosted and self-hosted minutes is wider than it has ever been. Here's a worked comparison for the same 20,000-minute monthly workload from the previous section. Hardware pricing uses the TestFlows project's public cost math for a 2-vCPU Hetzner Cloud VM: CX22-class, about €0.006/hour — roughly $0.00011/minute, capped near $5/month:
| GitHub-hosted 2-core | Self-hosted (owned VM) | |
|---|---|---|
| Compute, 20,000 min/mo | $120 | ~$5 (flat monthly box) |
| Platform fee | included in rate | $0 (proposed $40 — postponed) |
| Total | $120 | ~$5 |
Per minute, that's roughly a 56x gap ($0.006 versus $0.00011) — before counting that the flat-rate box also absorbs idle capacity, caching, and preinstalled tooling that make builds faster. And the counterfactual column tells the real story of the reversal: the proposed $40 platform fee would have cost eight times the hardware it ran on. At an 8-to-1 ratio of fee to hardware, "covering control-plane cost" stopped being a legible explanation — GitHub was asking self-hosters to pay a multiple of their infrastructure bill for orchestration, on infrastructure GitHub never touched.
Break-even math makes the same point from the other direction. A ~$5/month box against a $0.006/minute hosted rate pays for itself at roughly 830 billable minutes a month — a team that exhausts its included free quota breaks even almost immediately, and everything past that is margin. That is why the self-hosted runner ecosystem (from plain persistent runners to autoscaling fleets like TestFlows' Hetzner setup) keeps growing despite the operational overhead: the price umbrella is enormous.
None of this means self-hosting is free in the full sense — someone patches the runners, manages autoscaling, and debugs the 3 a.m. disk-full. But those are fixed operational costs that amortize across every minute you run, while per-minute billing scales linearly with success. The teams that self-host have already done this arithmetic. The backlash was the sound of a vendor discovering its customers can do arithmetic too.
The design question for any PaaS that ships CI
Strip out the GitHub specifics and the episode leaves a clean decision tree for any git-push platform deciding how tenant builds are priced:
- Meter build minutes and you inherit GitHub's problem in miniature: every minute a tenant's build runs on your owned runners becomes a line item to justify, a rounding policy to defend, and a coupling between tenant success (more deploys) and tenant pain (a bigger bill). GitHub could at least point at hyperscale control-plane costs; a PaaS running builds on a handful of owned Hetzner machines has no such story, because the marginal cost of one more build minute on an already-paid-for box rounds to zero.
- Keep builds unmetered and CI becomes the differentiator instead of the friction: push, watch it build, pay nothing per minute. The cost is real but fixed and plannable — a fleet of runner machines at flat monthly rates — which is exactly the cost structure self-hosting teams already prefer, as the previous section showed.
The second option is the side of the line worth building on. A self-hosted PaaS that owns its runners outright can offer what GitHub structurally cannot: builds whose marginal price is zero because the hardware is already bought. No per-minute meter, no rounding fights, no penalty for slow test suites or volunteer hardware — the three objections from the feedback threads, answered by architecture rather than by pricing-page prose. When the industry's most hated pricing move of the year was putting a meter on customer-owned compute, "we put no meter on anything" is not just positioning; it's the product decision the market just voted for.
Postponed is not dead: what to watch
The current status is genuinely good for self-hosters: hosted prices are down, the self-hosted charge never took effect, and GitHub says it is still listening. But postponed is not cancelled, and the economics that motivated the charge — 70 million jobs a day of control-plane load, much of it on hardware GitHub doesn't bill for — haven't changed. Three signals would indicate a second attempt is forming:
- A new billing unit. The feedback thread's most constructive proposals — per-job pricing, a self-hosted free allowance, log-volume billing — all fix the wall-clock objection. If GitHub returns with one of these instead of per-minute metering, expect far less resistance and far faster adoption.
- Self-hosted feature gates. GitHub's announcement leaned on promised autoscaling tooling and runner improvements. Watch whether new self-hosted capabilities arrive free or bundled with a future paid tier — the latter is the salami-slicing version of the same revenue goal.
- Third-party runner pricing moves. Providers like Blacksmith and Namespace exist in the gap between hosted rates and raw hardware. If their unit economics shift suddenly, it's often the earliest sign the platform math underneath them is moving again.
Until then, the lesson stands as written in December: CI vendors can cut the price of their own compute all they want, but the minute they put a meter on yours, you'd better have a better answer than "trust us" — because your customers have spreadsheets, and they know how to use them.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
