Pricing Changes for GitHub Actions
229 comments
·December 16, 2025golovast
tetha
This kinda change also has some different gears turning in my head. At $0.002 / build-minute, some of our large software integration tests would cost us around 15 - 20 cents. Some of our ansible integration tests would be 5 - 10 cents - and we run like 50 - 100 of those per day. Some deployments might cost us a cent or two.
Apples to oranges, naturally, but like this, our infra-jenkins master would pay for itself in hosting in a week of ansible integration testing compared to what GHA would cost. Sure, maintenance is a thing, but honestly, flinging java, docker and a few other things onto a build agent isn't the time-consuming part of maintaining CI infrastructure.
And I mean sure, everything is kinda janky on Jenkins, but everything falls into an expectable corridor of jank you get used to.
esafak
Any official Github action today:
"Thank you for your interest in this GitHub action, however, right now we are not taking contributions.
We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time. The GitHub public roadmap is the best place to follow along for any updates on features we’re working on and what stage they’re in."
MathiasPius
Introducing a separate charge specifically targeting those of your customers who choose to self-host your hilariously fragile infrastructure is certainly a choice.. And one I assume is in no way tied to adoption/usage-based KPIs.
Of course, if you can just fence in your competition and charge admission, it'd be silly to invest time in building a superior product.
kjuulh
We've self-hosted github actions in the past, and self-hosting it doesn't help all that much with the fragile part. For github it is just as much triggering the actions as it is running them. ;) I hope the product gets some investment, because it has been unstable for such a long time, that on the inside it must be just the usual right now. GitHub has by far the worst uptime of any SaaS tools we use at the moment, and it isn't even close.
> Actions is down again, call Brent so he can fix it again...
Fabricio20
We self host the runners in our infrastructure and the builds are over 10x faster than relying on their cloud runners. It's crazy the performance you get from running runners on your own hardware instead of their shared CPU. Literally from ~8m build time on Gradle + Docker down to mere 15s of Gradle + Docker on self hosted CPUs.
matsimitsu
This! We went from 20!! minutes and 1.2k monthly spend on very, very brittle action runs to a full CI run in 4 minutes, always passing, by just by going to Hetzner's server auction page and bid on a 100 euro Ryzen machine.
btown
> call Brent so he can fix it again
Not sure if a Phoenix Project reference, but if it is, it's certainly in keeping with Github being as fragile as the company in the book!
kjuulh
It is xD On the outside it feels like a product held together with duct tape, wood glue and prayers.
tracker1
I tend to just rely on the platform installers, then write my own process scripts to handle the work beyond the runners. Lets me exercise most of the process without having to (re)run the ci/cd processes over and over, which can be cumbersome, and a pain when they do break.
The only self-hosted runners I've used have been for internalized deployments separate from the build or (pre)test processes.
Aside: I've come to rely on Deno heavily for a lot of my scripting needs since it lets me reference repository modules directly and not require a build/install step head of time... just write TypeScript and run.
kjuulh
We choose github actions because it was tied directly to github providing the best pull-request experience etc. We actually didn't really use github actions templating as we'd got our own stuff for that, so the only thing github actions actually had to do was start, run a few light jobs as the CI was technically run elsewhere and then report the final status.
When you've got many 100s of services managing these in actions yaml itself is no bueno. As you mentioned having the option to actually be able to run the CI/CD yourself is a must. Having to wait 5 minutes plus many commits just to test an action drains you very fast.
Granted we did end up making the CI so fast (~ 1 minute with dependency cache, ~4 minutes without), that we saw devs running their setup less and less on their personal workstations for development. Except when github actions went down... ;) We used Jenkins self-hosted before and it was far more stable, but a pain to maintain and understand.
featherless
This is absolutely bananas; for my own CI workflow I'll have to pay $140+/month now just to run my own hardware.
hinkley
Am I right in assuming it’s not the amount of payment but the transition from $0 to paying a bill at all?
I’m definitely sure it’s saving me more than $140 a month to have CI/CD running and I’m also sure I’d never break even on the opportunity cost of having someone write or set one up internally if someone else’s works - and this is the key - just as well.
But investment in CI/CD is investing in future velocity. The hours invested are paid for by hours saved. So if the outcome is brittle and requires oversight that savings drops or disappears.
hedgehog
I'm curious, what are you doing that has over 1000 hours a month of action runtime?
featherless
I run a local Valhalla build cluster to power the https://sidecar.clutch.engineering routing engine. The cluster runs daily and takes a significant amount of wall-clock time to build the entire planet. That's about 50% of my CI time; the other 50% is presubmits + App Store builds for Sidecar + CANStudio / ELMCheck.
Using GitHub actions to coordinate the Valhalla builds was a nice-to-have, but this is a deal-breaker for my pull request workflows.
Eikon
On ZeroFS [0] I am doing around 80 000 minutes a month.
A lot of it is wasted in build time though, due to a lack of appropriate caching facilities with GitHub actions.
[0] https://github.com/Barre/ZeroFS/tree/main/.github/workflows
duped
1 hour build/test time, 20 devs, that's 50 runs a month. Totally possible.
nyrikki
I resorted to a local forgejo + woodpecker-ci. Every time I am forced back to GitHub for some reason it confirms I made the right choice.
In my experience gitlab always felt clunky and overly complicated on the back end, but for my needs local forgejo is better than the cloud options.
awestroke
They still host all artefacts and logs for these self-hosted runs. Probably costs them a fair bit
gz09
They already charge for this separately (at least storage). Some compute cost may be justified but you'd wish that this change would come with some commitment of fixing bugs (many open for years) in their CI platform -- as opposed to investing all their resources in a (mostly inferior) LLM agent (copilot).
naikrovek
Copilot uses other models, not (necessarily?) its own, so I’m not sure what you mean.
null
featherless
There's absolutely no way that the cost scales with the usage of my own hardware. I cannot fathom this change in any way or form. Livid.
naikrovek
Runners aren’t fragile, workflows are.
The runner software they provide is solid and I’ve never had an issue with it after administering self-hosted GitHub actions runners for 4 years. 100s of thousands of runners have taken jobs, done the work, destroyed themselves, and been replaced with clean runners, all without a single issue with the runners themselves.
Workflows on the other hand, they have problems. The whole design is a bit silly
falsedan
it's not the runners, it's the orchestration service that's the problem
been working to move all our workflows to self hosted, on demand ephemeral runners. was severely delayed to find out how slipshod the Actions Runner Service was, and had to redesign to handle out-of-order or plain missing webhook events. jobs would start running before a workflow_job event would be delivered
we've got it now that we can detect a GitHub Actions outage and let them know by opening a support ticket, before the status page updates
null
zahlman
Meanwhile I'm just running `pytest`, `pyproject-build`, `twine` etc. at the command line....
(People seem to object to this comment. I genuinely do not understand why.)
pseudosavant
It passes on my machine. YOLO!
colechristensen
You don't trust devs to run things, to have git hooks installed, to have a clean environment, to not have uncommitted changes, to not have a diverging environment on their laptop.
Actions let you test things in multiple environments, to test them with credentials against resources devs don't have access to, to do additional things like deploys, managing version numbers, on and on
With CI, especially pull requests, you can leave longer running tests for github to take care of verifying. You can run periodic tests once a day like an hour long smoke test.
CI is guard rails against common failure modes which turn requiring everyone to follow an evolving script into something automatic nobody needs to think about much
zahlman
> You don't trust devs to run things, to have git hooks installed, to have a clean environment, to not have uncommitted changes, to not have a diverging environment on their laptop.
... Is nobody in charge on the team?
Or is it not enough that devs adhere to a coding standard, work to APIs etc. but you expect them to follow a common process to get there (as opposed to what makes them individually most productive)?
> You can run periodic tests once a day like an hour long smoke test.
Which is great if you have multiple people expected to contribute on any given day. Quite a bit of development on GitHub, and in general, is not so... corporate.
I don't deny there are use cases for this sort of thing. But people on HN talking about "hosting things locally" seem to describe a culture utterly foreign to me. I don't, for example, use multiple computers throughout the house that I want to "sync". (I don't even use a smartphone.) I really feel strongly that most people in tech would be better served by questioning the existing complexity of their lives (and setups), than by questioning what they're missing out on.
misnome
Because you appear completely oblivious and deliberately naive about the entire purpose of CI.
zahlman
Based on my experience I really do think most people are using it for things that they could perfectly well do locally with far less complication.
Perhaps that isn't most use of it; the big projects are really big.
Arcuru
> We are introducing a $0.002 per-minute Actions cloud platform charge for all Actions workflows across GitHub-hosted and self-hosted runners.
Charging for self-hosted runners is an interesting choice. That's the same cost as their smallest hosted runners [1]
[1] - https://docs.github.com/en/billing/reference/actions-runner-...
sylens
Pushing you towards their hosted runners which will show up in their Azure usage numbers and drive the stock price
NewJazz
Ah yes, vertical integration and oligopoly.
Really Dianne?
thewisenerd
it'd be great if they can couple this with an SLA for GitHub actions so we won't have to end up paying as much..
(ofc, that'd only mean they stop updating the status page, so eh)
teach
For what it's worth, they already fail to update the status page. We had an "outage" just this morning where jobs were waiting 10+ minutes for an available runner -- resolved after half an hour or so but nothing was ever posted
falsedan
I don't want to shit on the Code to Cloud team but they act a lot like an internal infrastructure team when they're a product team with paying customers
tom1337
Yep - Bitbucket made a similar move recently and I guess they are just following along. I'd love to get the justification of that fee tho…
Edit: Confused GitLab and Bitbucket
swatcoder
> justification of that fee
ZIRP ended, its remaining monopoly money has been burnt through, and the projected economy is looking bleak. We're now in the phase where everything that can be monetized is being monetized in every way that can be managed.
Free tiers evaporate. Fees appear everywhere. Ads appear everywhere, even where it was implied they wouldn't. The lemons must be squeezed.
And because everybody of relevance is in that mode, there's little competitive pressure to provide a specific rationale for a specific scheme. For the next few years, that's all the justification that there needs to be.
null
wiether
Your edit made your post confusing for us now...
I thought that "Bitbucket" was in your original post and you added only your edit message to say that it was, in fact, Gitlab and not Bitbucket that added cost for self-hosted runners.
nstart
I initially felt a bit offended when I saw this. Then I thought about it and at the end of the day there's a decent amount of infrastructure that goes into displaying the build information, updating it, scanning for secrets and redacting, etc.
I don't know if it's worth the amount they are targeting, but it's definitely not zero either.
acdha
Yeah, I think we’re seeing some fallout from how much developer infrastructure was built out during the era where VCs were subsidizing everything, similar to how a lot of younger people complained about delivery charges going up when they had to pay the full cost. Unfortunately, now a lot of the competition is gone so there isn’t much room to negotiate or try alternate pricing models.
xp84
You would think the fat monthly per-seat license fee we also pay would be enough to cover the costs of checks notes reading some data from the DB and hosting JSON APIs and webpages.
franktankbank
Does it make sense to accept charge per minute when you are hosting yourself? When GHA is not very good?
jeduardo
That's a surprise, do you have a link to their announcement?
tom1337
Nope because I confused Bitbucket with GitLab. My bad. BitBuckets announcement can be found here: https://news.ycombinator.com/item?id=46165180
IshKebab
It's because there are easy-to-use third party runners that cost around 3-10x less than the GitHub ones. This is aimed squarely at them.
andsens
That's not a move of a company that thinks it can still grow. That's a Netflix "we have 90% of the market, let's squeeze them" move. This is the beginning. We have all seen this pattern over the last 5+ years. You know their next few moves.
groundzeros2015
The Netflix one worked
qoez
Worked for them not for the consumers
Izikiel43
Netflix is looking out for Netflix shareholders, not for consumers, like any other public company.
vkou
It worked to push me to unsubscribe.
sltr
> Self-hosted runners: You will be charged for using the GitHub Actions cloud platform from March 1, 2026
The GitHub encrapification finally affects me. I am militantly unwilling to pay per minute to use my own computer. Time to leave. I can trigger and monitor builds myself thank you very much.
ticoombs
I migrated to forgejo a few years ago and never looked back. While there are some edge cases and known issues. All of my actions "just worked".
clintonb
Yikes! They seem to be gunning for services like WarpBuild, which we've used for a couple years to keep our costs low. The $0.002 per minute on top of WarpBuild's costs is exactly GitHub's new pricing scheme.
I'm happy for competition, but this seems a bit foul since we users aren't getting anything tangible beyond the promise of improvements and investments that I don't need.
suryao
The lever that matters the most with the new $0.002/min tax is to reduce the number of minutes consumed.
Given that GitHub runners are still slow as ever, it actually is a point in our favor even compared to self-hosting on aws etc. However, it makes the value harder to communicate <shrug>.
clintonb
Thanks for the email and the reminder that we can use fewer shards with larger runners.
eduardogarza
This is my first comment on HN despite being a user for over a decade -- this is one of the most outrageous pricing changes I've encountered - I couldn't believe it when I read the email earlier (I run self-hosted runners).
Anyone using GitLab or any other VCM that you'd recommend? I'm absolutely done with Github. Or is everything else just as bad?
yoyohello13
We self host GitLab and it’s been amazing. Never down, all the features we need. And the CI is, at least for me, easier to understand than GH actions. You’re just running scripts in a container no weird abstractions.
woile
codeberg.org for open source, because it's a non-profit, with what it seems, very well intentioned people, with a good governance structure, and it's starting to support federation.
For a company, I'd recommend self-hosting forgejo (which also has actions), which powers codeberg.
(forgejo started as a fork of gitea)
import
Gitea is almost fully compatible with the GitHub runners. You might need to do small changes in the workflows.
wiether
Gitea!
And the best (maybe?) part in your case is that the CI is based on GH Actions, so you can probably reuse your workflows without the need to adapt them.
eduardogarza
I will try Gitea -- thanks everyone for the recommendations
Pooge
Gitea has a fully compatible system AFAIK.
verdverm
Tangled has a nix based workflow engine that looks very similar, if you are into nix and self-hosting runners
https://tangled.org/tangled.org/core/blob/master/docs/spindl...
(no affiliation)
---
Blog post about Tangled's CI: https://blog.tangled.org/ci
Cyph0n
Very cool! Are there any blog posts or articles about Tangled? Docs seem pretty light.
verdverm
I pinged them on Bluesky to join this HN story comments, they would be better equipped to answer
https://bsky.app/profile/tangled.org
There looks to be a blog post here: https://blog.tangled.org/ci
teeray
How does this compare to just running Hydra yourself?
IshKebab
Useless for Mac or Windows presumably.
quasigod
What do you mean? This is for CI, whatever the dev machine runs is irrelevant. Either way, the CI uses OCI containers built with Nix, you don't need Nix installed on the host. Also Nix supports MacOS.
verdverm
self-hosted, so same story?
I'm not a fan of nix and would have picked containers regardless for a git forge CI offering
wyldfire
If this gives you pause, consider these hosted alternatives as another option:
* Codeberg https://codeberg.org/
* Sourcehut https://sr.ht/ [1]
roxolotl
I’m genuinely excited about this. The GitHub actions platform is genuinely bad compared to circle or Travis but they’ve been totally crowded out because GitHub was just so easy to use. This has led to plenty of security issues and a general lack of innovation in the ci space. Hopefully by this pricing structure change we’ll see more investment in ci tooling across the industry
nine_k
GitHub Actions were never too easy to use. But they were cheap to use, so anything more expensive had trouble competing.
Now the playing field is more level, yay. Fun for those who choose to migrate away.
lherron
Why would the self-hosted runner fee be per-minute instead of per-job? I don’t get it.
woodruffw
I had the same question — I understand that the Actions control plane has costs on self-hosted runners that GitHub would like to recoup, but those costs are fixed per-job. Charging by the minute for the user’s own resources gives the impression that GitHub is actually trying to disincentivize third-party runners.
watermelon0
Self-hosted runner regularly communicates with the control plane, and control plane also needs to keep track of job status, logs, job summaries, etc.
8h job is definitely more expensive to them than a 1 minute one, but I'd guess that the actual reason is that this way they earn more money, and dissuade users from using a third party service instead of their own runners.
verdverm
or some other metric like how many logs your job produces and they have to process
the only rational outside rationale is this has the best financial projections, equitability with the customer be damned
gotta make up for those slumping ai sales somehow, amiright?
IshKebab
Because the competitor services that provide much cheaper hosted runners also charge per minute.
This isn't aimed at people actually self-hosting; it's aimed at alternative hosted runners providers. See this list
hoten
I wonder how much they made from engineering practices such as https://github.com/actions/runner/issues/3792.
To spell it out: jobs can hang forever because of some ridiculously bad code on their end, they have a 6 hour cap, so that's 6 hours of billable $$$ per-instance of the bug (assuming it wasn't manually canceled). I know I've seen jobs hang forever regularly over the course of my years using GitHub for work.
Note: pretty sure this has been resolved.
drcongo
Oh, I had that happen fairly recently.
I got contacted by our rep a couple weeks ago, who informed me of this news. I thought it was a disaster and it really pissed me off. The rep couldn't even explain the reasoning well. It basically summed up to "because we can" and "where are you going to go?". He was shocked to find out that I didn't like it.
We currently self-host on kubernets/aws. The thing that really got to me isn't the new charge per se. It's the fact that GHA has a ton of problems. I can hold my nose and deal with them when it's free. But now that you're squeezing me, at least you could have created something like GHA 2.0 and added a charge for that. Instead, there are vague roadmap promises which don't even include things that I care about. Specifically:
- Jenkins had better kubernetes integration years ago. It's crazy that GHA can't beat that.
- "Reintroducing multi-label functionality" - yeah, so they first broke it. They did supply "reasons", which looked like they never talked to a customer. [1]
- Still no SDK of any kind.
- "Actions Data Stream" - or you can just fix your logging.
There are dozens more complains, which are easy enough to find. This kind of an approach just makes me want to make sure that I don't use GHA again. Even if I end up paying another vendor, at least I'll be treated as a customer.
[1] - https://github.com/orgs/community/discussions/160682#discuss...