GitHub announced a $0.002 per minute charge on self-hosted runners on December 16, 2025, then postponed it the next day after backlash from users who pay for GitHub already. The fee never billed anyone. It does not follow that self-hosted runners are free. Maintenance hours, credential management, and idle capacity were costing teams money before the announcement and still are after the reversal.
TL;DR
- GitHub proposed a $0.002/min self-hosted runner fee on December 16, 2025, for March 2026
- Community backlash was fast. GitHub postponed the charge within 24 hours
- GitHub-hosted runner prices still dropped up to 39% on January 1, 2026, unaffected
- The fee going away does not retire the maintenance and security cost questions it raised
A five-minute skim of GitHub's own community discussion tells you more about the actual economics of self-hosted runners than most vendor guides do, because the objections are specific: real dollar figures, real hardware constraints, a real admission from GitHub that they got it wrong.
Here is the timeline, then what it should actually change about how your team thinks about self-hosted runner cost.
If your team is weighing self-hosted runners against GitHub-hosted, we can walk through the current numbers before you commit either way. Talk to CrossTecch.
What GitHub actually announced, and reversed
GitHub's changelog on December 16, 2025 announced two changes bundled together: GitHub-hosted runner prices would drop by up to 39% starting January 1, 2026, and a new $0.002 per minute charge would apply to self-hosted runner usage on private repositories starting March 1, 2026.
The reaction on GitHub's own community discussion board was immediate and specific. One frequently cited comment: "We already pay for the control plane, to the tune of thousands of dollars." Volunteer maintainers and nonprofits pointed out that per-minute billing would make older, donated hardware uneconomical to keep running. Others raised the more basic question of whether per-minute billing reflected the actual cost of a control plane at all, versus a flat fee or per-job model.
GitHub's response came the same day. A GitHub Community Admin posted that the self-hosted charge was being postponed "to re-evaluate our approach." The admission was direct: "We missed the mark with this change by not including more of you in our planning." The hosted-runner price cut went ahead as planned on January 1. The self-hosted charge did not.
The bottom line: the fee was proposed and reversed inside 24 hours, which is unusually fast even for a company that ships changelog reversals often.
Why the reversal does not settle the cost question
$0.002 a minute was never going to be the biggest line on anyone's runner bill. It would have added roughly $100 a month at 50,000 self-hosted minutes, which is real money but rarely the number that decides whether self-hosting made sense in the first place.
The objections that got the fee reversed are worth reading again, because most of them are about costs that were already there. "We already pay for the control plane" is an argument that self-hosting was never actually free, fee or no fee. Every self-hosted runner needs its OS patched, its GitHub Actions agent kept current, and its credentials managed so a compromised runner cannot mint long-lived tokens for anything it touches. None of that changed when GitHub backed off.
A team that has never priced its own maintenance hours cannot tell whether $0.002 a minute would have been cheap or expensive relative to what it already pays in engineer time. That comparison is the actual decision, and the reversal did not make it disappear. It just removed the line item that would have forced the comparison.
The rough numbers are out there if you look. A team running around 500 CI minutes a day on Kubernetes-hosted runners tends to spend something like 2 to 4 engineering hours a month on patching, disk cleanup, and log rotation alone, according to one detailed cost breakdown of self-hosted Kubernetes runners. That same breakdown puts general cost-effectiveness starting somewhere around 5,000 to 10,000 monthly CI minutes, and a full break-even against fixed infrastructure cost closer to 53,750 minutes a month at GitHub-hosted rates. Below the lower end of that range, the math usually does not work in self-hosting's favor at all, fee or no fee.
The bottom line: GitHub retracted the invoice. It did not retract the labor.
The real numbers, current and verified
GitHub-hosted runner rates dropped for real on January 1, 2026, fee reversal or not. These are worth knowing regardless of which side of the self-hosted decision your team is on.
| Runner type | Rate per minute (effective Jan 1, 2026) |
|---|---|
| Linux x86 | $0.006 |
| Linux ARM | $0.005 |
| Windows | $0.010 |
| macOS | $0.062 |
These rates already include GitHub's $0.002 platform charge, which applies to GitHub-hosted usage. It does not apply to self-hosted runners, which remain billed at zero from GitHub's side. You pay only for the compute you run them on.
Runner utilization is what actually decides the comparison. A self-hosted fleet sitting idle 60% of the day is paying for capacity nobody uses, regardless of what GitHub charges per minute. Spot instances are a real lever here. AWS's own best-practices guidance points to savings up to 90% versus on-demand pricing for workloads that can tolerate interruption, and most CI jobs can.
Run the arithmetic on a single, common instance type and the shape of the comparison gets clearer. A c5.xlarge, a typical 4 vCPU, 8 GiB choice for CI work, runs about $0.17 an hour on-demand on AWS, or roughly $124 a month if it never stops. That is the ceiling, not a realistic number, since a real self-hosted setup with autoscaling and Spot pricing lands well under it. It is still a useful anchor: a team whose GitHub-hosted bill at the rates above already exceeds that ceiling has a real case for self-hosting on utilization grounds alone, fee or no fee.
The bottom line: the GitHub-hosted rate is a fact you can look up. A rough self-hosted ceiling is easy to calculate too. The gap between them is where the decision actually lives.
The hidden cost is still security
Short-lived credentials expire within about an hour, per AWS's own guidance on securing self-hosted runners. That single design choice limits blast radius more than almost anything else on this list, because a runner holding a credential valid for only 60 minutes cannot hand an attacker a standing key to your infrastructure.
OIDC and short-lived credentials get treated as a security best practice, not a cost line. They are both. Getting credential scope wrong on a self-hosted runner is not just a compliance gap, it is hours of incident response and rotation work if it goes wrong, on top of whatever the exposure itself costs.
Defense-in-depth is the right frame, not a single control. Runner groups scoped by trust level, ephemeral runners that do not persist state between jobs, and least-privilege IAM roles all reduce the size of the problem if one layer fails. None of them became less necessary when the per-minute fee did not happen.
The bottom line: the fee was never the security risk. Standing credentials on a long-lived runner always were.
What most coverage of this got wrong
Coverage written in the days after the December 16 announcement, and before the December 17 reversal, is now stale by construction. Anyone still citing a March 2026 self-hosted charge as upcoming is describing a change that GitHub pulled before it ever billed a single account.
Coverage written after the reversal mostly treated it as the end of the story: fee cancelled, nothing more to see. That misses what the backlash comments themselves revealed, real teams naming real control-plane costs they were already carrying. The reversal is a good outcome. It is not evidence that self-hosted runners are cost-neutral.
GitHub's own decision guide on choosing between hosted and self-hosted runners is a solid general framework, but it does not connect to either the proposal or the reversal, since it was written independently of this specific pricing episode.
The bottom line: the story most people took from this was "GitHub backed down." The story worth taking is what the backlash comments actually said about cost.
How we evaluate a self-hosted runner setup
We do not sell CI platforms or a place to run your runners, which is the reason our team can give a stay-or-go answer without a thumb on the scale, fee or no fee.
The evaluation starts with three numbers: current monthly CI minutes, hours actually spent on runner maintenance in a typical month, and any incident history tied to runner access or credentials. Those three tell you whether your setup is one the December backlash comments describe accurately, or one where self-hosting already earns its keep.
What this evaluation looks like
We run it in three steps. First, a usage and cost audit against your actual GitHub billing and infrastructure spend. Second, a security posture review of runner scoping, credential lifetime, and network isolation. Third, a cost comparison specific to your numbers against the current GitHub-hosted rates above.
What the team owns at the end is a specific recommendation, not a generic one: stay self-hosted and fix what is costing you, move to GitHub-hosted at the new rates, or reconsider a managed alternative, with the math behind whichever applies.
Who this is for
Teams already self-hosting on private repos who have not priced their own maintenance hours against GitHub-hosted's January 2026 rates. The fee scare is over. The comparison it should have prompted usually is not.
If that sounds like your team, let's talk.
Key takeaways
- The self-hosted runner fee was proposed December 16, 2025 and postponed December 17. It never billed anyone
- GitHub-hosted rates did drop, for real, on January 1, 2026. Linux runs $0.006/min, down from a higher pre-cut rate
- Price your own maintenance hours before assuming self-hosting is the cheaper option by default
- Short-lived credentials limit the cost of a runner compromise. They do not eliminate the need to scope access correctly
- The backlash comments that got the fee reversed named real costs self-hosting already carries. That is the useful part of this story
"GitHub retracted the invoice. It did not retract the labor."
The fee is gone. The question it raised is not
GitHub proposed a charge, its own users objected with specifics, and GitHub reversed course inside a day. That is a rare, fast, and honestly handled correction.
It is also not the end of the cost conversation. The objections that got the fee killed, control-plane costs, maintenance hours, credential overhead, existed before December 16 and still exist now. A team that only tracked this story as "GitHub backed down" learned the wrong lesson.
If you have not priced your own self-hosted maintenance cost against the January 2026 GitHub-hosted rates, we can run the numbers with you. Talk to CrossTecch, or see our DevOps services for the full scope.
Frequently asked questions
Is GitHub still charging for self-hosted runners?
No. GitHub postponed the proposed $0.002 per minute self-hosted charge on December 17, 2025, one day after announcing it, and it never took effect.
How much do GitHub-hosted runners cost after the January 2026 price cut?
Linux runs $0.006 per minute, Linux ARM $0.005, Windows $0.010, and macOS $0.062, all effective January 1, 2026 and all down from the prior rates by up to 39%.
Why did GitHub reverse the self-hosted runner charge so quickly?
Users objected that they already pay substantial control-plane costs and that per-minute billing would penalize donated or older hardware. GitHub's own community team acknowledged missing the mark within a day.
Should we still evaluate our self-hosted runner costs even though the fee is gone?
Yes. Maintenance hours, credential management, and idle capacity cost money regardless of what GitHub charges per minute, and most teams have never priced them against current GitHub-hosted rates.
What is the difference between GitHub-hosted and self-hosted runners?
GitHub-hosted runners are managed, ephemeral machines GitHub provisions per job. Self-hosted runners are machines you provision and maintain yourself.