> GitHub stated that it has canceled the price increase after reviewing developer feedback. It added that it will take time to listen to customers and partners.
I get the feeling they got the feedback that their runners are not as indispensable to developers as they thought and realized they would lose a significant amount of users. Now if only they would listen to the feedback about windows 11 and their forced copilot we might be onto something.
I wonder if Microsoft will ever get that asking users before making changes can help them avoid looking bad in public.
Maybe half of all clients I work with use GitHub Actions for CI (the rest basically all use Jenkins), most of those using Actions use self-hosted runners for performance and security reasons, almost all of them reached out to me asking how difficult it would be to move away from GitHub Actions yet continue using GitHub.
Do you think these companies now suddenly stop wanting to move away from GitHub Actions because Microsoft suddenly changed their mind? I don't think so, probably less priority, but it will happen, because now the cat is out of the bag.
If they'd just do user research before announcing changes and not use announcements as "testing the waters", I'm sure they'd see a lot less churn. But I guess some number counting team somewhere in Microsoft figured out they'd make more money by charging people to run software on their own hardware, so maybe I'm just dreaming.
Fun thing is that almost every other CI as a service provider charges you in some shape or form for self hosted runners. CircleCI limits the number of self-hosted Job Running in parallel based on your plan and charges a fixed base fee per seat.
So moving away from GHA will not make self-hosted runners free, they’ll move into a different pricing structure that may or may not be beneficial.
And I think charging for self-hosted runners is actually fine. They’re not free for the provider either - log aggregation, caching of artifacts, runner scheduling, implementing the runner software etc are non-trivial problems for any larger CI system.
So I’m actually fine with the proposed change since it also gives me the power as a customer to say “hey, I’m paying for this, fix it.”
I also think its fine and fair to charge for the general GHA infrastructure that one would also be using with self-hosted runners.
I suspect that they weren't looking to make money off of those charges, but rather use that as a forcing function to push more usage of their managed runner (which are higher margin) which didn't work out.
Rather than everyone saying "damn that makes alternatives financially unattactive", a good chunk of the feedback was "sure I'll pay those charges as long as I don't have to use the shitty managed runners".
Depends if they are using another CI provider or running Jenkins themselves.
But also, Circle CI would be a known cost change. Right now, the only thing you know is that GitHub wants to start charging money. You have no idea what new pricing model they come up with.
The most obvious "all-in-one" package is GitLab, if you have the hardware for it and don't mind bit of bloat but all the needed features in one package.
Personally, for smaller scale projects that still require collaboration over the web, Gitea/Forgejo + Woodpecker CI has been a really simple, lightweight and easy to maintain solution.
If you're using the built-in Actions/CI/whatever it's called, and it works for you, then that's great, don't try to change :)
I guess I'm mostly still with Woodpecker because of having used it for years already, don't think there is anything major missing with either approaches, but was a while ago I looked deeper into it, maybe someone else here knows more (recent) details.
I feel like I could specify and vibe-code a CI workflow system that would be dramatically better (for a single organization’s workflow) than GitHub Actions. And hosting it would be barely more complex than hosting a GitHub Actions self-hosted runner.
The stack would be:
Postgres, as a job queue and job status tracker. The entire control plane state lives in here. Even in a fairly large org, the transaction rate would be very, very low.
An ingestion agent. Monitors the repository for pushes and PRs.
A job agent. This runs a in a sandbox and gets the inputs from GitHub and runs what is effectively a workflow step. It doesn’t get any secrets — everything it wants to do is either accomplished in the form of JSON output, blob output, or an org-specific API for doing things that don’t fit the JSON output model.
A thing to handle results. This is a simple service, connected to the database, that consumes the JSON job results and does whatever is needed (which would mostly consist of commenting on PRs or updating a CI status dashboard). For CD workflows, the build artifacts would be sent to whatever registry they go to.
A configuration system, which would be some files somewhere, maybe in a git repository that is not the repository that CI is being done on. (GitHub’s model of Actions config being in-band in the repository is IMO entirely wrong.)
And that’s about it.
I’m not suggesting that I could duplicate the GitHub Actions in a weekend. But I wouldn’t want to. This would be single-tenant, and it would support exactly the features that the organization actually uses. Heck, even par-for-the-course things like SSO aren’t needed because the entire system would have no users per se :)
Nah, that doesn’t work when the substance of the change is this intense and has an actual effect on peoples’ bottom lines. If they wait a few months and try again, people will see their bills go up immediately and they’ll all get mad again. I don’t know what GH will do next, but if they try to do that, it will definitely backfire.
When they eventually roll it out (And they will, they always do), everyone will have had plenty of time to run the numbers and either come up with a plan, or just swallow the pill.
If you still complain in a few months then that's on you, because you've been warned.
You might be surprised at how much you’re willing to surrender if someone gave you some time to come to terms with it.
It’s just a question of giving you enough time to move on from anger/shock/fear to toward acceptance. It’s like magic and is used all the time.
> Nah, that doesn’t work when…
Sounds like it could be another well known stage of the process called denial. Denial is when you tell yourself that something isn’t possible which makes you feel safer, when in fact you’re already moving toward acceptance - acceptance that you’re going to leave, or pay the price.
No. There is real serious money involved here. Usually, the people who self-host are maxing their runners (otherwise it makes more sense to use minute billing). So this will affect them by roughly doubling their servers cost. Think if some company had a $15K/month bill in self-runners, they'll now also get a $15k/month additional bill from GitHub.
We use dedicated machines for our runners. Each machine has like 16+ cpus, 64gb+ of ram. Costs are <2k per month. This pricing change would have cost more than the servers we're running on.
Outside of work, I'm a very sporadic coder. On some side-projects where I'm using Actions, I'll have an inspired few days of progress followed by completely idle weeks/months/quarters.
Losing free Actions doesn't particularly bother me, and I have no issue with paying what is most likely a negligible amount, but I don't really want to have a credit card on file which could be charged some unbounded amount if somebody gets into my account. I've shut down my personal AWS for similar reasons.
Is there any way of me just loading up a one-time $20? That will probably last well into 2027, and give me the peace of mind that I can just let it run. If my account's compromised, or I misconfigure something that goes wild, I am perfectly happy to write off that amount and have my incredibly-low-stakes toy projects fail to build.
There are several “virtual credit card” providers that allow you to generate additional cards, set limit on them like amounts and who can charge the CC. The availability varies per geography.
The problem with that is you might still get a huge bill if something goes wrong, then they try to charge it to your card at the end of the day/week/month/whatever, and it fails.
Now you still owe them the money, but haven't paid, so they tell you to pay on another card. If you refuse, they start debt collection against you and you could end up with your credit rating being affected, and maybe court cases and so on.
I want give the company an amount of money, then know that it's run out and I have to pay for more. You can set monthly limits (https://github.com/settings/billing/budgets), but if you are like me and have personal projects that you work on for a week or two a few times a year, that doesn't really work.
I just want to say I found this quite an insightful comment. I similarly would love to use a pay-as-you-go pricing model as a way of safely trying out various SaaS services.
Unfortunately I feel it is not in the SaaS businesses interests, who want to replicate the gym membership model where the 70% who don't use the service are supplementing the other 30% who use it frequently.
Setup something like CircleCI that mainly relies on paid users of their main product, and has a free plan. Microsoft currently seem to be in the process of figuring out how to lower the costs of GitHub for free users, since I'm guessing they make their actual money on other segments and products.
There's one thing I don't understand. Isn't GitHub action just "take a repo, do something with it, save something somewhere". So how is it different than writing a bash script that "clones the repo, do something with it, pushes the changes back"? If actions became paid feature, wouldn't that just generated myriads of show hn posts like "I recreated GitHub actions in xyz"?
Yes, in theory any CI/CD (whether Github, Gitlab, Jenkins etc,) is just a shell script with some warpping. But this wrapping matters because it's convenience: how you integrate with the repo, how you deal with variables, secrets, caching, deployment security and so on. Some people roughly figured this out and proposed some ways which other people learned, so switching is always a bit of a pain in various ways. But it is definitely possible - I did quite a lot of pipeline migration in my life and this is definitely not a blocker for a project of small to medium to biggish-size.
They have all kinds of costs hosting GitHub, which is why there's per seat pricing for companies. If those prices are too low, they can always increase them. Charging on top of that per minute of using your own infrastructure felt greedy to me. And the fact that this was supposed to be tied to one of the lesser-maintained features of GitHub raised eyebrows on top of that.
The utter rent-seeking audacity of charging by the minute for action runners you run on your own server...
Charge a flat fee per Action, sure. There is a tiny cost on GitHub's part associated with the API calls for starting and stopping, but if my build takes 8 hours on a self-hosted runner there is no more cost to GitHub than it taking 10 seconds.
That's the whole point of self-hosted runners.
Maybe there was more outrage elsewhere, but I was frankly confused at the seeming lack thereof here on Hacker News.
It's the classic strategy of floating an extreme change, "listening to feedback", and then coming back later with the price they intended to charge all along.
> GitHub stated that it has canceled the price increase after reviewing developer feedback. It added that it will take time to listen to customers and partners.
I get the feeling they got the feedback that their runners are not as indispensable to developers as they thought and realized they would lose a significant amount of users. Now if only they would listen to the feedback about windows 11 and their forced copilot we might be onto something.
I wonder if Microsoft will ever get that asking users before making changes can help them avoid looking bad in public.
Maybe half of all clients I work with use GitHub Actions for CI (the rest basically all use Jenkins), most of those using Actions use self-hosted runners for performance and security reasons, almost all of them reached out to me asking how difficult it would be to move away from GitHub Actions yet continue using GitHub.
Do you think these companies now suddenly stop wanting to move away from GitHub Actions because Microsoft suddenly changed their mind? I don't think so, probably less priority, but it will happen, because now the cat is out of the bag.
If they'd just do user research before announcing changes and not use announcements as "testing the waters", I'm sure they'd see a lot less churn. But I guess some number counting team somewhere in Microsoft figured out they'd make more money by charging people to run software on their own hardware, so maybe I'm just dreaming.
Fun thing is that almost every other CI as a service provider charges you in some shape or form for self hosted runners. CircleCI limits the number of self-hosted Job Running in parallel based on your plan and charges a fixed base fee per seat.
So moving away from GHA will not make self-hosted runners free, they’ll move into a different pricing structure that may or may not be beneficial.
And I think charging for self-hosted runners is actually fine. They’re not free for the provider either - log aggregation, caching of artifacts, runner scheduling, implementing the runner software etc are non-trivial problems for any larger CI system.
So I’m actually fine with the proposed change since it also gives me the power as a customer to say “hey, I’m paying for this, fix it.”
I also think its fine and fair to charge for the general GHA infrastructure that one would also be using with self-hosted runners.
I suspect that they weren't looking to make money off of those charges, but rather use that as a forcing function to push more usage of their managed runner (which are higher margin) which didn't work out. Rather than everyone saying "damn that makes alternatives financially unattactive", a good chunk of the feedback was "sure I'll pay those charges as long as I don't have to use the shitty managed runners".
Depends if they are using another CI provider or running Jenkins themselves.
But also, Circle CI would be a known cost change. Right now, the only thing you know is that GitHub wants to start charging money. You have no idea what new pricing model they come up with.
> Now if only they would listen to the feedback about windows 11 and their forced copilot we might be onto something.
You can just uninstall Copilot? It’s nowhere on my Surface Laptop 7 with W11.
For now
I've already jumped ship. Switching source control host was actually pretty easy. Builds still working just fine.
Great! Who did you jump to ?
The most obvious "all-in-one" package is GitLab, if you have the hardware for it and don't mind bit of bloat but all the needed features in one package.
Personally, for smaller scale projects that still require collaboration over the web, Gitea/Forgejo + Woodpecker CI has been a really simple, lightweight and easy to maintain solution.
I really love Gitlab CI. I don't miss managing my own Gitlab server but I definitely prefer their CI product to actions.
I am self host8ng forgejo. What can other CIs do that I could potentially need that is absent?
If you're using the built-in Actions/CI/whatever it's called, and it works for you, then that's great, don't try to change :)
I guess I'm mostly still with Woodpecker because of having used it for years already, don't think there is anything major missing with either approaches, but was a while ago I looked deeper into it, maybe someone else here knows more (recent) details.
I feel like I could specify and vibe-code a CI workflow system that would be dramatically better (for a single organization’s workflow) than GitHub Actions. And hosting it would be barely more complex than hosting a GitHub Actions self-hosted runner.
The stack would be:
Postgres, as a job queue and job status tracker. The entire control plane state lives in here. Even in a fairly large org, the transaction rate would be very, very low.
An ingestion agent. Monitors the repository for pushes and PRs.
A job agent. This runs a in a sandbox and gets the inputs from GitHub and runs what is effectively a workflow step. It doesn’t get any secrets — everything it wants to do is either accomplished in the form of JSON output, blob output, or an org-specific API for doing things that don’t fit the JSON output model.
A thing to handle results. This is a simple service, connected to the database, that consumes the JSON job results and does whatever is needed (which would mostly consist of commenting on PRs or updating a CI status dashboard). For CD workflows, the build artifacts would be sent to whatever registry they go to.
A configuration system, which would be some files somewhere, maybe in a git repository that is not the repository that CI is being done on. (GitHub’s model of Actions config being in-band in the repository is IMO entirely wrong.)
And that’s about it.
I’m not suggesting that I could duplicate the GitHub Actions in a weekend. But I wouldn’t want to. This would be single-tenant, and it would support exactly the features that the organization actually uses. Heck, even par-for-the-course things like SSO aren’t needed because the entire system would have no users per se :)
1. Announce price increase generating bad publicity.
2. Kill bad publicity with blog pretending to be understanding and taking on feedback while "pausing" the increase.
3. Implement price increase a few months later when the bad publicity wave is over, and its old news so wont generate new headlines.
Nah, that doesn’t work when the substance of the change is this intense and has an actual effect on peoples’ bottom lines. If they wait a few months and try again, people will see their bills go up immediately and they’ll all get mad again. I don’t know what GH will do next, but if they try to do that, it will definitely backfire.
When they eventually roll it out (And they will, they always do), everyone will have had plenty of time to run the numbers and either come up with a plan, or just swallow the pill.
If you still complain in a few months then that's on you, because you've been warned.
You might be surprised at how much you’re willing to surrender if someone gave you some time to come to terms with it.
It’s just a question of giving you enough time to move on from anger/shock/fear to toward acceptance. It’s like magic and is used all the time.
> Nah, that doesn’t work when…
Sounds like it could be another well known stage of the process called denial. Denial is when you tell yourself that something isn’t possible which makes you feel safer, when in fact you’re already moving toward acceptance - acceptance that you’re going to leave, or pay the price.
sounds like it's time to increase their vendor lock in then an make sure they are not as compatible with other solutions.
I fear this would be the obvious conclusion.
Sounds like Chat Control.
No. There is real serious money involved here. Usually, the people who self-host are maxing their runners (otherwise it makes more sense to use minute billing). So this will affect them by roughly doubling their servers cost. Think if some company had a $15K/month bill in self-runners, they'll now also get a $15k/month additional bill from GitHub.
Many people will switch for that kind of money.
We use dedicated machines for our runners. Each machine has like 16+ cpus, 64gb+ of ram. Costs are <2k per month. This pricing change would have cost more than the servers we're running on.
Outside of work, I'm a very sporadic coder. On some side-projects where I'm using Actions, I'll have an inspired few days of progress followed by completely idle weeks/months/quarters.
Losing free Actions doesn't particularly bother me, and I have no issue with paying what is most likely a negligible amount, but I don't really want to have a credit card on file which could be charged some unbounded amount if somebody gets into my account. I've shut down my personal AWS for similar reasons.
Is there any way of me just loading up a one-time $20? That will probably last well into 2027, and give me the peace of mind that I can just let it run. If my account's compromised, or I misconfigure something that goes wild, I am perfectly happy to write off that amount and have my incredibly-low-stakes toy projects fail to build.
Put a spend limit in GitHub and issue a chargeback if they ever bill you more.
There are several “virtual credit card” providers that allow you to generate additional cards, set limit on them like amounts and who can charge the CC. The availability varies per geography.
The problem with that is you might still get a huge bill if something goes wrong, then they try to charge it to your card at the end of the day/week/month/whatever, and it fails.
Now you still owe them the money, but haven't paid, so they tell you to pay on another card. If you refuse, they start debt collection against you and you could end up with your credit rating being affected, and maybe court cases and so on.
I want give the company an amount of money, then know that it's run out and I have to pay for more. You can set monthly limits (https://github.com/settings/billing/budgets), but if you are like me and have personal projects that you work on for a week or two a few times a year, that doesn't really work.
I just want to say I found this quite an insightful comment. I similarly would love to use a pay-as-you-go pricing model as a way of safely trying out various SaaS services.
Unfortunately I feel it is not in the SaaS businesses interests, who want to replicate the gym membership model where the 70% who don't use the service are supplementing the other 30% who use it frequently.
Setup something like CircleCI that mainly relies on paid users of their main product, and has a free plan. Microsoft currently seem to be in the process of figuring out how to lower the costs of GitHub for free users, since I'm guessing they make their actual money on other segments and products.
There's one thing I don't understand. Isn't GitHub action just "take a repo, do something with it, save something somewhere". So how is it different than writing a bash script that "clones the repo, do something with it, pushes the changes back"? If actions became paid feature, wouldn't that just generated myriads of show hn posts like "I recreated GitHub actions in xyz"?
Yes, in theory any CI/CD (whether Github, Gitlab, Jenkins etc,) is just a shell script with some warpping. But this wrapping matters because it's convenience: how you integrate with the repo, how you deal with variables, secrets, caching, deployment security and so on. Some people roughly figured this out and proposed some ways which other people learned, so switching is always a bit of a pain in various ways. But it is definitely possible - I did quite a lot of pipeline migration in my life and this is definitely not a blocker for a project of small to medium to biggish-size.
Where does one get to suffer YAML hell then??
It's like bash scripts, but with ability to debug them.
There are few things less debuggable than Github Actions. Bash scripts isn't one of them
this is a better link:
https://github.blog/changelog/2025-12-16-coming-soon-simpler...
from the tweet [1]:
"We’ve read your posts and heard your feedback.
1. We’re postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach.
2. We are continuing to reduce hosted-runners prices by up to 39% on January 1, 2026.
We have real costs"
^ theres more in the actual tweet, but the preview that gets unfurled on discord cuts off there. That last lines a killer, poor olde microsoft
1. https://x.com/i/status/2001372894882918548
> We have real costs"
Am i wrong or didn't they have a bug in the action runners that would basically cycle the CPU infinitely ?
> https://github.com/actions/runner/issues/2380
> https://github.com/actions/runner/issues/3792
Didn't they take years to fix this ? Or its unrelated ?
They are talking about the cost to run the Actions control plane and the scheduler that is not executed on the runner itself.
They have all kinds of costs hosting GitHub, which is why there's per seat pricing for companies. If those prices are too low, they can always increase them. Charging on top of that per minute of using your own infrastructure felt greedy to me. And the fact that this was supposed to be tied to one of the lesser-maintained features of GitHub raised eyebrows on top of that.
https://archive.ph/3nsGi
Not gonna wait 30seconds to read the bloody article, when it says "5seconds ad".
The utter rent-seeking audacity of charging by the minute for action runners you run on your own server...
Charge a flat fee per Action, sure. There is a tiny cost on GitHub's part associated with the API calls for starting and stopping, but if my build takes 8 hours on a self-hosted runner there is no more cost to GitHub than it taking 10 seconds.
That's the whole point of self-hosted runners.
Maybe there was more outrage elsewhere, but I was frankly confused at the seeming lack thereof here on Hacker News.
See also:
- https://news.ycombinator.com/item?id=46304379
- https://news.ycombinator.com/item?id=46305216
Oh good, I can postpone my migration for personal projects.
Or, rather, you have more time to execute it. They _will_ rug pull again, this is Microsoft ffs.
It's the classic strategy of floating an extreme change, "listening to feedback", and then coming back later with the price they intended to charge all along.
That's the signal I'm getting here and they're not even being coy about it, they're just postponing some form of inevitable price increase.
Who could've thought, really