My theory: Some manager's KPI is to increase the number of sold GitHub runner minutes. So they did some market research -- not enough to have a clear picture, but barely enough to be dangerous -- and found that some companies use self-hosted runners for cost reasons. So they deploy a two-pronged strategy: lower the cost of GitHub runners, and charge for the use of self-hosted runners, to incentivize switching.
This fails for several reasons that someone who actually uses the product might have intuited:
(a) For some use-cases, you can't switch to GitHub's runners. For us, it's a no-go for anything that touches our infrastructure.
(b) Switching CI providers isn't hard, we had to do it twice already. Granted, most of our CI logic is in a custom build script that you can run locally, and not in the proprietary YAML file. But to be honest, I'd recommend that sort of setup for any CI provider, as you always want the ability to debug things locally.
(c) GitHub Actions doesn't get the amount of love you'd expect from something billed as a "premium service". In fact, it often feels quite abandoned, barely kept working. Who knows what they're brewing internally, but they didn't coordinate this with a major feature announcement, and didn't rush to announce anything now that they got backlash, which leads me to believe they don't have anything major planned.
(d) Paying someone -- by the minute, no less -- to use my own infrastructure feels strange and greedy. GitHub has always had per-user pricing, which feels fair and predictable. If for some reason they need more money, they can always increase that price. The fact that they didn't do that leads me to believe this wasn't about cost per se. Hence the KPI theory I mentioned above: this wasn't well-coordinated with any bigger strategy.
> Switching CI providers isn't hard, we had to do it twice already. Granted, most of our CI logic is in a custom build script that you can run locally, and not in the proprietary YAML file. But to be honest, I'd recommend that sort of setup for any CI provider, as you always want the ability to debug things locally.
I believe this has been a CI/CD best practice for over a decade. Even in venerable Jenkins, this is one of the core principles when designing pipelines[0]: don't give in to the temptation to do fancy Groovy stuff, just use simple shell commands in steps, and you will be grateful to yourself several times years later.
It has been best practice for over a decade, but for reasons I don't understand, nearly every developer I've worked with just wants to do the lock-in/propietary route and is entirely unpersuaded by the "portability" argument. I've now seen it burn teams hard multiple times now. At that point people realize the wisdom in the external scripts, but then a new wave of devs come in and start the whole cycle over.
I don’t know why, but the linked page only shows the table of contents on iPhone Safari, but whence I switch to reader mode it shows the actual best practices. Anyway thanks for sharing!
https://news.ycombinator.com/item?id=46189692 from a few days ago pretty much tells me that any company that slightly cares about security cannot possibly depend on GitHub runner for their CI (except maybe the smallest/simplest projects). It is just one compromised package away from ruining everything.
(e): Community software like act and Forgejo/Gitea Actions have made it a lot easier to run GitHub Actions workflows without involving GitHub and are decreasing the friction of migration.
> 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.”
The problem is that they are charging a per-minute fee, and a fee at the same order-of-magnitude as actually running the tests. If you're offering cloud-hosted runners for $0.002/minute, asking that same $0.002/minute as an orchestrator fee for self-hosted runners is just insulting.
Charging for self-hosted runners is indeed not a huge deal, and I bet they wouldn't have gotten the same kind of backlash if they charged for it via a per-seat, per-run, per-gigabyte, or per-log-line fee. And if GHA hadn't been so poorly maintained...
Any model that charges for self-hosted runner is going to feel unfair to someone. Per seat pricing is better for small orgs with a lot of CI minutes, per-run pricing would be good for orgs with few, long runs, per minute pricing is nicer for orgs with many small runs.
In my observation the critisicm was strongly dominated by outrage over the actual fact.
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.
Self-hosting all of your CI is yet another tradeoff. The software comes for free (if you're using Free Software, that is), but you now have operational overhead. I'm not saying it's an unreasonable move, but it's also not a free swap
The cost of the control plan for Github and the cost of their runners are not equal. Yet this new plan seems to say a self-hosted minute is counted the same as a hosted minute, since self-hosted minutes count towards the 2000 included minutes.
Gitlab enters the room, where self-hosted runners are as free as in free beer (maintenance yes, but no limit on runners and no pricing expect on a per-user basis).
Yes, gitlab does still have free self-hosted runners. OTOH, github has a free organisation plan and gitlab doesn't. So yes, strictly speaking self-hosted runners are free, but you're paying for the dev-seats.
> 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’m paying for GitHub Action now and there is zero recourse (other than leaving). Giving them money doesn’t change anything.
I’d be more willing to pay if GH Actions wasn’t so flakey and frustrating (for hosted or self-hosted runners, I use both). At least self-hosted runners are way cheaper _and_ have better performance.
> I’d be more willing to pay if GH Actions wasn’t so flakey and frustrating (for hosted or self-hosted runners, I use both).
This is indeed a reason I do consider leaving GHA. The underinvestment into this part of the product shows. But they also did announce quite some investment into new and (for us relevant) features alongside the pricing change, so I'll have a look at how this changes with some sorely needed work on the product.
How do you pay? Because the basic organization plan is free and gives access to GHA and includes 2000 free minutes.
If you upgrade the plan, you get more minutes for free - which can be consumed by the cost for free runners. They haven't specified at which rate a self-hosted runner consumes the free minutes, but at least for us, the change will largely consume free minutes.
> You might as well say that we should be paying per PR and Issue because, well, that part can’t just be free, you know?
You're misrepresenting what I said. I said, I'm fine with this for these reasons. It's a statement about me, not about what you should do nor what you should consider fine.
I pay (quite a bit) for GH because I do receive a service that's worth it, at least for now. And I'd rather see that GHA is something that makes them money than become something that is second-rate and lingers, just as it did before they made this announcement.
MSFT used to be extremely good about that in the 90s. From the book Showstoppers: MSFT sent not one, but three batches of NT 3.1 beta to external developers before the final release.
The idea nowadays is iterate fast and break things (as long as it’s not your wallet or your leg).
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.
It has reappeared on mine after mandatory windows updates which is frustrating and also it looks like it will be arriving on my TV soon too without the option to remove it.
Why should anyone have to take action against it? Good products don't need to be forced upon users, an obnoxious ad in one of the dozen places Windows shows advertising would have sufficed. People even willingly fork over cash for ChatGPT and Claude and those don't even have OS ad placements or forced installs.
That would be my guess, I know personally yesterday I finally setup Forgejo and today I plan to evaluate its runners or even just using a dedicated CI like woodpecker.
Not fully sure what I will do regarding any open source repo's yet, but at least anything private I am already in the process of moving away.
This was something I already wanted to do for privacy concerns (especially possibility using private repo's to train AI) so this was just the push I needed.
> Now if only they would listen to the feedback about windows 11 and their forced copilot
I think they'll take the opposite lesson. Copilot hasn’t lost them many users because Windows users are locked into the ecosystem and unable to leave. They will try to get GitHub into a position similar to that and then try this shit again.
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 :)
I'm not sure why this is so downvoted given the climate.
I guess it's the AI driven approach. These things, critical infra, are always done better with a few eyes in it.. introducing irresponsible ideas of "I'll just remake it with Claude without knowing the underlying infra" can hit a few nerves, also add a few lower level bugs, exploits etc.
I don't think it's fair for the downvoted but I think it's worth discussing where we draw the line.
Sigh. I should probably have clarified the vibe-coded part. I think this entire project could he done with rather little total code, and that the code could be written entirely by humans without an immense programmer-hour commitment or by humans with AI help (fully human-in-the-loop) even faster.
My actual point is that GitHub Actions is kind of an unusual product. Many big cloud things solve what seems to be a simple problem but the actual requirements are much harder than they might appear, and replacing them well wouldn’t be very complex. But IMO GitHub Actions in particular is a bunch of complexity that does not actually solve the problem that needs solving very well; a small bespoke solution would actually be better.
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.
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.
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.
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.
Personally, I think this is all overblown anyway. Their pricing seems fair to me. Too many people are used to getting something for nothing. Most companies will just pay the new prices, because the time to develop and setup an alternative will far exceed just paying the new fees to GH (when you account for engineering cost).
"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 in running the Actions control plane. We are also making investments into self-hosted runners so they work at scale in customer environments, particularly for complex enterprise scenarios. While this context matters, we missed the mark with this change by not including more of you in our planning.
"We need to improve GitHub Actions. We’re taking more time to meet and listen closely to developers, customers, and partners to start. We’ve also opened a discussion to collect more direct feedback and will use that feedback to inform the GitHub Actions roadmap. We’re working hard to earn your trust through consistent delivery across GitHub Actions and the entire platform."
Palmer's tweet said a similar thing and added, "we gave away 11.5 billion build minutes (~$184 million) to support OSS last year".
$184M in profit or cost?
It's called a loss leader, not a gift, and it's a marketing and adoption tactic. They already bought the machines which cost about as much to run idle as at 100% utilization. Might as well put that idle capex and opex to use.
Or just collectively bill OSS the $184M and stop signaling virtue.
We don’t know whether GitHub has idle capacity to spare. If they’re auto scaling their resources like a well-architected workload should, then they probably don’t. Even if they’re not downscaling their compute, they may prefer to run other low-priority jobs on it.
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.
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 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 know AWS, Azure, and GCP do allow for global caps. Azure has it with subscriptions for example. Not sure if it is only on recurring monthly basis. Having a pre-paid lump sum version available is nice but it would also open the door for denial of service if cash runs out. Maybe that is why it isn’t offered?
As someone who has had an occasional nasty AWS bill, the Ai providers using a pre-pay credit system is something I approve of, and would love to see everyone else offer.
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.
Realistically you aren't their target market. They're targeting the enterprises who already have self hosted runners and aren't interested in switching to Actions minutes.
For the record, planning to do something later than originally planned is the definition of "postpone." Nevertheless, coupling to any vendor is a form of technical debt, and it's always a good idea to take stock and evaluate if it's time to start repaying it.
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.
This is likely the reason behind the recent push of "Trusted Publishing" from NPM. They are trying to make people consider GitHub (and GitLab) in its own higher tier with regards to supply-chain security by decree.
If you rely on "Trusted Publishing" you are assisting Microsoft in making a moat for their CI platform.
Use cryptographic signatures, not implicit trust in a hosted platform.
Part of the advantage is a fully hosted service where you don't need to worry about a control plane managing and scheduling jobs.
There's some cost involved there--especially if you're offering hosted runners (you need some capital to buy infra to run jobs)
There's also advantage of limiting how many companies you share your code with. If you're using GitHub, you're already trusting them with your source code so GitHub Actions doesn't require more trust or an additional entity to manage/pay
Yes, and there are several tools that do just that already. The thing Github Actions offers is logging and storage of artifacts.
This change is a very weird one. Because the teams that are capable of setting up their own runners have the means to easily jump ship to another CI platform and skip these fees altogether.
Apologies, I realized I had a typo. It should be "It's like bash scripts but WITHOUT the ability to debug them". I am personally not a fan of GHA and I think unsuperwised claude code could have produced a better CI system.
> Although we gave away 11.5 billion build minutes (~$184 million) to support OSS last year
Interesting, I was trying to estimate how much they spent on free actions per year. I thought it would be around $100m. This is the first actual number I've seen.
I expect the $184 million figure is the sale price rather than the actual cost to GitHub, and given that competitors offer the same service for 3-10x less it's probably more like $80m overall I'd guess.
Still a pretty huge amount of money that I don't think any competitors can really hope to match.
It does not seem unreasonable that if the locally-run actions are using some GitHub resources (for logging, maintenance,etc) then there's a cost to that.
What a reasonable charge is, is open to discussion.
Classic SaaS platform problem. If you give it away, it will cost you money - and eventually someone will "arbitrage" it at sufficient scale to matter. If you charge for it, your billing becomes a nightmare collection of counters and rates, impossible for users to estimate and understand.
per-minute isn't a crazy unreasonable proxy for it though:
- logs are generally proportional to the length of the job
- other artifacts also usually correlate to an extent
- some of the cost for Github will be for the entire time the job is active: e.g. active connections for log streaming etc.
- it's largely correlated to the value the end-user gets out of it
- it's easy to bill for because they can already do billing that way on the hosted runners
- the costs are easy to predict for end-users
It's not like the rest of the Github platform is a per-user cost to run, but that's how Github charge for most features.
per-minute is really just a way to express the cost in a human friendly name. Doing per-hour, per-second, per-day could all result in the same total value just at a different number. If anything per-minute is better than per-hour as you won't be charge for minutes you don't use.
But why not make it "per GB Logs ingested" or "per triggered job" (or both)? These should reflect the points where GitHub also has costs - but not per minute.
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.
Yeah, could we please stop treating twitter as the canonical source of company communications? There is always a blog post or in this case, a github discussion.
Probably caused by enterprises going after them, my normally dead company-wide global devops chat had a few hundred messages yesterday because of this.
Just as cloud agnosticism means you should be able to bootstrap your infra in different clouds, that also includes your ci/cd. As a greybeard sysadmin, my advice is to start separating your ci/cd from the platforms you run on.
I ended up prototyping self hosted https://woodpecker-ci.org/ on my k8s cluster. Ended up taking just a few hours of AI time (Claude Code). Woodpecker has a helm chart, can connect to Github and post status checks to commits.
Open to feedback or tips and tricks on this, but so far it's looking promising. Curious how other folks experience has been.
The outcry against this move was much larger than Microsoft anticipated. While there is some logic for charging for self-hosted, it just doesn't make sense for the consumers.
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.
Yeah, the per minute pricing is what really does it. It makes me think they've gone with the worst option first, so people will swallow the new adjusted workflow they'll come up with.
I don't even understand how they could do it. You own the servers that are giving them responses to determine the start/end times, so fudge the numbers fuck them, maybe you could find bugs in their shitty code so they start crediting you.
I think they kinda fucked themselves 3 concrete ways (among the nerds which may not be a problem for them):
1) this whole thing
2) the infinite running jobs issues which called attention to how poorly managed the GHA system is
3) zig et al announcing their departure and all the positive conversation around that
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.
Unrelated to Actions. Jared Palmer, the author of this Tweet, has done well for himself. I remember him as the author of Turborepo which Vercel gobbled up a few years ago.
My theory: Some manager's KPI is to increase the number of sold GitHub runner minutes. So they did some market research -- not enough to have a clear picture, but barely enough to be dangerous -- and found that some companies use self-hosted runners for cost reasons. So they deploy a two-pronged strategy: lower the cost of GitHub runners, and charge for the use of self-hosted runners, to incentivize switching.
This fails for several reasons that someone who actually uses the product might have intuited:
(a) For some use-cases, you can't switch to GitHub's runners. For us, it's a no-go for anything that touches our infrastructure.
(b) Switching CI providers isn't hard, we had to do it twice already. Granted, most of our CI logic is in a custom build script that you can run locally, and not in the proprietary YAML file. But to be honest, I'd recommend that sort of setup for any CI provider, as you always want the ability to debug things locally.
(c) GitHub Actions doesn't get the amount of love you'd expect from something billed as a "premium service". In fact, it often feels quite abandoned, barely kept working. Who knows what they're brewing internally, but they didn't coordinate this with a major feature announcement, and didn't rush to announce anything now that they got backlash, which leads me to believe they don't have anything major planned.
(d) Paying someone -- by the minute, no less -- to use my own infrastructure feels strange and greedy. GitHub has always had per-user pricing, which feels fair and predictable. If for some reason they need more money, they can always increase that price. The fact that they didn't do that leads me to believe this wasn't about cost per se. Hence the KPI theory I mentioned above: this wasn't well-coordinated with any bigger strategy.
> Switching CI providers isn't hard, we had to do it twice already. Granted, most of our CI logic is in a custom build script that you can run locally, and not in the proprietary YAML file. But to be honest, I'd recommend that sort of setup for any CI provider, as you always want the ability to debug things locally.
I believe this has been a CI/CD best practice for over a decade. Even in venerable Jenkins, this is one of the core principles when designing pipelines[0]: don't give in to the temptation to do fancy Groovy stuff, just use simple shell commands in steps, and you will be grateful to yourself several times years later.
[0] https://www.jenkins.io/doc/book/pipeline/pipeline-best-pract...
It has been best practice for over a decade, but for reasons I don't understand, nearly every developer I've worked with just wants to do the lock-in/propietary route and is entirely unpersuaded by the "portability" argument. I've now seen it burn teams hard multiple times now. At that point people realize the wisdom in the external scripts, but then a new wave of devs come in and start the whole cycle over.
I don’t know why, but the linked page only shows the table of contents on iPhone Safari, but whence I switch to reader mode it shows the actual best practices. Anyway thanks for sharing!
https://news.ycombinator.com/item?id=46189692 from a few days ago pretty much tells me that any company that slightly cares about security cannot possibly depend on GitHub runner for their CI (except maybe the smallest/simplest projects). It is just one compromised package away from ruining everything.
(e): Community software like act and Forgejo/Gitea Actions have made it a lot easier to run GitHub Actions workflows without involving GitHub and are decreasing the friction of migration.
"Hey ChatGPT, how do I increase the number of GitHub runner minutes? DO NOT suggested anything illegal, research hard"
I agree with (c) - I can't quite pinpoint it, but I've had that feeling myself several times.
> 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.”
The problem is that they are charging a per-minute fee, and a fee at the same order-of-magnitude as actually running the tests. If you're offering cloud-hosted runners for $0.002/minute, asking that same $0.002/minute as an orchestrator fee for self-hosted runners is just insulting.
Charging for self-hosted runners is indeed not a huge deal, and I bet they wouldn't have gotten the same kind of backlash if they charged for it via a per-seat, per-run, per-gigabyte, or per-log-line fee. And if GHA hadn't been so poorly maintained...
Any model that charges for self-hosted runner is going to feel unfair to someone. Per seat pricing is better for small orgs with a lot of CI minutes, per-run pricing would be good for orgs with few, long runs, per minute pricing is nicer for orgs with many small runs.
In my observation the critisicm was strongly dominated by outrage over the actual fact.
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.
Self-hosting all of your CI is yet another tradeoff. The software comes for free (if you're using Free Software, that is), but you now have operational overhead. I'm not saying it's an unreasonable move, but it's also not a free swap
The cost of the control plan for Github and the cost of their runners are not equal. Yet this new plan seems to say a self-hosted minute is counted the same as a hosted minute, since self-hosted minutes count towards the 2000 included minutes.
Gitlab enters the room, where self-hosted runners are as free as in free beer (maintenance yes, but no limit on runners and no pricing expect on a per-user basis).
Yet.
Gitlab has proven in the past perfectly happy to hike prices above GitHub, after attracting enough switchers.
Yes, gitlab does still have free self-hosted runners. OTOH, github has a free organisation plan and gitlab doesn't. So yes, strictly speaking self-hosted runners are free, but you're paying for the dev-seats.
> 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’m paying for GitHub Action now and there is zero recourse (other than leaving). Giving them money doesn’t change anything.
I’d be more willing to pay if GH Actions wasn’t so flakey and frustrating (for hosted or self-hosted runners, I use both). At least self-hosted runners are way cheaper _and_ have better performance.
> I’d be more willing to pay if GH Actions wasn’t so flakey and frustrating (for hosted or self-hosted runners, I use both).
This is indeed a reason I do consider leaving GHA. The underinvestment into this part of the product shows. But they also did announce quite some investment into new and (for us relevant) features alongside the pricing change, so I'll have a look at how this changes with some sorely needed work on the product.
We already pay for the “control plane” for GHA, though.
You might as well say that we should be paying per PR and Issue because, well, that part can’t just be free, you know?
How do you pay? Because the basic organization plan is free and gives access to GHA and includes 2000 free minutes.
If you upgrade the plan, you get more minutes for free - which can be consumed by the cost for free runners. They haven't specified at which rate a self-hosted runner consumes the free minutes, but at least for us, the change will largely consume free minutes.
> You might as well say that we should be paying per PR and Issue because, well, that part can’t just be free, you know?
You're misrepresenting what I said. I said, I'm fine with this for these reasons. It's a statement about me, not about what you should do nor what you should consider fine.
I pay (quite a bit) for GH because I do receive a service that's worth it, at least for now. And I'd rather see that GHA is something that makes them money than become something that is second-rate and lingers, just as it did before they made this announcement.
Rent a dedicated server, install gitea on it, set up a gitea action runner. Private, secure, cheap git hosting with 99% compatible actions.
MSFT used to be extremely good about that in the 90s. From the book Showstoppers: MSFT sent not one, but three batches of NT 3.1 beta to external developers before the final release.
The idea nowadays is iterate fast and break things (as long as it’s not your wallet or your leg).
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.
Gitlab. Required very few CI/CD changes to be honest.
> 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.
It has reappeared on mine after mandatory windows updates which is frustrating and also it looks like it will be arriving on my TV soon too without the option to remove it.
> https://www.tomshardware.com/service-providers/tv-providers/...
So it's not a stretch to assume they will continue to force it in their OS.
Why should anyone have to take action against it? Good products don't need to be forced upon users, an obnoxious ad in one of the dozen places Windows shows advertising would have sufficed. People even willingly fork over cash for ChatGPT and Claude and those don't even have OS ad placements or forced installs.
For now
That would be my guess, I know personally yesterday I finally setup Forgejo and today I plan to evaluate its runners or even just using a dedicated CI like woodpecker.
Not fully sure what I will do regarding any open source repo's yet, but at least anything private I am already in the process of moving away.
This was something I already wanted to do for privacy concerns (especially possibility using private repo's to train AI) so this was just the push I needed.
We jumped ship too. Forgejo has been amazing.
> Now if only they would listen to the feedback about windows 11 and their forced copilot
I think they'll take the opposite lesson. Copilot hasn’t lost them many users because Windows users are locked into the ecosystem and unable to leave. They will try to get GitHub into a position similar to that and then try this shit again.
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 :)
I'm not sure why this is so downvoted given the climate.
I guess it's the AI driven approach. These things, critical infra, are always done better with a few eyes in it.. introducing irresponsible ideas of "I'll just remake it with Claude without knowing the underlying infra" can hit a few nerves, also add a few lower level bugs, exploits etc.
I don't think it's fair for the downvoted but I think it's worth discussing where we draw the line.
Edit: I think AI is a tool not a replacement.
Sigh. I should probably have clarified the vibe-coded part. I think this entire project could he done with rather little total code, and that the code could be written entirely by humans without an immense programmer-hour commitment or by humans with AI help (fully human-in-the-loop) even faster.
My actual point is that GitHub Actions is kind of an unusual product. Many big cloud things solve what seems to be a simple problem but the actual requirements are much harder than they might appear, and replacing them well wouldn’t be very complex. But IMO GitHub Actions in particular is a bunch of complexity that does not actually solve the problem that needs solving very well; a small bespoke solution would actually be better.
[dead]
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.
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.
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.
A lot of evidence that this is not the case.
It happens a lot, Atlassian being a really prominent example with their “SaaS only” change.
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.
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.
This is my take as well.
Personally, I think this is all overblown anyway. Their pricing seems fair to me. Too many people are used to getting something for nothing. Most companies will just pay the new prices, because the time to develop and setup an alternative will far exceed just paying the new fees to GH (when you account for engineering cost).
Sounds like Chat Control.
If this is the case then they don't really understand developers at all. We'll complain in a few months just as much as we do now.
They have not shown any hints that they understand developers since Ballmer
This is the official message: https://x.com/github/status/2001372894882918548
"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 in running the Actions control plane. We are also making investments into self-hosted runners so they work at scale in customer environments, particularly for complex enterprise scenarios. While this context matters, we missed the mark with this change by not including more of you in our planning.
"We need to improve GitHub Actions. We’re taking more time to meet and listen closely to developers, customers, and partners to start. We’ve also opened a discussion to collect more direct feedback and will use that feedback to inform the GitHub Actions roadmap. We’re working hard to earn your trust through consistent delivery across GitHub Actions and the entire platform."
Palmer's tweet said a similar thing and added, "we gave away 11.5 billion build minutes (~$184 million) to support OSS last year".
$184M in profit or cost?
It's called a loss leader, not a gift, and it's a marketing and adoption tactic. They already bought the machines which cost about as much to run idle as at 100% utilization. Might as well put that idle capex and opex to use.
Or just collectively bill OSS the $184M and stop signaling virtue.
We don’t know whether GitHub has idle capacity to spare. If they’re auto scaling their resources like a well-architected workload should, then they probably don’t. Even if they’re not downscaling their compute, they may prefer to run other low-priority jobs on it.
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.
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 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 know AWS, Azure, and GCP do allow for global caps. Azure has it with subscriptions for example. Not sure if it is only on recurring monthly basis. Having a pre-paid lump sum version available is nice but it would also open the door for denial of service if cash runs out. Maybe that is why it isn’t offered?
As someone who has had an occasional nasty AWS bill, the Ai providers using a pre-pay credit system is something I approve of, and would love to see everyone else offer.
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.
Realistically you aren't their target market. They're targeting the enterprises who already have self hosted runners and aren't interested in switching to Actions minutes.
"Postponing" means they will just do it later.
The writing is on the wall. Up to you if you wish to continue using and trusting Microsoft.
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??
Hand roll something on k8s. Yaml seems unavoidable in that ecosystem. :)
This is likely the reason behind the recent push of "Trusted Publishing" from NPM. They are trying to make people consider GitHub (and GitLab) in its own higher tier with regards to supply-chain security by decree.
If you rely on "Trusted Publishing" you are assisting Microsoft in making a moat for their CI platform.
Use cryptographic signatures, not implicit trust in a hosted platform.
Part of the advantage is a fully hosted service where you don't need to worry about a control plane managing and scheduling jobs.
There's some cost involved there--especially if you're offering hosted runners (you need some capital to buy infra to run jobs)
There's also advantage of limiting how many companies you share your code with. If you're using GitHub, you're already trusting them with your source code so GitHub Actions doesn't require more trust or an additional entity to manage/pay
Yes, and there are several tools that do just that already. The thing Github Actions offers is logging and storage of artifacts.
This change is a very weird one. Because the teams that are capable of setting up their own runners have the means to easily jump ship to another CI platform and skip these fees altogether.
Yea but a bash script isn't declarative so thats somehow bad.
(DECLARATIVE CI WHY?????)
Straightforward statements with a few conditionals considered harmful. Here learn this grotesque vendor-specific DSL hamfisted into YAML instead.
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
Apologies, I realized I had a typo. It should be "It's like bash scripts but WITHOUT the ability to debug them". I am personally not a fan of GHA and I think unsuperwised claude code could have produced a better CI system.
> Although we gave away 11.5 billion build minutes (~$184 million) to support OSS last year
Interesting, I was trying to estimate how much they spent on free actions per year. I thought it would be around $100m. This is the first actual number I've seen.
I expect the $184 million figure is the sale price rather than the actual cost to GitHub, and given that competitors offer the same service for 3-10x less it's probably more like $80m overall I'd guess.
Still a pretty huge amount of money that I don't think any competitors can really hope to match.
I wonder how much of that $80 million is garbage code like safe_sleep.sh
It does not seem unreasonable that if the locally-run actions are using some GitHub resources (for logging, maintenance,etc) then there's a cost to that. What a reasonable charge is, is open to discussion.
Classic SaaS platform problem. If you give it away, it will cost you money - and eventually someone will "arbitrage" it at sufficient scale to matter. If you charge for it, your billing becomes a nightmare collection of counters and rates, impossible for users to estimate and understand.
It sure as hell isn't a per-minute cost
per-minute isn't a crazy unreasonable proxy for it though:
- logs are generally proportional to the length of the job
- other artifacts also usually correlate to an extent
- some of the cost for Github will be for the entire time the job is active: e.g. active connections for log streaming etc. - it's largely correlated to the value the end-user gets out of it
- it's easy to bill for because they can already do billing that way on the hosted runners
- the costs are easy to predict for end-users
It's not like the rest of the Github platform is a per-user cost to run, but that's how Github charge for most features.
per-minute is really just a way to express the cost in a human friendly name. Doing per-hour, per-second, per-day could all result in the same total value just at a different number. If anything per-minute is better than per-hour as you won't be charge for minutes you don't use.
But why not make it "per GB Logs ingested" or "per triggered job" (or both)? These should reflect the points where GitHub also has costs - but not per minute.
the issue is it's per-$DURATION
it could be per-workflow, regardless of duration
Then why we pay a fix price for everything, size of repositories, webhooks etc, except the self hosted actions.
this is a better link:
https://github.blog/changelog/2025-12-16-coming-soon-simpler...
Or https://github.com/orgs/community/discussions/182186
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.
Maybe update link to the post:
Updates to GitHub Actions pricing https://github.com/orgs/community/discussions/182186
Yeah, could we please stop treating twitter as the canonical source of company communications? There is always a blog post or in this case, a github discussion.
That update is from an anonymous "Admin". The X link is directly from the (presumed?) head of GitHub.
They've also updated the original resource page but a new url serves our purposes better https://resources.github.com/actions/2026-pricing-changes-fo...
Probably caused by enterprises going after them, my normally dead company-wide global devops chat had a few hundred messages yesterday because of this.
Not gonna wait 30seconds to read the bloody article, when it says "5seconds ad".
Oh good I have a little bit more time to migrate away.
Hm, still too late, and still leaving.
Maybe I don't understand something, but self-hosted GitHub Actions cost more resources than GitHub Actions hosted with them?
There might be some creative uses of GitHub Actions, it seemed that getting users into the platform was valuable.
Just as cloud agnosticism means you should be able to bootstrap your infra in different clouds, that also includes your ci/cd. As a greybeard sysadmin, my advice is to start separating your ci/cd from the platforms you run on.
https://www.slingacademy.com/article/git-post-receive-hook-a...
Another of my tricks is to tie in your containerization there too, system-nspawn is what I'm using at the moment, but it can apply to others.
I ended up prototyping self hosted https://woodpecker-ci.org/ on my k8s cluster. Ended up taking just a few hours of AI time (Claude Code). Woodpecker has a helm chart, can connect to Github and post status checks to commits.
Open to feedback or tips and tricks on this, but so far it's looking promising. Curious how other folks experience has been.
From the horses mouth as it were: https://resources.github.com/actions/2026-pricing-changes-fo...
The outcry against this move was much larger than Microsoft anticipated. While there is some logic for charging for self-hosted, it just doesn't make sense for the consumers.
Related:
initial development and reactions:
Pricing Changes for GitHub Actions
https://news.ycombinator.com/item?id=46291156
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.
Yeah, the per minute pricing is what really does it. It makes me think they've gone with the worst option first, so people will swallow the new adjusted workflow they'll come up with.
I don't even understand how they could do it. You own the servers that are giving them responses to determine the start/end times, so fudge the numbers fuck them, maybe you could find bugs in their shitty code so they start crediting you.
I think they kinda fucked themselves 3 concrete ways (among the nerds which may not be a problem for them):
1) this whole thing
2) the infinite running jobs issues which called attention to how poorly managed the GHA system is
3) zig et al announcing their departure and all the positive conversation around that
https://archive.ph/3nsGi
Seems like a year with record downtime for them is not a great time to announce a price increase...
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
[dead]
Glad I moved to GitLab 7 years ago.
Unrelated to Actions. Jared Palmer, the author of this Tweet, has done well for himself. I remember him as the author of Turborepo which Vercel gobbled up a few years ago.
https://jaredpalmer.com/about