alt Hacker NewsPricing Changes for GitHub Actions
Comments
Given they've been essentially subsidizing self-hosted orgs for a while, I'm kinda surprised they didn't do this before now. Probably wanted to lead with the price cut for everyone else.
It'll be interesting to see how this affects third party companies providing GitHub runners.
A few years ago, I had a build that was a bit slow on Github actions. I didn't want to switch to the paid plan just to spin up a worker. Basically we are a bootstrapped company with, at the time, no budget to pay ourselves or for extra stuff like fancy build servers. If you are that kind of company, Github is amazing value.
To solve the problem, I created a simple vm in Google Cloud with a lot of CPU and memory that runs Ubuntu. I installed enough stuff on it to be able to check out code and run our build script (a jvm and gradle basically). And then I modified the Github action to 1) start the vm, 2) trigger the build script via ssh 3) pause the vm so we don't get billed for it. That vm runs for maybe an hour per month or so. It would probably cost us hundreds of euros per month if we ran it 24/7. But 1/3600th of that barely registers on our bills. And it's nice and fast.
This has been working flawlessly for a few years now. The Github action takes about 3 minutes. That includes starting the vm, running the script, and shutting the vm down again.
Wonky in a way. But also simple and robust enough. People over engineer/over think this stuff for the wrong reasons. For example, I could of course automate the provisioning of that vm. But I haven't. Because I only ever touch it once a year or so to run a quick apt-get update. I rebuilt it a few weeks ago in a different region. That was like a 20 minute job. Terraform or Ansible for vms you only create once every few years is redundant and might take more time than you would save. I can always do that when that stops being true.
I've been running this startup on the freemium layer in Github for five years now. It's great as a free service. I would actually pay for it if I needed to. I did actually pay for it before MS acquired Github in a previous startup when business usage wasn't free. But so far, there's no need for me to do that. I also run some monitoring scripts as Github actions. Simple curl jobs against our servers that trigger alerts when they fail. That has to run somewhere. It might as well be Github actions. But if/when that becomes inconvenient, I can improvise other solutions.
I'm late to the party, but Gitea as has Gitea Actions[0] based on their fork[1] of act[2]. Their claim is that it's mostly compatible with GitHub Actions. I wonder if this can be spun off to have the control plane run separately and integrate into GitHub Action. Or alternatively mirror the repo for Gitea Actions only.
[0] https://docs.gitea.com/usage/actions/overview
[1] https://gitea.com/gitea/act / https://gitea.com/gitea/act_runner
This sucks, it make me feel so silly after decide to move back to github self hosted runners just because I do not want to run act on a remote ARM64 server.
I was just using act (https://github.com/nektos/act) on my local server to build the X64 packages for my project, since I want to streamline it with ARM64 support, I migrated to the github self hosted runners.
This is really ridiculous, is M$ really lack that money just to schedule the Jobs running not in there infra?
If Github runs the control plane, I presume there would be some costs to that. Consider the costs of hosting a control plane that assigns jobs to runners, receives and processes heart beat signals, receives log streams, exchanges file artifacts with the runner. Such actions would take up compute for the Control Plane.
Are Control Plane costs already separately charged?
My take as a cofounder of Shipfox, a company working on alternative GitHub Actions runners (same space as Depot, Blacksmith, Namespace). The price update itself wasn't very surprising. GitHub-hosted runners historically carried a significant premium given the underlying hardware, which isn't particularly well suited for CI workloads that are often CPU-intensive. Lowering prices there makes sense and better reflects real usage. Pricing self-hosted runners also feels logical from GitHub's perspective. Until now, GitHub Actions generated little direct revenue from self-hosted usage, despite still providing orchestration, Actions Marketplace, etc. Given how widely self-hosting is used, it's hard to imagine that remaining free forever. For users of GitHub-hosted runners, this is clearly good news. For teams running self-hosted runners, the impact can be noticeable. For example, if your infrastructure previously achieved a per-minute cost about half of GitHub's hosted 2 vCPU rate (a conservative assumption), adding a $0.002/min fee effectively moves the total from ~$0.004 to ~$0.006 per minute, roughly a 50% increase. In setups that were much cheaper than hosted runners, the relative increase is even higher. That said, most teams don't self-host purely to save money. Performance, hardware control, and security or compliance requirements are usually the main drivers. This change doesn't remove those benefits, but it does change the cost equation and likely forces a reassessment.
So Microsoft is slowly killing it. Not surprising.
IMO it's long time coming. Streaming logs and other supporting functionality is not free. We at Cirrus Runners provide runners as a service for a fixed monthly price with unlimited usage. We target large entrerprises that save $100K+ yearly by switching to us (10-25 times). In our calculations the new per-minute fee is roughly ~0.1% of the effective per-minute cost our customers avoid by using our fixed-price model. Over providers with the traditional per-minute pricing will have bigger impact.
GitHub actions are expensive enough that self-hosted was the only real option. I can't imagine this will do anything other than push people from the entire ecosystem.
Git was supposed to be "distributed", but we ended up with a central HTTP hub.
Can't we switch to something more advanced in terms of protocols (like one that always maintain 3 copies, and where people can give ressources (cpu/bandwidth/memory) in the forms of tokens)?
Will OSS (public) repositories also have to pay if they use self-hosted GitHub runners ? If yes, that seems a bit counterintuitive, given that Github hosted runners are free for public repos.
Why would a public repo use a self-hosted runner ? because the self-hosted runner storage available is only 14GB !!
I just convinced the team to switch to GitHub Actions self hosted for various reasons, but one of them being cost.
This is an insult to anyone who bought into GitHub. It's an insult to all of us who have been doing OSS there for years. This is how you kill your business and any loyalty or trust in your brand.
What a disaster.
Here are the practical implications and considerations to optimize for cost, given the new pricing. These are generic and ensure you think through your workflows and runners before making any changes.
1. Self-hosting runners or using WarpBuild/blacksmith runners is still cheaper Despite the $0.002/minute self-hosted runner tax, self-hosting runners on your cloud (aws/gcp/azure/...) or using WarpBuild/... runners remains the cheaper option.
2. Prefer larger runners If your workflow scales with the number of vCPUs, prefer larger runners. That ensures you spend fewer minutes on the runner, which reduces the GitHub self-hosted runner tax.
For example, using actions-runner-controller with heavy jobs running on 1 vcpu runners is not a good idea. Instead, prefer a 2vcpu runner (say) if it runs the job ~2x faster.
3. Prefer faster runners All else being equal, prefer faster runners. That ensures you spend fewer minutes on the runner, which reduces the GitHub self-hosted runner tax.
For example, if you're self-hosting on aws and using a t3g.medium runner, it's better to use a t4g.medium runner since the newer generation is faster, but not much more expensive.
4. Prefer fewer shards If you have a lot of shards for your jobs (example: tests on ~50 shards), consider reducing the number of shards and parallelizing the tests on fewer but larger runners.
5. Improve job performance This is not new advice, but it's now more important than ever because of the additional GitHub self-hosted runner tax.
6. Use GitHub hosted runners for very short jobs For linters and other very short jobs, it's better to use GitHub hosted runners.
Hope this helps. Note: I'm the founder of WarpBuild. I'm biased, but the points above hold.
The urge to move to Codeberg grows with every passing day.
The reason this makes sense, at least for Github, is because the only valid reason to run your own action runners is compliance. And if you are doing it for compliance, price doesn't really matter. You don't really have a choice.
If you've been running your runners on your own infra for cost reasons, you're not really that interesting to the Github business.
Say I wanted to run the GitHub Action's "self hosted" runner on my own infra, then integrate it with my repo using webhooks (like I would for other CI platforms). What value would I be losing?
There are several features that are only available if you self host github runners like this concurrency issue[1] that has been open for 3 years with the only solution being to use self hosted runners. So you'd expect at least a new product release that fixes these issues before they start rug pulling people.
Yeah... Kind of expected GHA to be a money trap at some point. It was tempting with how easy it is to setup. And every since Claude Code integrated tightly it assumes i want pipelines in gha even though I have pipelines elsewhere. Glad I stuck with picking a different system and didn't invest a lot of time here. I had plenty of compute to run jobs myself.
At getstream.io we ended up running Github Actions on Hetzner. The end-result is 4x faster builds for 3x less $$$.
Running workers ourselves was the last resort, we tried everything else but it was impossible to get fast (and consistent) build times otherwise.
In a way we are now going to get charged for Github's poor execution on Actions.
So instead of addressing their runners being extremely slow to the point that a reasonable person would think it's deliberate in order to extract more billable minutes, they're charging customers for using an alternative. Makes sense.
I'm a little surprised at the outrage here. I guess sure if you're using tiny self-hosted runners this would be significant, but if you're using even an 8 vCPU machine from blacksmith for instance (16 cents per minute), this is roughly 10% extra. That seems reasonable for them providing the platform?
It’s interesting to see the posts from warpbuild, blacksmith, buikdjet and others defending their business model that was based on the inefficiency of GitHub. I love the fact that git is built in such an open way that if you are worried about running in your own infrastructure you can easily deploy it (It’s just like SSH!) yourself. At least for me, cheaper GitHub actions is a win because I can’t justify running my own git. But these companies that are based on offering you a faster or cheaper github actions service are actually the worst of both worlds: they are not your platform and they are not in the position to offer you a better service. I’m not gonna miss them when they’re gone or transformed into an AI pivot.
Probably long overdue, but per-minute price vs per-job is quite expensive. Wouldn’t like to be in the shoes of “only” 2x cheaper third parties. If they follow up with faster runners… interested to see if they ever come up with a good SDK for their scale set API, will integrate it in RunsOn!
At $0.002 per minute there are at most 90 dollars in a month. Maybe even after an year of cumulative costs it's less then the cost of switching to something else. Maybe even after many and many years of cumulative costs: the larger the company the more expensive corporate inertia gets.
In theory I assume you could rebuild an 'open GitHub actions' that maintained the existing API and used webhook events to trigger a workflow and github API to post status back into GitHub.
The funny thing is if GitHub let me pay extra for an actions runner that was not a potato, I would happily give them so much money. Instead they want to penalize me for working around their broken product.
Charging by minute might push people toward shorter, noisier and more fragmented pipelines. It feels more like a lever to discourage selfhosting over time.
It's not outrageous money today, but it's a clear signal about where they want CI to live.
More than 6 years users of OneDev (onedev.io).
- Git repo - Ticketing, Kaban - Full helpdesk - Complete and full CI/CD - everything links via custom workflow - self hosted
I still dont know why everyone hasn't switch yet to that banger.
Github, thanks for making this service available free for public repos, it's a big boon. Currently the runner has only 14GB of disk space, if that can be made to 50 GB, that would be amazing !
this is the third article about it, we know, good times are over, will start migrating towards something else
Our org just migrated from Bitrise to self-hosted GHA runners just a couple of months ago, with cost savings as a main reason. I already foresee an interesting conversation coming up tomorrow.
$LLM spinup a jenkins cluster on my qa infrastructure please
Charging for the self hosted runners - That's close to flat $90 per month for a machine that you host yourself no matter how small or large the machine is.
So they are finally doing this. Our github account rep mentioned this back in February, but then they kept postponing and heard nothing so I was hoping they realized how stupid this idea was and abandoned it.
My org sadly has a lot of github actions workflows, even after this it's not expensive enough to justify migrating away, but with all their downtime and bugs they are really pushing us closer and closer.
This is a serious issue. How is it possible for GitHub/Microsoft to charge me for using my own machine as a self-hosted GitHub Actions runner?
hoping for some disruption here. gha is an absolutely horrid platform for anyone trying to build optimized workflows. so many bugs / rough edges that haven't been addressed for years, the hosted runners feel like decade old compute. missing all of the modern features (like dynamic pipelines) other providers offer.
to top it all off, they round up to the nearest whole minute instead of billing for actual usage which i assume they'll use for this new charge.
If they charge me for my self-hosted runner i will just move to Gitlab. This is theft..or let's say this is microsoft.
I understand that orchestration,log storage, keeping software updated can cost money, which they seem to recover from charging for software. Hopefully there is support now included with self hosted runners being charged.
I assume they want us to pay for their orchestration and also push customers back to using their compute so everything is stickier.
But nothing they've done in the last few years has demonstrated improvement in this area. As the person with both purchasing and final authority on these things in my org, it's hard to stomach.
Just dropping in to say how lovely the Gerrit experience is when compared to GitHub: https://www.gerritcodereview.com/
I would remind everyone that lots of free solutions like Forgejo exist with much better security posture.
Geez. This would've been much more agreeable had they bothered to fix years-old open bugs with self-hosted runners
How will this hit OSS projects which rely heavily on github actions? I’m thinking of projects like nixpkgs, which is the backbone of nixos and always has dozens of actions queued or running. (I am using nix as an example for scale, but I am not involved in the project and my description might be inaccurate. I’m also not familiar with nix’s financials at all.)
Are there bring-your-own-agent CI platforms that don't have pricing structures like this? Buildkite and CircleCI do.
With their availability issues it will be hard to forecast costs of “continuous” operation. I guess everyone using ARC can get rekt, why would you put in the work to move to their next bs when you can just leave?
Ah the monoculture comes back to haunt people. Who could have seen that one coming?
> > We are introducing a $0.002 per-minute Actions cloud platform charge for all Actions workflows across GitHub-hosted and self-hosted runners.
Holy s***
That's more expensive than an m8i.large.
What on earth.
We're microsoft. We don't care. We don't have to care, we're microsoft. Lock in? Embrace, expand, extinguish? Anti-competive? Anti-trust? We don't care. We don't have to care. Pay taxes? We don't have to pay taxes (https://www.propublica.org/article/irs-microsoft-audit-back-...). We're ... etc.
This is not new, not unexpected. This is ongoing. Nothing stops this because who wins elections? How do they pay for all that publicity. Certainly "contributing" to campaigns is much cheaper than paying your taxes.
Supposedly this is a place for hackers. Hackers can build a better alternative.