Dora NodaGitHub tried to charge you two-tenths of a cent (USD 0.002) for every minute your own computer ran your own CI jobs — and the only reason you are not paying it today is that developers yelled loud enough, fast enough, to get the plan shelved.
That is the short version of the strangest pricing episode in recent CI history. In mid-December 2025, GitHub announced a new "Actions cloud platform charge" of USD 0.002 per minute that would apply to self-hosted runner usage starting March 1, 2026. Self-hosted runners — the machines you buy, patch, scale, and pay the power bill for — would start metering minutes to GitHub anyway, because the orchestration layer scheduling those jobs belongs to GitHub. Within days, after what one outlet called a community revolt, GitHub postponed the charge indefinitely, admitting it had "missed the mark" by not including users in the planning. The charge never took effect. There is no new date — and no guarantee it won't return in a different form.
The reversal is good news. But the episode deserves a close read anyway, because it revealed something structural: a CI vendor's instinct to meter compute a team already owns, just because the control plane is theirs. So let's do the math the announcement implied, look honestly at GitHub's side of it, and ask what "postponed indefinitely" should mean for your planning.
The math: what two-tenths of a cent per minute actually costs
Two-tenths of a cent per minute sounds like nothing. It isn't nothing at CI scale. USD 0.002/minute works out to USD 0.12 per compute-hour, which means a single runner running flat-out costs about USD 86 a month in platform charges alone — roughly USD 1,037 a year — before you count a dollar of the hardware underneath it.
Here's what the shelved charge would have added to three typical private-repo teams, stacked on top of infrastructure they already pay for:
| Team profile | Self-hosted minutes/month | New platform charge |
|---|---|---|
| Small team, a few services | 10,000 | ~USD 20/month (~USD 240/year) |
| Mid-size team, monorepo + matrix builds | 50,000 | ~USD 100/month (~USD 1,200/year) |
| Heavy CI shop, ephemeral fleets at scale | 200,000 | ~USD 400/month (~USD 4,800/year) |
One honest caveat favors GitHub here: the charge would have counted toward the minutes included in your plan, so a small team sitting comfortably under its included quota would likely have seen USD 0 in new bills. That mechanism is a big part of why GitHub claimed 96% of customers would see no change. The teams actually paying were the ones whose self-hosted usage exceeds included minutes — which is to say, exactly the teams that invested the most in owning their CI infrastructure. The heaviest self-hosters, the ones saving GitHub the most hosted-compute cost, would have paid the most for the privilege.
And remember what sits underneath those numbers: every minute in that table is a minute the team already paid for once. The VM or bare-metal box, the bandwidth, the storage, the patching, the 3 a.m. runner outage — all theirs. The platform charge was a second bill on the same minute, levied not for compute but for scheduling.
Why it stung: a meter on orchestration, not compute
To understand the backlash, separate the two things a CI bill can meter. The first is compute: CPU-minutes, memory, GPUs — stuff with a marginal cost per use. Everyone accepts paying for that, or equivalently, buying the box and running it free. The second is orchestration: receiving the webhook, queuing the job, dispatching it to a runner, collecting logs. That is real work with real servers behind it, but its cost has nothing to do with how long your test suite takes.
GitHub's charge metered the second thing with the first thing's meter. A 45-minute integration suite on your own hardware would have cost nine cents of "cloud platform" — not because scheduling it cost GitHub nine cents more than scheduling a 45-second lint job, but because minutes were the available dial. Self-hosting has always meant a clean trade: you absorb the operational burden, and in exchange the marginal minute is free. The platform charge broke that trade while leaving the burden exactly where it was. Same patching, same scaling, same firefighting — plus a meter.
That is why the announcement read, to many teams, as a tax on an architectural choice rather than a price for a service. Nobody objected to hosted runners costing money; hosted runners are someone else's computers. The objection was to paying per-minute for your own computers because the dispatch layer lives in someone else's cloud. Once you accept that orchestration-of-owned-compute is meterable, there is no natural ceiling: today's USD 0.002 is tomorrow's USD 0.004 with a straight face, because the number was never anchored to a unit cost you can audit.
The vendor's case, steelmanned
Fairness requires saying GitHub's side at its strongest, because it isn't empty. The Actions control plane genuinely costs money at scale: job routing, queueing, artifact and log storage, the API surface that third-party autoscalers like Actions Runner Controller hammer all day. Self-hosted minutes have been growing fast, and every one of those minutes rides GitHub's orchestration for free while the company eats the infra, engineering, and support cost. SVP Jared Palmer's defense — that the charge "aligns pricing to match consumption and our cost patterns (infra, eng, and support) as usage grows across both hosted and self-hosted" — describes a real cost curve, not an invented one.
The packaging was also, on paper, generous: GitHub-hosted runners got up to 39% cheaper on January 1, 2026 (with the platform charge already folded into the reduced meter price), public repositories stayed free on both hosted and self-hosted runners, and GitHub Enterprise Server customers were untouched. If you squint, the story was a rebalancing — cheaper managed compute, plus a small platform fee that 96% of customers would never notice — not a shakedown.
Where the case breaks down is the choice of meter, not the existence of cost. A flat platform fee per organization, a per-runner connection fee, a quota on control-plane API calls — any of these would track the actual cost (orchestration load) more honestly than a per-minute tax pegged to how long your own hardware stays busy. GitHub picked the meter that grows with your compute, which is precisely the meter a self-hoster chose to escape. The backlash wasn't "we refuse to pay for anything"; it was "this meter measures the wrong thing."
What "postponed indefinitely" actually means for your planning
Here is the current state, pieced together from GitHub's updates and community trackers: the self-hosted platform charge is postponed indefinitely, it never took effect, self-hosted runner usage remains free, and the 39% hosted-runner cut did take effect on January 1, 2026. GitHub says it is taking time to meet and listen to developers, customers, and partners. There is no new date.
Read that the way an operator should: no charge, no timeline, no guarantee. GitHub's leadership was explicit that the infrastructure costs behind the proposal remain unsolved. An unsolved cost with a shelved price is not a resolved issue; it is a parked one. The meter can return in a different form — a revised rate, a different unit, a bundled plan change — and next time it may arrive with the consultation this round lacked, which will make it harder to argue against on process grounds.
Three practical postures follow from that:
- Budget the line item anyway. Run your last three months of self-hosted minutes through the USD 0.002 rate. For most teams it lands between "rounding error" and "one engineer-day a month" — worth knowing exactly, because the next proposal will be debated in dollars, not principles.
- Know your exit cost before you need it. The charge applied to GitHub's orchestration of your runners; runners orchestrated elsewhere (Buildkite agents, Woodpecker, Forgejo Actions, plain Jenkins) were never in scope. You don't need to migrate — you need a one-page note on what migration would cost, so a future announcement meets a prepared team instead of a panicked one.
- Watch the hosted-runner price, not just the self-hosted one. The 39% cut changed the build-vs-buy crossover for real. If your self-hosted fleet exists partly because hosted minutes were USD 0.008 a pop, re-run that comparison at the 2026 rates; some teams will find the managed option now wins on total cost once engineer time is honestly priced.
The deeper lesson is about where meters live. Every "free if you self-host it" arrangement is a policy, not a law of physics — it holds until the vendor's cost curve says otherwise. The GitHub episode is the clearest recent demonstration that the orchestration layer is the part vendors can meter even when you own everything underneath. Design your platform bets accordingly: prefer setups where the scheduler, the runner, and the machine all answer to you, so no single vendor's pricing update can put a meter between your code and your hardware.
That is also why a git-push PaaS whose build step runs entirely on the tenant's own fleet never has this meter to begin with. When the control plane and the compute are both yours — provisioned as code on machines you own, with no per-minute dispatch layer owned by a third party — there is no seam for an orchestration charge to attach to. The build costs what the machine costs, full stop.
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.
