The Github Actions Control Plane Is No Longer Free
Key topics
GitHub's decision to start charging for its Actions control plane has sparked a lively debate, with many commenters linking the move to Microsoft's broader strategy of increasing prices across its product lineup. Some see this as a classic case of "embrace, extend, and extinguish," with GitHub Actions potentially becoming a costly necessity for developers. As one commenter quipped, "No such thing as free parking," while others worry that this change could be the downfall of GitHub Actions. The discussion highlights the tension between the convenience of integrated services and the costs of sustaining them, particularly in the AI-driven tech landscape.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
3m
Peak period
49
0-3h
Avg / period
9
Key moments
- 01Story posted
Dec 16, 2025 at 12:37 PM EST
17 days ago
Step 01 - 02First comment
Dec 16, 2025 at 12:40 PM EST
3m after posting
Step 02 - 03Peak activity
49 comments in 0-3h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 18, 2025 at 8:06 AM EST
15 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
https://news.ycombinator.com/item?id=46291156
This is going to be the downfall of GA
It does? I feel like it implies that they want third-party runners like Blacksmith out of the ecosystem, which is why they're now financially penalizing customers who use them.
- Introducing a cheap 1-core runner - Lowering the price of GitHub-hosted runners - Making it slightly more expensive to use self-hosted runners - There is actually a fourth one: the vnet integration, which also allows you to run public runners in your own infra
As a bonus, for some people it means something that was free is now not free. Those who are willing to pay rather than go, might prefer to use GitHub-hosted if they are going to pay anyway.
This is clearly an incentive to use github-hosted, and their sales reps are also going this way.
https://docs.github.com/en/enterprise-cloud@latest/admin/con...
1. Services like blacksmith and WarpBuild (I'm the founder) are still cheaper than GitHub hosted runners, even after including the $0.002/min self-hosting tax.
2. The biggest lever for controlling costs now is reducing the number of minutes used in CI. Given how slow Github's runners are, or even the ones on AWS compared to our baremetal processor single core performance + nvme disks, it makes even more sense to use WarpBuild. This actually makes a better case for moving from slow AWS instances running with actions-runner-controller etc. to WarpBuild!
3. Messaging this to most users is harder since the first reaction is that Github options make more sense. After some rational thought, it is the opposite.
Overall - it is worse for Github users, but options like blacksmith and WarpBuild are still the better option.
Right now at my company our biggest complaint are macOS Intel runners from GitHub which somehow take 15+ minutes to provision and are the slowest of the bunch.
macOS Runners Apple Silicon and Intel support
Nowadays GH has more sizes by WB continues to beat them in price and performance.
It’s highway robbery what GH charges for the crap they provide. I can highly recommend WarpBuild for Mac (and Linux) runners.
what makes you think they won't hike the control plane price again? They can turn this knob arbitrarily to put you out of business.
Reg. hiking it again, they'd have to either be extremely anti-competitive and selectively apply the pricing OR apply the hike uniformly by about double the current value to match our pricing while making it completely unviable for any large co to use self-hosted github actions in the first place.
That's not true for _all GitHub Actions usage_.
https://resources.github.com/actions/2026-pricing-changes-fo...
> Standard GitHub-hosted or self-hosted runner usage on public repositories will remain free.
Basically I'll gladly pay for a service, but I don't like getting locked into that service. If the payed service is using FOSS, I will always have the option to migrate if the provider starts to misbehave
Not sure about the "up to" implications, but I guess it's just Microsoft trying to make github a bit more freemium tm
> And we’re reducing the net cost of GitHub-hosted runners by up to 39%, depending on which machine type is used.
> The price reduction you will see in your account depends on the types of machines that you use most frequently – smaller runners will have a smaller relative price reduction, larger runners will see a larger relative reduction.
The only variable is how long after acquisition before they gut it. It's almost never right away. GitHub was acquired 7 years ago, but it started showing symptoms perhaps 2 years ago.
With this I think it's clear the wound was fatal. GitHub will stumble on for a few more years with ever-decreasing quality, before going the way of Skype.
So, I guess we're all migrating to gitlab? Or is it time to launch gittube? Githamster?
But other alternatives exist as well, like Sourcehut: https://sr.ht/
They seem to care much less about free users than in the past but businesses still flock to it. GitLab is the only other platform I’ve seen in the workplace of anywhere I worked, with the exception of a big tech company I worked at. They had both GitHub enterprise and an internally maintained platform which was being phased out. if I recall correctly it based on Phabricator
The considerations for commercial users leaving github are probably pretty different, so perhaps they'll stay.
There’s also a large bunch of projects that will never leave, some of which ms have influence over. I mean, some high profile open source projects hasn’t even left source forge yet, even though it has been malware infested shithole for decades.
Considering that the lifetime of our sun system is finite that statement is undeniably true.
Also we don't know how a non-Microsoft GitHub could have developed.
For example, in our pipeline we have 5 different linter tasks (for different subprojects), running each only a few seconds. Nonetheless, we’ll get billed for 5 minutes on every commit.
the control plane clearly has value to people beyond the compute used for running the actions, and it seems reasonable that they should charge for that if you're using it.
What I'd really like to see is some new CI/CD systems though. Actions is garbage in multiple dimensions. Can't somebody do something clever and save us from this flaky insecure YAML hell?
To your second statement, I generally agree. Sounds strange to say given we're in the business of GHA runners. But it's just not a performant or reliable system at scale. This change from GitHub doesn't smell of a company that wants to do right by it's users.
If you are interested in what is up next for us at Depot, feel free to ping me via the email in my bio. I think you'll be quite interested in what we are doing.
[0] https://depot.dev
GitHub will begin charging for self-hosted action runners on March 2026 https://github.blog/changelog/2025-12-16-coming-soon-simpler... (https://news.ycombinator.com/item?id=46291414)
1. Self-hosting runners or using WarpBuild/blacksmith runners is still cheaper Despite the $0.002/minute self-hosted runner tax, self-hosting runners on your cloud (aws/gcp/azure/...) or using WarpBuild/... runners remains the cheaper option.
2. Prefer larger runners If your workflow scales with the number of vCPUs, prefer larger runners. That ensures you spend fewer minutes on the runner, which reduces the GitHub self-hosted runner tax.
For example, using actions-runner-controller with heavy jobs running on 1 vcpu runners is not a good idea. Instead, prefer a 2vcpu runner (say) if it runs the job ~2x faster.
3. Prefer faster runners All else being equal, prefer faster runners. That ensures you spend fewer minutes on the runner, which reduces the GitHub self-hosted runner tax.
For example, if you're self-hosting on aws and using a t3g.medium runner, it's better to use a t4g.medium runner since the newer generation is faster, but not much more expensive.
4. Prefer fewer shards If you have a lot of shards for your jobs (example: tests on ~50 shards), consider reducing the number of shards and parallelizing the tests on fewer but larger runners.
5. Improve job performance This is not new advice, but it's now more important than ever because of the additional GitHub self-hosted runner tax.
6. Use GitHub hosted runners for very short jobs For linters and other very short jobs, it's better to use GitHub hosted runners.
Hope this helps. Note: I'm the founder of WarpBuild. I'm biased, but the points above hold.
Hard for me to feel like our industry is innovating and not just gouging with the rest in the battle for enshittification.