I got contacted by our rep a couple weeks ago, who informed me of this news. I thought it was a disaster and it really pissed me off. The rep couldn't even explain the reasoning well. It basically summed up to "because we can" and "where are you going to go?". He was shocked to find out that I didn't like it.
We currently self-host on kubernets/aws. The thing that really got to me isn't the new charge per se. It's the fact that GHA has a ton of problems. I can hold my nose and deal with them when it's free. But now that you're squeezing me, at least you could have created something like GHA 2.0 and added a charge for that. Instead, there are vague roadmap promises which don't even include things that I care about. Specifically:
- Jenkins had better kubernetes integration years ago. It's crazy that GHA can't beat that.
- "Reintroducing multi-label functionality" - yeah, so they first broke it. They did supply "reasons", which looked like they never talked to a customer. [1]
- Still no SDK of any kind.
- "Actions Data Stream" - or you can just fix your logging.
There are dozens more complains, which are easy enough to find. This kind of an approach just makes me want to make sure that I don't use GHA again. Even if I end up paying another vendor, at least I'll be treated as a customer.
"Thank you for your interest in this GitHub action, however, right now we are not taking contributions.
We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time. The GitHub public roadmap is the best place to follow along for any updates on features we’re working on and what stage they’re in."
This kinda change also has some different gears turning in my head. At $0.002 / build-minute, some of our large software integration tests would cost us around 15 - 20 cents. Some of our ansible integration tests would be 5 - 10 cents - and we run like 50 - 100 of those per day. Some deployments might cost us a cent or two.
Apples to oranges, naturally, but like this, our infra-jenkins master would pay for itself in hosting in a week of ansible integration testing compared to what GHA would cost. Sure, maintenance is a thing, but honestly, flinging java, docker and a few other things onto a build agent isn't the time-consuming part of maintaining CI infrastructure.
And I mean sure, everything is kinda janky on Jenkins, but everything falls into an expectable corridor of jank you get used to.
> Sure, maintenance is a thing, but honestly, flinging java, docker and a few other things onto a build agent isn't the time-consuming part of maintaining CI infrastructure.
Depending on your workplace, there's a whole extra layer of bureaucracy and compliance involved if you self-host things. I aggressively avoid managing any VMs for that reason alone.
Luckily, at work we are this layer of bureaucracy and compliance. I'm very much pushing the agenda and idea that managing a stateful, mutable linux VM is a complex skill on it's own and incurs toil that's both recurring and hard to automate. The best case to handle that is to place your use case into our config management and let us manage it.
Most modern development workflows should just pickup a host with some container engine and do their work in stateless containers with some external state mapped in, like package caches. It's much easier for both sides in a majority of cases.
Last place I worked had long running end to end tests that would take 30 minutes on GHA (compared to maybe 5 locally) on every PR. This is going to make that a very expensive endeavour
> And I mean sure, everything is kinda janky on Jenkins, but everything falls into an expectable corridor of jank you get used to.
Self-hosting Jenkins on an EC2 instance is probably going to result in a _better_ experience at this point. Github Cache is barely better than just downloading assets directly, and with Jenkins you can trivially use a local disk for caching.
Or if you're feeling fancy and want more isolation, host a local RustFS installation and use S3 caching in your favorite tools.
And if you want any concurrency at all, you need 1 runner registration per concurrent job. And each runner needs its own user. And each runner requires a full and separate copy of the runner software, which is large (hundreds of megs) and self-updates.
I am developing a self-hosted solution for this [1]. It’s true that it’s somewhat of a pain but JIT runners allow a lot of flexibility that we don’t find elsewhere.
Introducing a separate charge specifically targeting those of your customers who choose to self-host your hilariously fragile infrastructure is certainly a choice.. And one I assume is in no way tied to adoption/usage-based KPIs.
Of course, if you can just fence in your competition and charge admission, it'd be silly to invest time in building a superior product.
We've self-hosted github actions in the past, and self-hosting it doesn't help all that much with the fragile part. For github it is just as much triggering the actions as it is running them. ;) I hope the product gets some investment, because it has been unstable for such a long time, that on the inside it must be just the usual right now. GitHub has by far the worst uptime of any SaaS tools we use at the moment, and it isn't even close.
> Actions is down again, call Brent so he can fix it again...
We self host the runners in our infrastructure and the builds are over 10x faster than relying on their cloud runners. It's crazy the performance you get from running runners on your own hardware instead of their shared CPU. Literally from ~8m build time on Gradle + Docker down to mere 15s of Gradle + Docker on self hosted CPUs.
This! We went from 20!! minutes and 1.2k monthly spend on very, very brittle action runs to a full CI run in 4 minutes, always passing, by just by going to Hetzner's server auction page and bid on a 100 euro Ryzen machine.
After self hosting our builds ended up so fast, that we were actually waiting for was GitHub scheduling our agents, rather than it being the job running. It sucked a bit, because we'd optimized it so much, but we on 90th percentile saw that it took 20-30 seconds for github to schedule the jobs as they should. Measured from when the commit hit the branch, to the webhook begin sent.
My company uses GitHub, GitLab, and Jenkins. We'll soon™ be migrating off of GitLab in favor of GitHub because it's a Microsoft shop and we get some kind of discount on GitHub for spending so much other money with Microsoft.
Scheduling jobs, actually getting them running, is virtually instant with GitLab but it's slow AF for GitHub for no discernable reason.
lmao I just realized on this forum writing this way might sound like I own something. To be clear, I don't own shit. I typically write "my employer", and should have here.
I don't know, maybe it's a compliment. Wood glue can form bonds stronger than the material it's bonding. So, the wood glue in this case is better than the service it's holding together :)
I tend to just rely on the platform installers, then write my own process scripts to handle the work beyond the runners. Lets me exercise most of the process without having to (re)run the ci/cd processes over and over, which can be cumbersome, and a pain when they do break.
The only self-hosted runners I've used have been for internalized deployments separate from the build or (pre)test processes.
Aside: I've come to rely on Deno heavily for a lot of my scripting needs since it lets me reference repository modules directly and not require a build/install step head of time... just write TypeScript and run.
We choose github actions because it was tied directly to github providing the best pull-request experience etc. We actually didn't really use github actions templating as we'd got our own stuff for that, so the only thing github actions actually had to do was start, run a few light jobs as the CI was technically run elsewhere and then report the final status.
When you've got many 100s of services managing these in actions yaml itself is no bueno. As you mentioned having the option to actually be able to run the CI/CD yourself is a must. Having to wait 5 minutes plus many commits just to test an action drains you very fast.
Granted we did end up making the CI so fast (~ 1 minute with dependency cache, ~4 minutes without), that we saw devs running their setup less and less on their personal workstations for development. Except when github actions went down... ;) We used Jenkins self-hosted before and it was far more stable, but a pain to maintain and understand.
Am I right in assuming it’s not the amount of payment but the transition from $0 to paying a bill at all?
I’m definitely sure it’s saving me more than $140 a month to have CI/CD running and I’m also sure I’d never break even on the opportunity cost of having someone write or set one up internally if someone else’s works - and this is the key - just as well.
But investment in CI/CD is investing in future velocity. The hours invested are paid for by hours saved. So if the outcome is brittle and requires oversight that savings drops or disappears.
The only company I’ve held a grudge against longer than MS is McDonalds and they are sort of cut from the same cloth.
I’m also someone who paid for JetBrains when everyone still thought it wasn’t worth money to pay for a code editor. Though I guess that’s again now. And everyone is using an MS product instead.
I run a local Valhalla build cluster to power the https://sidecar.clutch.engineering routing engine. The cluster runs daily and takes a significant amount of wall-clock time to build the entire planet. That's about 50% of my CI time; the other 50% is presubmits + App Store builds for Sidecar + CANStudio / ELMCheck.
Using GitHub actions to coordinate the Valhalla builds was a nice-to-have, but this is a deal-breaker for my pull request workflows.
ZeroFS looks really good. I know a bit about this design space but hadn't run across ZeroFS yet. Do you do testing of the error recovery behavior (connectivity etc)?
This has been mostly manual testing for now.
ZeroFS currently lacks automatic fault injection and proper crash tests, and it’s an area I plan to focus on.
SlateDB, the lower layer, already does DST as well as fault injection though.
I found that implementing a local cache on the runners has been helpful. Ingress/egress on local network is hella slow, especially when each build has ~10-20GB of artifacts to manage.
They already charge for this separately (at least storage). Some compute cost may be justified but you'd wish that this change would come with some commitment of fixing bugs (many open for years) in their CI platform -- as opposed to investing all their resources in a (mostly inferior) LLM agent (copilot).
- github copilot PR reviews are subpar compared to what I've seen from other services: at least for our PRs they tend to be mostly an (expensive) grammar/spell-check
- given that it's github native you'd wish for a good integration with the platform but then when your org is behind a (github) IP whitelist things seem to break often
- network firewall for the agent doesn't seem to work properly
raised tickets for all these but given how well it works when it does, I might as well just migrate to another service
I don't work for Microsoft (in fact, I work for a competitor), and I think it's totally reasonable to charge for workflow executions. It's not like they're free to build, operate, and maintain.
The runner software they provide is solid and I’ve never had an issue with it after administering self-hosted GitHub actions runners for 4 years. 100s of thousands of runners have taken jobs, done the work, destroyed themselves, and been replaced with clean runners, all without a single issue with the runners themselves.
Workflows on the other hand, they have problems. The whole design is a bit silly
it's not the runners, it's the orchestration service that's the problem
been working to move all our workflows to self hosted, on demand ephemeral runners. was severely delayed to find out how slipshod the Actions Runner Service was, and had to redesign to handle out-of-order or plain missing webhook events. jobs would start running before a workflow_job event would be delivered
we've got it now that we can detect a GitHub Actions outage and let them know by opening a support ticket, before the status page updates
You don't trust devs to run things, to have git hooks installed, to have a clean environment, to not have uncommitted changes, to not have a diverging environment on their laptop.
Actions let you test things in multiple environments, to test them with credentials against resources devs don't have access to, to do additional things like deploys, managing version numbers, on and on
With CI, especially pull requests, you can leave longer running tests for github to take care of verifying. You can run periodic tests once a day like an hour long smoke test.
CI is guard rails against common failure modes which turn requiring everyone to follow an evolving script into something automatic nobody needs to think about much
> You don't trust devs to run things, to have git hooks installed, to have a clean environment, to not have uncommitted changes, to not have a diverging environment on their laptop.
... Is nobody in charge on the team?
Or is it not enough that devs adhere to a coding standard, work to APIs etc. but you expect them to follow a common process to get there (as opposed to what makes them individually most productive)?
> You can run periodic tests once a day like an hour long smoke test.
Which is great if you have multiple people expected to contribute on any given day. Quite a bit of development on GitHub, and in general, is not so... corporate.
I don't deny there are use cases for this sort of thing. But people on HN talking about "hosting things locally" seem to describe a culture utterly foreign to me. I don't, for example, use multiple computers throughout the house that I want to "sync". (I don't even use a smartphone.) I really feel strongly that most people in tech would be better served by questioning the existing complexity of their lives (and setups), than by questioning what they're missing out on.
For what it's worth, they already fail to update the status page. We had an "outage" just this morning where jobs were waiting 10+ minutes for an available runner -- resolved after half an hour or so but nothing was ever posted
I don't want to shit on the Code to Cloud team but they act a lot like an internal infrastructure team when they're a product team with paying customers
ZIRP ended, its remaining monopoly money has been burnt through, and the projected economy is looking bleak. We're now in the phase where everything that can be monetized is being monetized in every way that can be managed.
Free tiers evaporate. Fees appear everywhere. Ads appear everywhere, even where it was implied they wouldn't. The lemons must be squeezed.
And because everybody of relevance is in that mode, there's little competitive pressure to provide a specific rationale for a specific scheme. For the next few years, that's all the justification that there needs to be.
I thought that "Bitbucket" was in your original post and you added only your edit message to say that it was, in fact, Gitlab and not Bitbucket that added cost for self-hosted runners.
I initially felt a bit offended when I saw this. Then I thought about it and at the end of the day there's a decent amount of infrastructure that goes into displaying the build information, updating it, scanning for secrets and redacting, etc.
I don't know if it's worth the amount they are targeting, but it's definitely not zero either.
You would think the fat monthly per-seat license fee we also pay would be enough to cover the costs of checks notes reading some data from the DB and hosting JSON APIs and webpages.
Yeah, I think we’re seeing some fallout from how much developer infrastructure was built out during the era where VCs were subsidizing everything, similar to how a lot of younger people complained about delivery charges going up when they had to pay the full cost. Unfortunately, now a lot of the competition is gone so there isn’t much room to negotiate or try alternate pricing models.
Starting an external CI company for GitHub is becoming more interesting now.
Gitlab offers ability to do CI for external repositories. Travis CI was what everyone used before Github Actions. Time for a new Travis?
That's not a move of a company that thinks it can still grow. That's a Netflix "we have 90% of the market, let's squeeze them" move.
This is the beginning. We have all seen this pattern over the last 5+ years. You know their next few moves.
It actually kind of did for a lot of people. Streaming was cheap, available, and convenient.
Now it's none of those three. Once again, choosing not to pirate is just an objectively wrong choice. It's a worse experience, with worse quality, worse availability, and at a higher price tag.
> Choosing not to pirate is just an objectively wrong choice. It's a worse experience, with worse quality, worse availability, and at a higher price tag.
Choosing not to pirate and not to consume simultaneously is not necessarily a wrong choice. A difficult one? Yes. But I propose that it could be beneficial for your mental (and maybe physical) health.
> Perfectly good excuse to make society worse for people
What an incredibly silly accusation to make of a company/service that streams movies and television. Like you understand it is possible to dilute the concept of civic responsibility right?
Companies don't care about society, unless it affects profit. Companies are not people, they are cold machines that through different means try to reach the same purpose, make more money.
No one should anthropomorphize companies. They might look like they have human qualities, same way like the T800 in the Terminator looked human.
> Self-hosted runners: You will be charged for using the GitHub Actions cloud platform from March 1, 2026
The GitHub encrapification finally affects me. I am militantly unwilling to pay per minute to use my own computer. Time to leave. I can trigger and monitor builds myself thank you very much.
This is my first comment on HN despite being a user for over a decade -- this is one of the most outrageous pricing changes I've encountered - I couldn't believe it when I read the email earlier (I run self-hosted runners).
Anyone using GitLab or any other VCM that you'd recommend? I'm absolutely done with Github. Or is everything else just as bad?
We self host GitLab and it’s been amazing. Never down, all the features we need. And the CI is, at least for me, easier to understand than GH actions. You’re just running scripts in a container no weird abstractions.
I'm pretty happy with codeberg.org as a free host.
Alternatively, Forgejo, Gitea, or (based on praise I've seen from other people) maybe sourcehut.org.
I find GitLab's interface intolerable. Heavy reliance on javascript even for read-only access, nonintuitive organization, common operations hidden behind menus, mystifying icons... Every time I seek out a project's home and discover a GitLab instance, I find myself pausing to reconsider whether contributing to the project will really be rewarding enough to outweigh the unpleasant experience I'm about to have.
Gitlab interface is busy, yeah. But you it packs a lot of functionality in. If you want, you disable features like wiki and snippets to free up space on the side bar of a project. Or just look past it and find the part you want, issues merge requests, whatever.
After working for years with GitLab professionally, you know exactly where everything is.
Particularly making a contribution should anyhow be trivial - you push the branch and it shows a banner in the repo asking if you want to open a MR for the recently pushed branch.
I don't know why anyone would use GitHub actions. They seem like a weird, less powerful version of the GitLab CI. Now they want to charge for runtime on your own runner.
codeberg.org for open source, because it's a non-profit, with what it seems, very well intentioned people, with a good governance structure, and it's starting to support federation.
For a company, I'd recommend self-hosting forgejo (which also has actions), which powers codeberg.
Self-hosted gitlab here. Love it, and gitlab CI is excellent as well. Almost all product development revolves around some crappy AI integration that we don't use, and it worries me to see so much focus there instead of the core product, but the core product is still excellent.
And the best (maybe?) part in your case is that the CI is based on GH Actions, so you can probably reuse your workflows without the need to adapt them.
Sure, but there's a separate mechanism that you need to make it all work: the orchestration. Without that, you have only the capacity to run jobs -- it's potential energy, if you will, not doing real work.
That orchestrator thus provides real value. And it's not like it's free for them to build, operate, and maintain.
Yikes! They seem to be gunning for services like WarpBuild, which we've used for a couple years to keep our costs low. The $0.002 per minute on top of WarpBuild's costs is exactly GitHub's new pricing scheme.
I'm happy for competition, but this seems a bit foul since we users aren't getting anything tangible beyond the promise of improvements and investments that I don't need.
The lever that matters the most with the new $0.002/min tax is to reduce the number of minutes consumed.
Given that GitHub runners are still slow as ever, it actually is a point in our favor even compared to self-hosting on aws etc. However, it makes the value harder to communicate <shrug>.
What do you mean? This is for CI, whatever the dev machine runs is irrelevant. Either way, the CI uses OCI containers built with Nix, you don't need Nix installed on the host. Also Nix supports MacOS.
It is containers. It's based on Nixery, which is a virtual Docker registry where it puts together containers for you on the fly containing whatever packages you want from Nixpkgs.
The operate on less than 100_000€/year, so I would cut them some slack ;-)
btw. codeberg is not a company, more like a foundation, Verein is the german word.
I fail to see how this is relevant to the point I was making. With uptime being so low, it's not a viable alternative: budget / resources / etc. don't change that fact.
Don't get me wrong — I am glad that they are doing what they're doing, but it's a long way until it becomes a real alternative.
I'm sure if Codeberg had equivalent resources they'd be good, hard to fault a nonprofit for not benefiting from a trillion dollar multinational corporation. What was GitHub's excuse for their failures?
I’m genuinely excited about this. The GitHub actions platform is genuinely bad compared to circle or Travis but they’ve been totally crowded out because GitHub was just so easy to use. This has led to plenty of security issues and a general lack of innovation in the ci space. Hopefully by this pricing structure change we’ll see more investment in ci tooling across the industry
This. There are plenty of good/better CICD solutions out there, but it's tricky to compete with "comes for free with our VCS". I guess it's clear now there is no such thing as a free lunch. I feel it's a good thing for the "CICD industry" that people will be looking around to alternatives, and do a honest Total Cost of Ownership analysis.
I had the same question — I understand that the Actions control plane has costs on self-hosted runners that GitHub would like to recoup, but those costs are fixed per-job. Charging by the minute for the user’s own resources gives the impression that GitHub is actually trying to disincentivize third-party runners.
Self-hosted runner regularly communicates with the control plane, and control plane also needs to keep track of job status, logs, job summaries, etc.
8h job is definitely more expensive to them than a 1 minute one, but I'd guess that the actual reason is that this way they earn more money, and dissuade users from using a third party service instead of their own runners.
That's generous, but doesn't seem consistent with how Microsoft does business. Also, if that's the case why does self-hosted cost the same as the lowest hosted tier?
The $0.002 per-minute for self-hosted runners will definitely change the unit economics for a lot of 3rd party runner providers.
I'm sure we'll feel it too at https://sprinters.sh, but probably a bit less than others as our flat $0.01 per job fee for runners on your own AWS account will still work out to about 80% average savings in practice, compared to ~90% now when using spot instances.
I use GitHub Actions for only one thing, which is to automatically assign any issues to myself (by using the "gh" program), and I am not paying anything for it. Furthermore, the repositories that use this are all public (I do not have any private repositories on GitHub, and due to various things I will not do that).
As far as I can tell from that article, these changes will not affect me; it says "Standard GitHub-hosted or self-hosted runner usage on public repositories will remain free" and another section says "This will not impact Actions usage in public repositories". Hopefully, this information would behelpful for other people who use GitHub Actions. However, I don't know if I missed something else that is important, from the article.
This sounds correct, there are no changes for public repositories.
For private repositories, each GitHub account gets 2000 free minutes of runtime per month. Both self-hosted runners and GitHub-hosted runners count against that quota.
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 is still cheaper than not
Despite the $0.002/minute self-hosted runner tax, self-hosting runners on your cloud (aws/gcp/azure/...) 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.
Note: I make WarpBuild, where we provide github actions runner compute. Our compute is still cheaper than using github hosted runners (even with the $0.002/min tax) and our runners are optimized for high performance to minimize the number of mins consumed.
I'm generally biased, but I think the points 1-6 apply irrespective of WarpBuild.
To spell it out: jobs can hang forever because of some ridiculously bad code on their end, they have a 6 hour cap, so that's 6 hours of billable $$$ per-instance of the bug (assuming it wasn't manually canceled). I know I've seen jobs hang forever regularly over the course of my years using GitHub for work.
Earlier this year I priced out AWS's on-demand m7i.large instances at $0.002/minute [1]. GitHub's two-core costs $0.008/minute today so it was a nice savings. But it looks like this announcement doubles the self-hosted cost and reduces their two-core system pricing to $0.006/min.
From this perspective this is a huge price jump, but self-hosting to save money can still work out.
Honestly, GitHub Actions have been too flaky for me and I'm begrudgingly reaching for Jenkins again for new projects.
Could this change mainly be about competition with their own hosted runners?
Today it's possible to spin up a company that sells GitHub Actions runners with a lower price and higher performance than GitHub's own hosted runners. These new fees will make that a lot less economically viable.
1. Services like WarpBuild (I'm the founder) are still cheaper than GitHub hosted runners, even after including the $0.002/min self-hosting tax.
2. The biggest lever for controlling costs now is reducing the number of minutes used in CI. Given how slow Github's runners are, or even the ones on AWS compared to our baremetal processor single core performance + nvme disks, it makes even more sense to use WarpBuild. This actually makes a better case for moving from slow AWS instances running with actions-runner-controller etc. to WarpBuild!
3. Messaging this to most users is harder since the first reaction is that Github options make more sense. After some rational thought, it is the opposite.
Are there any good CI systems to begin with? joking, but not really
Jenkins has been rock solid, we are trying to migrate to Argo Workflows/Events, but there are a complaints (like deploying argo workflows with helm, such fun!)
I've been using dagger.io and it's been really nice to work with.
- runs locally
- has a language server: python, typescript, go, java, OR elixer
- has static typing
- the new caching mechanisms introduced in 0.19.4 are chef's kiss
I do not work for dagger and pay for it using the company credit card. A breath of fresh air after the unceasing misery and pain that is Gitlab and GHA.
Pay even more to bring your own hardware? Well, that's new.
I get that self-hosted runners generate huge egress traffic, but this is still wild. Hope it pushes more companies to look into self-hosted Gitea / Forgejo / etc.
The email I received from them this morning claims that this will be cheaper for 96% of users...
I have cron jobs on several github projects that runs once a day and I have never been charged anything for it (other than my github membership). Should I expect to be charged for this?
I would think that majority of users does not use GitHub actions at all or have very light infrequent usage so that would be true. I think with my personal project I have never exceeded the resources they give me as part of personal pro subscription.
Curious: Can you expand a little bit on your usage? $700/month equates to 350,000 minutes. Are you just running a truck-load of different Actions, or are the Actions themselves long-lived (waiting on something to complete)?
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.
Part of this is fair since there is a cost to operating the control plane.
One way around this is to go back to using check runs. I imagine a third party could handle webhooks, parse the .github/workflows/example.yml, then execute the action via https://github.com/nektos/act (or similar), then post the result.
That makes me genuinely curious about the internal hosted vs. self-hosted usage ratio they're seeing. I'd have guessed the bulk of the cost/volume was on hosted, but clearly that can't be the case
Anecdotally I've seen it get a lot more common to use third-party managed runners (e.g. Blacksmith) for anyone that needs slightly beefier machines and/or a caching system that actually works.
They are not just more expensive, they are also slower. Last time I compared them, AWS ARM64 instances could easily run jobs 30% faster, for the same CPU/memory count, than those that GitHub offers.
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.
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.
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.
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.
PLEASE stop propping up the narrative that the GitHub Actions control plane was previously free. It never was. Pricing is not that simple. I see way too many people in this thread, and even GitHub Actions competitors promoting this nonsensical narrative.
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!
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?
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.
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.
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.
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.)
> Standard GitHub-hosted or self-hosted runner usage on public repositories will remain free. GitHub Enterprise Server pricing is not impacted by this change.
Per-minute pricing for self-hosted runners seems like a very fast way for them to force everyone who actually is using self-hosted runners to migrate away.
I suspect we'll be doing that sometime in January or February.
Ahh, so since GitHub is completely incompetent when it comes to managing a CI they are going to make it worse for everyone to get their cut.
I hate GH Action runners with a passion. They are slow, overpriced, and clearly held together with duct tape and chewing gum. WarpBuild, on the other hand, was a breeze to setup and provided faster runners and lower prices.
I have never been a fan of GitHub and their entire system, always felt Bitbucket or GitLab were superior in terms of the tooling and included features across all plans.
However, my experience with GitHub Actions was really poor. Some build that would run perfectly on my local machine and any other servers we have hosted would always time out on GitHub runners. I went back and forth from small runners to large runners and the result was always the same. Then I found that there are third-party companies just offering replacement runners for GitHub Actions at less than half the price for an amazing reliability and cost. It was a night and day difference.
Now... this move by GitHub is almost unbelievable. Charging folks to use their own machines
Given github ran 11.5 billion mins of actions in 2025, and most of them would've been on self-hosted runners, this move makes some sense from their POV.
However, this is still an... interesting... move, especially after bitbucket got all that hate a few weeks ago for doing something similar.
We all knew this would happen. For open source projects one step local build and test is superior to full automation for this reason. It lasts forever whereas these automated server configs require ongoing maintenance.
I've been running self hosted runners for my company using Actions Runner Controller (ARC) on my own kubernetes infrastructure. Could never really get the devs invested in GitOps style dev cycles so I may just chuck actions and use a more nightly or on demand style build server since that seems to be what they desire and expect. I always expected this day to come so my actions use very little github/actions specific stuff, mainly they just kick off scripts already. I do wonder how hard it would be to create my own github API pollers etc but not sure I want to invest any further in anything github specific. Good news is the effective date is March and the initial prices for my usage will probably be very low but I fully expect them to push further price increases / monetization / lock-in.
Hmm... News about massive RAM price hikes. Then GitHub decides to charge for per-minute. Do they keep a lot of stuff in RAM while a workflow is running?
It's worse than unrealistic. It's ludicrous. Any company running more than an hour of actions workflows per week on GitHub can afford a few dollars a month for infrastructure. The per-minute charge is less than the cost of a millisecond of engineering labor time.
Dude why are you so determined to defend this pricing change? You're all over this thread arguing with people that it's not a big deal. If it's a big deal to them, why do you give a shit? It's not like it's your problem if people take their business elsewhere for a poor reason.
Possibly a good time to remind people that the default value of jobs.<job_id>.timeout-minutes is 360 (minutes), meaning that your hanging job will cost $0.72 before it times out.
Isn't it like way more expensive and restricted? They were very competitive in the early days, but currently they are more capped than anything else it seems. Especially for self hosting..
Ok, they have changed their pricing. Currently they are capping the number of concurrent agents. At one point, they introduced minutes cap and that was very big step down.
That's just the point. Selfhosted runners were the alternative. The only alternative for "runners" is Github-hosted, 200%-markup runners.
Now the only alternative is to move builds, CI, etc. off of GitHub's platform entirely, and maybe your source control as well. In other words, a big pain. Github seems to have entered peak encrapification: the point where they openly acknowledge rent-seeking as their product approach, fully deprecating "building the best, most reliable, trustworthy product." Now it's just "Pay us high margins because the effort to migrate off is big and will take too long to break even."
Genuinely curious about this as well. It's a major bummer that self-hosted infra can't be used to validate GitHub Pull Requests now; basically means I'll have to move my entire workflow off of GitHub so that everything can be integrated reasonably again.
That's not exactly true. You just won't be able to use self-hosted infra to validate GitHub PRs a) using GHA and b) for free.
GitHub still supports e.g. PR checks that originate from other systems. We had PR checks before GHA and it's easy enough to go back to that. Jenkins has some stuff built in or you can make some simple API calls.
Gitea + Gitea Actions works approximately as well as GHA. For GitHub specifically, you're back to setting PR checks + commit status programmatically through the API.
Love how they drop this news right before everyone goes away for the xmas holidays and it kicks in right as you come back. Or before you come back if you live outside the US.
Founder of Depot[0] here. I'm disappointed by this change and by the impact this is going to have on all self-hosted runner customers, not just us. In my view, this is GitHub extracting more revenue from the ecosystem for a service that is slow, unreliable, and that GitHub has openly not invested in.
We will continue to do our best to provide the fastest GHA runners and keep them cheaper than GitHub-hosted runners.
I have a love-hate relationship with GitHub Actions. Love because they are right there in my GitHub repository. Hate because they are very brittle once you move out of the happy path.
It seems GitLab has a much better experience in this department, but their pricing is hard to justify for us...
Genuinely curious if folks here had better experiences or recommendations for a smooth CI/CD experience.
Love-hate for me as well. Love that there is native github integration for triggering events and other github bits. Hate the brittleness and anymore the reliability even if you are just using the control plane. I've always sought to keep my actions as mainly just calling existing scripts, that is keep logic out of them and make them relatively dumb wrappers but it would still be some effort to get off it.
I read this and I'm thinking I should just get Claude to write me my own GitHub (with blackjack! and... nevermind)
I'm in the era of writing my own tools, not to share just for me or whatever group I'm working in. If you're going to charge me for something rife with annoying struggles, I might as well be annoyed by a tool I control.
I was worried about this, but $10/mo for 5000 self-hosted minutes isn't terrible, the self-hosted runner feature is great for our use cases where the repo is too big to run in the cloud generally and/or ingress/egress is too expensive.
Why are there no changes for plans with included minutes e.g. enterprise that has 50000 since the runners are now cheaper? So now the included tier has effectively been reduced.
how long before they start skimming OSS projects that are public but nonetheless have Github Sponsors income. I mean that's money right there for them right
Everyone in this thread has gone absolutely insane. $5/month gets you 41 fucking _hours_ of continuous operation. If you're not utterly abusing the platform, this falls extremely below the threshold of caring. And if not, what the fuck are you even doing with all those hours? The new per-minute charge is less than one millisecond of engineer labor cost.
I have a nightly software build of a piece of software that takes 6 hours to create a 70GB artifact. The build process requires a GPU so it runs on my own HW. That's ~180 hours per month for this job alone. Is that really so hard to imagine?
I don't know how much of that 6 hours build is tangled up in github workflows, but if it's a single contiguous block, you probably could make it near zero by making the self-hosted runner do only the preparation and only the final upload process (workflow_dispatch when the build is complete).
Most of it is just time waiting either while the source assets are downloaded (I clean slate it, that's the point of CI after all), the build itself runs, or the artifact is uploading to it's storage home. I'm sure it could be re-architected to use less actions minutes but if I'm going to redo it I will probably just move away from actions altogether because it's only loosely linked to Github anyway (runs on a schedule) and that way I am insulated from any future changes they come up with. The hardest part will likely be figuring out the Slack bot posting, I do use the marketplace action for that, but that's probably low lift. With LLM assisted coding I'm leaning more and more to little in house apps for stuff like this, it keeps you from dealing with lock in and other extractive gotchas.
I think you significantly underestimate the number of CI minutes people are using in practice.
(Which, yes, has implications for energy use/climate change too for sure).
It doesn't look like i currently have access to the usage data on any of the lots-of-runners-lots-of-PRs projects I currently work on (which are still probably way less than some large companies).
Any "large companies" don't give a shit about things at this cost level. They spend more on the time it takes you to open the door. The number of CI minutes could be astronomical and it still wouldn't rate above the threshold of caring. The time people in this thread have spent wringing their hands is way more expensive.
per minute billing is hard to wrap around the head
On my larger organization, we have on average 20 to 30 *active* runners during business hours. Assuming 5 on the off-hours, my napkin math says it comes down to about 10 fully-utilized-runners per month, so about 864$/mo. For the size of my organization that is honestly totally acceptable.
This is assuming 0.002$ per minute of job being actively executed. If it turns out to be 0.002$ per minute of *runner being registered* on the control plane, it would increase quite a bit. We are still using the old HorizontalRunnerAutoscaler with actions-runner-controller, with quite a pool of prewarmed runners idling to pick up a job. It would be a strong reason to use the new RunnerScaleSet (to take advantage of the reactive webhook-based scaling) and keep a very lean pool of prewarmed runners.
Well, you obviously are using their resources, to kick off and register statuses of the jobs running on your resources, right? That is probably worth $1/month to you?
Doesn't this depend a lot on how long your actions run? Like, you may have already invested in your own hardware (maybe because your actions use a lot of resources and it's cheaper) and now you have to pay per-minute of action runtime for the API that does the bookkeeping?
I got contacted by our rep a couple weeks ago, who informed me of this news. I thought it was a disaster and it really pissed me off. The rep couldn't even explain the reasoning well. It basically summed up to "because we can" and "where are you going to go?". He was shocked to find out that I didn't like it.
We currently self-host on kubernets/aws. The thing that really got to me isn't the new charge per se. It's the fact that GHA has a ton of problems. I can hold my nose and deal with them when it's free. But now that you're squeezing me, at least you could have created something like GHA 2.0 and added a charge for that. Instead, there are vague roadmap promises which don't even include things that I care about. Specifically:
- Jenkins had better kubernetes integration years ago. It's crazy that GHA can't beat that.
- "Reintroducing multi-label functionality" - yeah, so they first broke it. They did supply "reasons", which looked like they never talked to a customer. [1]
- Still no SDK of any kind.
- "Actions Data Stream" - or you can just fix your logging.
There are dozens more complains, which are easy enough to find. This kind of an approach just makes me want to make sure that I don't use GHA again. Even if I end up paying another vendor, at least I'll be treated as a customer.
[1] - https://github.com/orgs/community/discussions/160682#discuss...
Any official Github action today:
"Thank you for your interest in this GitHub action, however, right now we are not taking contributions.
We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time. The GitHub public roadmap is the best place to follow along for any updates on features we’re working on and what stage they’re in."
Reference: https://github.com/actions/runner?tab=readme-ov-file#note
This kinda change also has some different gears turning in my head. At $0.002 / build-minute, some of our large software integration tests would cost us around 15 - 20 cents. Some of our ansible integration tests would be 5 - 10 cents - and we run like 50 - 100 of those per day. Some deployments might cost us a cent or two.
Apples to oranges, naturally, but like this, our infra-jenkins master would pay for itself in hosting in a week of ansible integration testing compared to what GHA would cost. Sure, maintenance is a thing, but honestly, flinging java, docker and a few other things onto a build agent isn't the time-consuming part of maintaining CI infrastructure.
And I mean sure, everything is kinda janky on Jenkins, but everything falls into an expectable corridor of jank you get used to.
> Sure, maintenance is a thing, but honestly, flinging java, docker and a few other things onto a build agent isn't the time-consuming part of maintaining CI infrastructure.
Depending on your workplace, there's a whole extra layer of bureaucracy and compliance involved if you self-host things. I aggressively avoid managing any VMs for that reason alone.
Luckily, at work we are this layer of bureaucracy and compliance. I'm very much pushing the agenda and idea that managing a stateful, mutable linux VM is a complex skill on it's own and incurs toil that's both recurring and hard to automate. The best case to handle that is to place your use case into our config management and let us manage it.
Most modern development workflows should just pickup a host with some container engine and do their work in stateless containers with some external state mapped in, like package caches. It's much easier for both sides in a majority of cases.
Last place I worked had long running end to end tests that would take 30 minutes on GHA (compared to maybe 5 locally) on every PR. This is going to make that a very expensive endeavour
> And I mean sure, everything is kinda janky on Jenkins, but everything falls into an expectable corridor of jank you get used to.
Self-hosting Jenkins on an EC2 instance is probably going to result in a _better_ experience at this point. Github Cache is barely better than just downloading assets directly, and with Jenkins you can trivially use a local disk for caching.
Or if you're feeling fancy and want more isolation, host a local RustFS installation and use S3 caching in your favorite tools.
GitHub Actions runners are hard to self-host.
The runner configuration and registration process is unnecessarily byzantine. [1]
They can't cancel jobs cleanly. [2]
There are consistency problems everywhere. [3]
Their own documentations describes horrible things unless you use runners in JIT mode. Though JIT runners are not always removed after exit.
If there is a worse self-hosted CI runner, I haven't yet met it.
[1] https://docs.github.com/en/actions/how-tos/manage-runners/se...
[2] https://github.com/orgs/community/discussions/26311
[3] https://github.com/orgs/community/discussions/62365
And if you want any concurrency at all, you need 1 runner registration per concurrent job. And each runner needs its own user. And each runner requires a full and separate copy of the runner software, which is large (hundreds of megs) and self-updates.
You don't need your own user.
The rest is correct. (Though you can hardlink the installation.) And you can disable self-update, though it does it by default.
I am developing a self-hosted solution for this [1]. It’s true that it’s somewhat of a pain but JIT runners allow a lot of flexibility that we don’t find elsewhere.
[1] https://runs-on.com
Introducing a separate charge specifically targeting those of your customers who choose to self-host your hilariously fragile infrastructure is certainly a choice.. And one I assume is in no way tied to adoption/usage-based KPIs.
Of course, if you can just fence in your competition and charge admission, it'd be silly to invest time in building a superior product.
We've self-hosted github actions in the past, and self-hosting it doesn't help all that much with the fragile part. For github it is just as much triggering the actions as it is running them. ;) I hope the product gets some investment, because it has been unstable for such a long time, that on the inside it must be just the usual right now. GitHub has by far the worst uptime of any SaaS tools we use at the moment, and it isn't even close.
> Actions is down again, call Brent so he can fix it again...
We self host the runners in our infrastructure and the builds are over 10x faster than relying on their cloud runners. It's crazy the performance you get from running runners on your own hardware instead of their shared CPU. Literally from ~8m build time on Gradle + Docker down to mere 15s of Gradle + Docker on self hosted CPUs.
This! We went from 20!! minutes and 1.2k monthly spend on very, very brittle action runs to a full CI run in 4 minutes, always passing, by just by going to Hetzner's server auction page and bid on a 100 euro Ryzen machine.
After self hosting our builds ended up so fast, that we were actually waiting for was GitHub scheduling our agents, rather than it being the job running. It sucked a bit, because we'd optimized it so much, but we on 90th percentile saw that it took 20-30 seconds for github to schedule the jobs as they should. Measured from when the commit hit the branch, to the webhook begin sent.
My company uses GitHub, GitLab, and Jenkins. We'll soon™ be migrating off of GitLab in favor of GitHub because it's a Microsoft shop and we get some kind of discount on GitHub for spending so much other money with Microsoft.
Scheduling jobs, actually getting them running, is virtually instant with GitLab but it's slow AF for GitHub for no discernable reason.
lmao I just realized on this forum writing this way might sound like I own something. To be clear, I don't own shit. I typically write "my employer", and should have here.
> call Brent so he can fix it again
Not sure if a Phoenix Project reference, but if it is, it's certainly in keeping with Github being as fragile as the company in the book!
It is xD On the outside it feels like a product held together with duct tape, wood glue and prayers.
Hey, don't insult wood glue like that.
or prayers
Indeed, wood glue is amazing. Such slander is totally uncalled for.
I don't know, maybe it's a compliment. Wood glue can form bonds stronger than the material it's bonding. So, the wood glue in this case is better than the service it's holding together :)
I tend to just rely on the platform installers, then write my own process scripts to handle the work beyond the runners. Lets me exercise most of the process without having to (re)run the ci/cd processes over and over, which can be cumbersome, and a pain when they do break.
The only self-hosted runners I've used have been for internalized deployments separate from the build or (pre)test processes.
Aside: I've come to rely on Deno heavily for a lot of my scripting needs since it lets me reference repository modules directly and not require a build/install step head of time... just write TypeScript and run.
We choose github actions because it was tied directly to github providing the best pull-request experience etc. We actually didn't really use github actions templating as we'd got our own stuff for that, so the only thing github actions actually had to do was start, run a few light jobs as the CI was technically run elsewhere and then report the final status.
When you've got many 100s of services managing these in actions yaml itself is no bueno. As you mentioned having the option to actually be able to run the CI/CD yourself is a must. Having to wait 5 minutes plus many commits just to test an action drains you very fast.
Granted we did end up making the CI so fast (~ 1 minute with dependency cache, ~4 minutes without), that we saw devs running their setup less and less on their personal workstations for development. Except when github actions went down... ;) We used Jenkins self-hosted before and it was far more stable, but a pain to maintain and understand.
This is absolutely bananas; for my own CI workflow I'll have to pay $140+/month now just to run my own hardware.
Am I right in assuming it’s not the amount of payment but the transition from $0 to paying a bill at all?
I’m definitely sure it’s saving me more than $140 a month to have CI/CD running and I’m also sure I’d never break even on the opportunity cost of having someone write or set one up internally if someone else’s works - and this is the key - just as well.
But investment in CI/CD is investing in future velocity. The hours invested are paid for by hours saved. So if the outcome is brittle and requires oversight that savings drops or disappears.
Have you ever set up GitHub Actions? The outcome is brittle because of their platform, not because of my inability to do CI.
You're sounding a lot like a Microsoft damage control artist.
The only company I’ve held a grudge against longer than MS is McDonalds and they are sort of cut from the same cloth.
I’m also someone who paid for JetBrains when everyone still thought it wasn’t worth money to pay for a code editor. Though I guess that’s again now. And everyone is using an MS product instead.
Keep this kind of comment on reddit, not here.
This is not investment in CI/CD. I already did that, by buying and investing in my own hardware, my own workflows, my own caching solution.
This is like if Dropbox started charging you money for the files you have stored on your backup hard drives.
I'm curious, what are you doing that has over 1000 hours a month of action runtime?
I run a local Valhalla build cluster to power the https://sidecar.clutch.engineering routing engine. The cluster runs daily and takes a significant amount of wall-clock time to build the entire planet. That's about 50% of my CI time; the other 50% is presubmits + App Store builds for Sidecar + CANStudio / ELMCheck.
Using GitHub actions to coordinate the Valhalla builds was a nice-to-have, but this is a deal-breaker for my pull request workflows.
Cool, that looks a lot nicer than the OBD scanner app I've been using.
On ZeroFS [0] I am doing around 80 000 minutes a month.
A lot of it is wasted in build time though, due to a lack of appropriate caching facilities with GitHub actions.
[0] https://github.com/Barre/ZeroFS/tree/main/.github/workflows
ZeroFS looks really good. I know a bit about this design space but hadn't run across ZeroFS yet. Do you do testing of the error recovery behavior (connectivity etc)?
This has been mostly manual testing for now. ZeroFS currently lacks automatic fault injection and proper crash tests, and it’s an area I plan to focus on.
SlateDB, the lower layer, already does DST as well as fault injection though.
I found that implementing a local cache on the runners has been helpful. Ingress/egress on local network is hella slow, especially when each build has ~10-20GB of artifacts to manage.
What do you use for the local cache?
Just wrote about my approach yesterday: https://jeffverkoeyen.com/blog/2025/12/15/SlotWarmedCaching/
tl;dr uses a local slot-based cache that is pre-warmed after every merge to main, taking Sidecar builds from ~10-15 minutes to <60 seconds.
Wow, that's a very cool project.
Thank you!
1 hour build/test time, 20 devs, that's 50 runs a month. Totally possible.
I resorted to a local forgejo + woodpecker-ci. Every time I am forced back to GitHub for some reason it confirms I made the right choice.
In my experience gitlab always felt clunky and overly complicated on the back end, but for my needs local forgejo is better than the cloud options.
They still host all artefacts and logs for these self-hosted runs. Probably costs them a fair bit
They already charge for this separately (at least storage). Some compute cost may be justified but you'd wish that this change would come with some commitment of fixing bugs (many open for years) in their CI platform -- as opposed to investing all their resources in a (mostly inferior) LLM agent (copilot).
Copilot uses other models, not (necessarily?) its own, so I’m not sure what you mean.
It does leverage various models, but
- github copilot PR reviews are subpar compared to what I've seen from other services: at least for our PRs they tend to be mostly an (expensive) grammar/spell-check
- given that it's github native you'd wish for a good integration with the platform but then when your org is behind a (github) IP whitelist things seem to break often
- network firewall for the agent doesn't seem to work properly
raised tickets for all these but given how well it works when it does, I might as well just migrate to another service
There's absolutely no way that the cost scales with the usage of my own hardware. I cannot fathom this change in any way or form. Livid.
Sounds like the position a Microsoft damage control artist would take. Someone in a Reddit discussion on this topic made the same comment.
I don't work for Microsoft (in fact, I work for a competitor), and I think it's totally reasonable to charge for workflow executions. It's not like they're free to build, operate, and maintain.
Runners aren’t fragile, workflows are.
The runner software they provide is solid and I’ve never had an issue with it after administering self-hosted GitHub actions runners for 4 years. 100s of thousands of runners have taken jobs, done the work, destroyed themselves, and been replaced with clean runners, all without a single issue with the runners themselves.
Workflows on the other hand, they have problems. The whole design is a bit silly
it's not the runners, it's the orchestration service that's the problem
been working to move all our workflows to self hosted, on demand ephemeral runners. was severely delayed to find out how slipshod the Actions Runner Service was, and had to redesign to handle out-of-order or plain missing webhook events. jobs would start running before a workflow_job event would be delivered
we've got it now that we can detect a GitHub Actions outage and let them know by opening a support ticket, before the status page updates
Meanwhile I'm just running `pytest`, `pyproject-build`, `twine` etc. at the command line....
(People seem to object to this comment. I genuinely do not understand why.)
It passes on my machine. YOLO!
You don't trust devs to run things, to have git hooks installed, to have a clean environment, to not have uncommitted changes, to not have a diverging environment on their laptop.
Actions let you test things in multiple environments, to test them with credentials against resources devs don't have access to, to do additional things like deploys, managing version numbers, on and on
With CI, especially pull requests, you can leave longer running tests for github to take care of verifying. You can run periodic tests once a day like an hour long smoke test.
CI is guard rails against common failure modes which turn requiring everyone to follow an evolving script into something automatic nobody needs to think about much
> You don't trust devs to run things, to have git hooks installed, to have a clean environment, to not have uncommitted changes, to not have a diverging environment on their laptop.
... Is nobody in charge on the team?
Or is it not enough that devs adhere to a coding standard, work to APIs etc. but you expect them to follow a common process to get there (as opposed to what makes them individually most productive)?
> You can run periodic tests once a day like an hour long smoke test.
Which is great if you have multiple people expected to contribute on any given day. Quite a bit of development on GitHub, and in general, is not so... corporate.
I don't deny there are use cases for this sort of thing. But people on HN talking about "hosting things locally" seem to describe a culture utterly foreign to me. I don't, for example, use multiple computers throughout the house that I want to "sync". (I don't even use a smartphone.) I really feel strongly that most people in tech would be better served by questioning the existing complexity of their lives (and setups), than by questioning what they're missing out on.
I think you could learn a lot about the other use cases if you asked some genuine questions and listened with intent
Because you appear completely oblivious and deliberately naive about the entire purpose of CI.
Based on my experience I really do think most people are using it for things that they could perfectly well do locally with far less complication.
Perhaps that isn't most use of it; the big projects are really big.
Care to provide examples?
Fundamentally, yes, what you run in a CI pipeline can run locally.
That's doesn't mean it should.
Because if we follow this line of thought, then datacenters are useless. Most people could perfectly host their services locally.
> Because if we follow this line of thought, then datacenters are useless. Most people could perfectly host their services locally.
There are a rather lot of people who do argue that? Like, I actually agree that non-local CI is useful, but this is a poor argument for it.
I'm aware of people arguing for self-hosting some services for personal use.
I'm not aware of people arguing for self-hosting team or enterprise services.
> We are introducing a $0.002 per-minute Actions cloud platform charge for all Actions workflows across GitHub-hosted and self-hosted runners.
Charging for self-hosted runners is an interesting choice. That's the same cost as their smallest hosted runners [1]
[1] - https://docs.github.com/en/billing/reference/actions-runner-...
Pushing you towards their hosted runners which will show up in their Azure usage numbers and drive the stock price
Ah yes, vertical integration and oligopoly.
Really Dianne?
it'd be great if they can couple this with an SLA for GitHub actions so we won't have to end up paying as much..
(ofc, that'd only mean they stop updating the status page, so eh)
For what it's worth, they already fail to update the status page. We had an "outage" just this morning where jobs were waiting 10+ minutes for an available runner -- resolved after half an hour or so but nothing was ever posted
https://downdetector.com/status/github/
I don't want to shit on the Code to Cloud team but they act a lot like an internal infrastructure team when they're a product team with paying customers
Yep - Bitbucket made a similar move recently and I guess they are just following along. I'd love to get the justification of that fee tho…
Edit: Confused GitLab and Bitbucket
> justification of that fee
ZIRP ended, its remaining monopoly money has been burnt through, and the projected economy is looking bleak. We're now in the phase where everything that can be monetized is being monetized in every way that can be managed.
Free tiers evaporate. Fees appear everywhere. Ads appear everywhere, even where it was implied they wouldn't. The lemons must be squeezed.
And because everybody of relevance is in that mode, there's little competitive pressure to provide a specific rationale for a specific scheme. For the next few years, that's all the justification that there needs to be.
Your edit made your post confusing for us now...
I thought that "Bitbucket" was in your original post and you added only your edit message to say that it was, in fact, Gitlab and not Bitbucket that added cost for self-hosted runners.
I initially felt a bit offended when I saw this. Then I thought about it and at the end of the day there's a decent amount of infrastructure that goes into displaying the build information, updating it, scanning for secrets and redacting, etc.
I don't know if it's worth the amount they are targeting, but it's definitely not zero either.
You would think the fat monthly per-seat license fee we also pay would be enough to cover the costs of checks notes reading some data from the DB and hosting JSON APIs and webpages.
Yeah, I think we’re seeing some fallout from how much developer infrastructure was built out during the era where VCs were subsidizing everything, similar to how a lot of younger people complained about delivery charges going up when they had to pay the full cost. Unfortunately, now a lot of the competition is gone so there isn’t much room to negotiate or try alternate pricing models.
Does it make sense to accept charge per minute when you are hosting yourself? When GHA is not very good?
That's a surprise, do you have a link to their announcement?
Nope because I confused Bitbucket with GitLab. My bad. BitBuckets announcement can be found here: https://news.ycombinator.com/item?id=46165180
Thanks for clarifying it! I left bitbucket many years ago when they changed their UI to a new style that was awful to use...
It's because there are easy-to-use third party runners that cost around 3-10x less than the GitHub ones. This is aimed squarely at them.
https://github.com/neysofu/awesome-github-actions-runners
Starting an external CI company for GitHub is becoming more interesting now. Gitlab offers ability to do CI for external repositories. Travis CI was what everyone used before Github Actions. Time for a new Travis?
That's not a move of a company that thinks it can still grow. That's a Netflix "we have 90% of the market, let's squeeze them" move. This is the beginning. We have all seen this pattern over the last 5+ years. You know their next few moves.
The Netflix one worked
Worked for them not for the consumers
short-term maybe, but piracy is making a come back
It never left
It actually kind of did for a lot of people. Streaming was cheap, available, and convenient.
Now it's none of those three. Once again, choosing not to pirate is just an objectively wrong choice. It's a worse experience, with worse quality, worse availability, and at a higher price tag.
> Choosing not to pirate is just an objectively wrong choice. It's a worse experience, with worse quality, worse availability, and at a higher price tag.
Choosing not to pirate and not to consume simultaneously is not necessarily a wrong choice. A difficult one? Yes. But I propose that it could be beneficial for your mental (and maybe physical) health.
Netflix is looking out for Netflix shareholders, not for consumers, like any other public company.
Perfectly good excuse to make society worse for people. Oh wait, what's that? It's not a good excuse? Oh okay.
Nobody needs a Netflix subscription. You can just stop paying
> Perfectly good excuse to make society worse for people
What an incredibly silly accusation to make of a company/service that streams movies and television. Like you understand it is possible to dilute the concept of civic responsibility right?
?
Companies don't care about society, unless it affects profit. Companies are not people, they are cold machines that through different means try to reach the same purpose, make more money.
No one should anthropomorphize companies. They might look like they have human qualities, same way like the T800 in the Terminator looked human.
It worked to push me to unsubscribe.
> Self-hosted runners: You will be charged for using the GitHub Actions cloud platform from March 1, 2026
The GitHub encrapification finally affects me. I am militantly unwilling to pay per minute to use my own computer. Time to leave. I can trigger and monitor builds myself thank you very much.
I migrated to forgejo a few years ago and never looked back. While there are some edge cases and known issues. All of my actions "just worked".
This is my first comment on HN despite being a user for over a decade -- this is one of the most outrageous pricing changes I've encountered - I couldn't believe it when I read the email earlier (I run self-hosted runners).
Anyone using GitLab or any other VCM that you'd recommend? I'm absolutely done with Github. Or is everything else just as bad?
We self host GitLab and it’s been amazing. Never down, all the features we need. And the CI is, at least for me, easier to understand than GH actions. You’re just running scripts in a container no weird abstractions.
I'm pretty happy with codeberg.org as a free host.
Alternatively, Forgejo, Gitea, or (based on praise I've seen from other people) maybe sourcehut.org.
I find GitLab's interface intolerable. Heavy reliance on javascript even for read-only access, nonintuitive organization, common operations hidden behind menus, mystifying icons... Every time I seek out a project's home and discover a GitLab instance, I find myself pausing to reconsider whether contributing to the project will really be rewarding enough to outweigh the unpleasant experience I'm about to have.
What does VCM stand for?
Gitlab interface is busy, yeah. But you it packs a lot of functionality in. If you want, you disable features like wiki and snippets to free up space on the side bar of a project. Or just look past it and find the part you want, issues merge requests, whatever.
After working for years with GitLab professionally, you know exactly where everything is.
Particularly making a contribution should anyhow be trivial - you push the branch and it shows a banner in the repo asking if you want to open a MR for the recently pushed branch.
I don't know why anyone would use GitHub actions. They seem like a weird, less powerful version of the GitLab CI. Now they want to charge for runtime on your own runner.
codeberg.org for open source, because it's a non-profit, with what it seems, very well intentioned people, with a good governance structure, and it's starting to support federation.
For a company, I'd recommend self-hosting forgejo (which also has actions), which powers codeberg.
(forgejo started as a fork of gitea)
Gitea is almost fully compatible with the GitHub runners. You might need to do small changes in the workflows.
Self-hosted gitlab here. Love it, and gitlab CI is excellent as well. Almost all product development revolves around some crappy AI integration that we don't use, and it worries me to see so much focus there instead of the core product, but the core product is still excellent.
Gitea!
And the best (maybe?) part in your case is that the CI is based on GH Actions, so you can probably reuse your workflows without the need to adapt them.
"Outrageous"? It's two tenths of a cent per minute. How much will it impact you, really, particularly relative to the cost of compute?
It's outrageous because self hosted runners are... self hosted.
And the entire solution just sucks. It's bad, bad software. It barely works a lot of the time.
The only reason they're doing this is because they can. Which is usually a really stupid reason. And here, it is. So, that's outrageous.
> because self hosted runners are... self hosted.
Sure, but there's a separate mechanism that you need to make it all work: the orchestration. Without that, you have only the capacity to run jobs -- it's potential energy, if you will, not doing real work.
That orchestrator thus provides real value. And it's not like it's free for them to build, operate, and maintain.
The CI pipeline using my own runner is absolutely something that I expect to come for free with hosting the repository.
At our company, it's ~35k USD increase annually. This is not negligeable.
That’s 2.5x what my actual runners cost. For every $100 in compute, I will be paying $250 to github. They can fuck right off
I'm curious - where are you finding runners for $0.0008/minute? What are their specs?
Ubicloud. Also faster than the analog runners github provide. Only problem is startup time is slower
I will try Gitea -- thanks everyone for the recommendations
Gitea has a fully compatible system AFAIK.
Yikes! They seem to be gunning for services like WarpBuild, which we've used for a couple years to keep our costs low. The $0.002 per minute on top of WarpBuild's costs is exactly GitHub's new pricing scheme.
I'm happy for competition, but this seems a bit foul since we users aren't getting anything tangible beyond the promise of improvements and investments that I don't need.
The lever that matters the most with the new $0.002/min tax is to reduce the number of minutes consumed.
Given that GitHub runners are still slow as ever, it actually is a point in our favor even compared to self-hosting on aws etc. However, it makes the value harder to communicate <shrug>.
Thanks for the email and the reminder that we can use fewer shards with larger runners.
Tangled has a nix based workflow engine that looks very similar, if you are into nix and self-hosting runners
https://tangled.org/tangled.org/core/blob/master/docs/spindl...
(no affiliation)
---
Blog post about Tangled's CI: https://blog.tangled.org/ci
Very cool! Are there any blog posts or articles about Tangled? Docs seem pretty light.
I pinged them on Bluesky to join this HN story comments, they would be better equipped to answer
https://bsky.app/profile/tangled.org
There looks to be a blog post here: https://blog.tangled.org/ci
How does this compare to just running Hydra yourself?
Useless for Mac or Windows presumably.
What do you mean? This is for CI, whatever the dev machine runs is irrelevant. Either way, the CI uses OCI containers built with Nix, you don't need Nix installed on the host. Also Nix supports MacOS.
self-hosted, so same story?
I'm not a fan of nix and would have picked containers regardless for a git forge CI offering
It is containers. It's based on Nixery, which is a virtual Docker registry where it puts together containers for you on the fly containing whatever packages you want from Nixpkgs.
If this gives you pause, consider these hosted alternatives as another option:
* Codeberg https://codeberg.org/
* Sourcehut https://sr.ht/ [1]
[1] https://sourcehut.org/alpha-details/
Codeberg's uptime is so bad, that it actually makes GitHub look good. ~96.5% over last 2 weeks [1]
[1]: https://status.codeberg.org/status/codeberg
The operate on less than 100_000€/year, so I would cut them some slack ;-) btw. codeberg is not a company, more like a foundation, Verein is the german word.
I fail to see how this is relevant to the point I was making. With uptime being so low, it's not a viable alternative: budget / resources / etc. don't change that fact.
Don't get me wrong — I am glad that they are doing what they're doing, but it's a long way until it becomes a real alternative.
We don't actually know what githubs uptime is because they don't say. If you told me it's less than 96.5, I might believe you, particular for actions.
I'm sure if Codeberg had equivalent resources they'd be good, hard to fault a nonprofit for not benefiting from a trillion dollar multinational corporation. What was GitHub's excuse for their failures?
I am not criticizing Codeberg, I'm just adding context that seems very important from my experience.
As mentioned above — I am glad that they exist and do what they do. However, that doesn't mean I should ignore issues like this.
Are they a profit center yet?
Or just run a self hosted GitLab open source instance? Running it for 6 years now with nearly zero issues and a great CI.
Last time I self hosted GitLab I was greeted with an "Update ASAP" Badge on the admin page basically every week and that has scared me away.
I’m genuinely excited about this. The GitHub actions platform is genuinely bad compared to circle or Travis but they’ve been totally crowded out because GitHub was just so easy to use. This has led to plenty of security issues and a general lack of innovation in the ci space. Hopefully by this pricing structure change we’ll see more investment in ci tooling across the industry
GitHub Actions were never too easy to use. But they were cheap to use, so anything more expensive had trouble competing.
Now the playing field is more level, yay. Fun for those who choose to migrate away.
This. There are plenty of good/better CICD solutions out there, but it's tricky to compete with "comes for free with our VCS". I guess it's clear now there is no such thing as a free lunch. I feel it's a good thing for the "CICD industry" that people will be looking around to alternatives, and do a honest Total Cost of Ownership analysis.
Why would the self-hosted runner fee be per-minute instead of per-job? I don’t get it.
I had the same question — I understand that the Actions control plane has costs on self-hosted runners that GitHub would like to recoup, but those costs are fixed per-job. Charging by the minute for the user’s own resources gives the impression that GitHub is actually trying to disincentivize third-party runners.
Self-hosted runner regularly communicates with the control plane, and control plane also needs to keep track of job status, logs, job summaries, etc.
8h job is definitely more expensive to them than a 1 minute one, but I'd guess that the actual reason is that this way they earn more money, and dissuade users from using a third party service instead of their own runners.
Might be an estimation of logs storage/bandwidth.
That's generous, but doesn't seem consistent with how Microsoft does business. Also, if that's the case why does self-hosted cost the same as the lowest hosted tier?
or some other metric like how many logs your job produces and they have to process
the only rational outside rationale is this has the best financial projections, equitability with the customer be damned
gotta make up for those slumping ai sales somehow, amiright?
Because the competitor services that provide much cheaper hosted runners also charge per minute.
This isn't aimed at people actually self-hosting; it's aimed at alternative hosted runners providers. See this list
https://github.com/neysofu/awesome-github-actions-runners
The $0.002 per-minute for self-hosted runners will definitely change the unit economics for a lot of 3rd party runner providers.
I'm sure we'll feel it too at https://sprinters.sh, but probably a bit less than others as our flat $0.01 per job fee for runners on your own AWS account will still work out to about 80% average savings in practice, compared to ~90% now when using spot instances.
I use GitHub Actions for only one thing, which is to automatically assign any issues to myself (by using the "gh" program), and I am not paying anything for it. Furthermore, the repositories that use this are all public (I do not have any private repositories on GitHub, and due to various things I will not do that).
As far as I can tell from that article, these changes will not affect me; it says "Standard GitHub-hosted or self-hosted runner usage on public repositories will remain free" and another section says "This will not impact Actions usage in public repositories". Hopefully, this information would behelpful for other people who use GitHub Actions. However, I don't know if I missed something else that is important, from the article.
This sounds correct, there are no changes for public repositories.
For private repositories, each GitHub account gets 2000 free minutes of runtime per month. Both self-hosted runners and GitHub-hosted runners count against that quota.
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 is still cheaper than not Despite the $0.002/minute self-hosted runner tax, self-hosting runners on your cloud (aws/gcp/azure/...) 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.
Note: I make WarpBuild, where we provide github actions runner compute. Our compute is still cheaper than using github hosted runners (even with the $0.002/min tax) and our runners are optimized for high performance to minimize the number of mins consumed. I'm generally biased, but I think the points 1-6 apply irrespective of WarpBuild.
Related: Github Actions control plane is no longer free https://news.ycombinator.com/item?id=46291500 https://www.blacksmith.sh/blog/actions-pricing
I wonder how much they made from engineering practices such as https://github.com/actions/runner/issues/3792.
To spell it out: jobs can hang forever because of some ridiculously bad code on their end, they have a 6 hour cap, so that's 6 hours of billable $$$ per-instance of the bug (assuming it wasn't manually canceled). I know I've seen jobs hang forever regularly over the course of my years using GitHub for work.
Note: pretty sure this has been resolved.
Oh, I had that happen fairly recently.
Earlier this year I priced out AWS's on-demand m7i.large instances at $0.002/minute [1]. GitHub's two-core costs $0.008/minute today so it was a nice savings. But it looks like this announcement doubles the self-hosted cost and reduces their two-core system pricing to $0.006/min.
From this perspective this is a huge price jump, but self-hosting to save money can still work out.
Honestly, GitHub Actions have been too flaky for me and I'm begrudgingly reaching for Jenkins again for new projects.
[1] https://instances.vantage.sh/aws/ec2/m7i.large?currency=USD&...
Have you considered other options like woodpecker for example?
Could this change mainly be about competition with their own hosted runners?
Today it's possible to spin up a company that sells GitHub Actions runners with a lower price and higher performance than GitHub's own hosted runners. These new fees will make that a lot less economically viable.
With these changes, three things hold:
1. Services like WarpBuild (I'm the founder) are still cheaper than GitHub hosted runners, even after including the $0.002/min self-hosting tax.
2. The biggest lever for controlling costs now is reducing the number of minutes used in CI. Given how slow Github's runners are, or even the ones on AWS compared to our baremetal processor single core performance + nvme disks, it makes even more sense to use WarpBuild. This actually makes a better case for moving from slow AWS instances running with actions-runner-controller etc. to WarpBuild!
3. Messaging this to most users is harder since the first reaction is that Github options make more sense. After some rational thought, it is the opposite.
I guess I’ll start to look at an alternative to GitHub self hosted runners.
It’s been awhile since I looked. What’s a good alternative?
Are there any good CI systems to begin with? joking, but not really
Jenkins has been rock solid, we are trying to migrate to Argo Workflows/Events, but there are a complaints (like deploying argo workflows with helm, such fun!)
I've been using dagger.io and it's been really nice to work with.
- runs locally
- has a language server: python, typescript, go, java, OR elixer
- has static typing
- the new caching mechanisms introduced in 0.19.4 are chef's kiss
I do not work for dagger and pay for it using the company credit card. A breath of fresh air after the unceasing misery and pain that is Gitlab and GHA.
"Jenkins is the worst form of CI, except for all those other forms that have been tried."
-- Winston Churchill (probably)
buildkite
I am just waiting for GitHub starting to charge for API usage ...
On the heavy side, but TeamCity is full of goodies.
Pay even more to bring your own hardware? Well, that's new.
I get that self-hosted runners generate huge egress traffic, but this is still wild. Hope it pushes more companies to look into self-hosted Gitea / Forgejo / etc.
Jenkins not looking so bad anymore..
The email I received from them this morning claims that this will be cheaper for 96% of users...
I have cron jobs on several github projects that runs once a day and I have never been charged anything for it (other than my github membership). Should I expect to be charged for this?
I would think that majority of users does not use GitHub actions at all or have very light infrequent usage so that would be true. I think with my personal project I have never exceeded the resources they give me as part of personal pro subscription.
I didn't find a single example of any of the upcoming features, should I follow them in github to read release notes?
https://github.blog/news-insights/product-news/lets-talk-abo...
they are only building "ai" features now
No, the AI is only building AI features now, or so they say.
Our current GitHub bill is $90/month, this would add an additional $700/month. I don't see how this doesn't cause a mass outflux.
Curious: Can you expand a little bit on your usage? $700/month equates to 350,000 minutes. Are you just running a truck-load of different Actions, or are the Actions themselves long-lived (waiting on something to complete)?
How much do you pay for the servers that run actions? Is it much more than $610? Then it kinda makes sense.
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 guess it was only a matter of time...
Part of this is fair since there is a cost to operating the control plane.
One way around this is to go back to using check runs. I imagine a third party could handle webhooks, parse the .github/workflows/example.yml, then execute the action via https://github.com/nektos/act (or similar), then post the result.
inb4 "our webhooks are now 2c per call"
That makes me genuinely curious about the internal hosted vs. self-hosted usage ratio they're seeing. I'd have guessed the bulk of the cost/volume was on hosted, but clearly that can't be the case
Anecdotally I've seen it get a lot more common to use third-party managed runners (e.g. Blacksmith) for anyone that needs slightly beefier machines and/or a caching system that actually works.
Yeah, we migrated to self hosted actions runnrers on hetzner 2 years ago, the speed improvement was massive
GitHub charges too much for hosted runners. It's pretty straightforward to switch to another runner provider at literally half the cost of GitHub.
They are not just more expensive, they are also slower. Last time I compared them, AWS ARM64 instances could easily run jobs 30% faster, for the same CPU/memory count, than those that GitHub offers.
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.
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.
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.
"That said, most teams don't self-host purely to save money"
I think most do. Or at least the infrastructure/compute costs are not coming from their own dept budget anymore ;)
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.
> Streaming logs and other supporting functionality
GitHub's log streaming also sucks. It's very laggy and chunked, whereas GitLab's is pretty much real-time.
PLEASE stop propping up the narrative that the GitHub Actions control plane was previously free. It never was. Pricing is not that simple. I see way too many people in this thread, and even GitHub Actions competitors promoting this nonsensical narrative.
There has to be a VC in this thread, go ahead and fund a GitHub competitor that offers a flat monthly(yearly?) rate.
Focus on the enterprise. Something like a 3000$ minimum yearly price. Direct customer support with real engineers no questions asked.
Need someone to setup your CICD, that's another fee, but on staff engineers will get it done.
Edit: I'd even imagine a company like this can bootstrap, I'd need help though. Would probably take 4 skilled SWEs about 6 months for an MVP.
It's Jujutsu based, but I imagine East River Source Control https://ersc.io/ may be building a GitHub competitor.
The urge to move to Codeberg grows with every passing day.
Or use Gitea or Forgejo and host it yourself.
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!
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?
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.
Those of us who have been writing it "Micro$oft" since the 90's can now say, "I told you so."
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.
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.
Would also be interested in a better platform
Earthly did not work out, and dagger had the problem of we support everything but but nothing is great
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.)
> Standard GitHub-hosted or self-hosted runner usage on public repositories will remain free. GitHub Enterprise Server pricing is not impacted by this change.
Per-minute pricing for self-hosted runners seems like a very fast way for them to force everyone who actually is using self-hosted runners to migrate away.
I suspect we'll be doing that sometime in January or February.
I guess forgejo is the easiest migration path? https://forgejo.org/
Ahh, so since GitHub is completely incompetent when it comes to managing a CI they are going to make it worse for everyone to get their cut.
I hate GH Action runners with a passion. They are slow, overpriced, and clearly held together with duct tape and chewing gum. WarpBuild, on the other hand, was a breeze to setup and provided faster runners and lower prices.
This is a really shitty move.
Hey GitHub, your Microsoft is showing...
I have never been a fan of GitHub and their entire system, always felt Bitbucket or GitLab were superior in terms of the tooling and included features across all plans.
However, my experience with GitHub Actions was really poor. Some build that would run perfectly on my local machine and any other servers we have hosted would always time out on GitHub runners. I went back and forth from small runners to large runners and the result was always the same. Then I found that there are third-party companies just offering replacement runners for GitHub Actions at less than half the price for an amazing reliability and cost. It was a night and day difference.
Now... this move by GitHub is almost unbelievable. Charging folks to use their own machines
Hey - thanks for the WarpBuild love!
Given github ran 11.5 billion mins of actions in 2025, and most of them would've been on self-hosted runners, this move makes some sense from their POV.
However, this is still an... interesting... move, especially after bitbucket got all that hate a few weeks ago for doing something similar.
Maybe it's time to start dusting off the ol' Jenkins-fu?
Charging per minute for self-hosted runners seems absolutely bananas!
We all knew this would happen. For open source projects one step local build and test is superior to full automation for this reason. It lasts forever whereas these automated server configs require ongoing maintenance.
But open source is still free for now.
I've been running self hosted runners for my company using Actions Runner Controller (ARC) on my own kubernetes infrastructure. Could never really get the devs invested in GitOps style dev cycles so I may just chuck actions and use a more nightly or on demand style build server since that seems to be what they desire and expect. I always expected this day to come so my actions use very little github/actions specific stuff, mainly they just kick off scripts already. I do wonder how hard it would be to create my own github API pollers etc but not sure I want to invest any further in anything github specific. Good news is the effective date is March and the initial prices for my usage will probably be very low but I fully expect them to push further price increases / monetization / lock-in.
this article explains release better than github itself https://www.blacksmith.sh/blog/actions-pricing
Anything that prices spammers out of abusing GitHub actions is a win in my book...
Maybe it's a lack of imagination on my part, but how do spammers abuse self-hosted runners?
Form submission spam. Unique/'untraceable' IPs...
How do they abuse self hosted runners?
Hmm... News about massive RAM price hikes. Then GitHub decides to charge for per-minute. Do they keep a lot of stuff in RAM while a workflow is running?
> > 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.
That's actually $90/month, that's kind of crazy.
I realise 100% utilisation isn't realistic, but that still sounds very expensive when you're already BYOB.
> I realise 100% utilisation isn't realistic
It's worse than unrealistic. It's ludicrous. Any company running more than an hour of actions workflows per week on GitHub can afford a few dollars a month for infrastructure. The per-minute charge is less than the cost of a millisecond of engineering labor time.
Monorepo, though Gitlab, self-hosted runner, 41 hours in the last week.
Tell me that $20/month is a notable amount of expense for your business spending 41 hours per week on workflows. Go on.
Dude why are you so determined to defend this pricing change? You're all over this thread arguing with people that it's not a big deal. If it's a big deal to them, why do you give a shit? It's not like it's your problem if people take their business elsewhere for a poor reason.
This increases our CI compute costs by 30%.
We'd be at roughly $700/month at current usage.
$3 a day, $100/mo to run your own github actions (which is a programming language based atop json ... sheesh). Ugh!!
I do not even understand why any decent size eng org uses actions. It only has rough edges.
37signal's `signoff` script is sounding like a good play in the very near future: https://world.hey.com/dhh/we-re-moving-continuous-integratio...
Microsoft has mierdas touch.
Possibly a good time to remind people that the default value of jobs.<job_id>.timeout-minutes is 360 (minutes), meaning that your hanging job will cost $0.72 before it times out.
https://docs.github.com/en/actions/reference/workflows-and-a...
Is there a great opensource CI system that integrates nicely with github repos?
Use Blacksmith. I promise you won't regret it.
Back to Buildkite I go.
Isn't it like way more expensive and restricted? They were very competitive in the early days, but currently they are more capped than anything else it seems. Especially for self hosting..
> Hosted Agents > > 2,000 minutes/month
:-o
Buildkite doesn't have per-minute charges for self-hosted agents.
Ok, they have changed their pricing. Currently they are capping the number of concurrent agents. At one point, they introduced minutes cap and that was very big step down.
what are the opensource alternatives to selfhosted runners ?
That's just the point. Selfhosted runners were the alternative. The only alternative for "runners" is Github-hosted, 200%-markup runners.
Now the only alternative is to move builds, CI, etc. off of GitHub's platform entirely, and maybe your source control as well. In other words, a big pain. Github seems to have entered peak encrapification: the point where they openly acknowledge rent-seeking as their product approach, fully deprecating "building the best, most reliable, trustworthy product." Now it's just "Pay us high margins because the effort to migrate off is big and will take too long to break even."
Basically the modern day Heroku business model.
https://woodpecker-ci.org/
Also found https://crowci.dev/4.5/ which seems to have better docs.
Genuinely curious about this as well. It's a major bummer that self-hosted infra can't be used to validate GitHub Pull Requests now; basically means I'll have to move my entire workflow off of GitHub so that everything can be integrated reasonably again.
That's not exactly true. You just won't be able to use self-hosted infra to validate GitHub PRs a) using GHA and b) for free.
GitHub still supports e.g. PR checks that originate from other systems. We had PR checks before GHA and it's easy enough to go back to that. Jenkins has some stuff built in or you can make some simple API calls.
It's not as convenient, but it works just fine.
Won't those other systems create a cost that is metered in terms of run-time?
Woodpecker CI supports GitHub: https://woodpecker-ci.org/
Gitea + Gitea Actions works approximately as well as GHA. For GitHub specifically, you're back to setting PR checks + commit status programmatically through the API.
Love how they drop this news right before everyone goes away for the xmas holidays and it kicks in right as you come back. Or before you come back if you live outside the US.
Founder of Depot[0] here. I'm disappointed by this change and by the impact this is going to have on all self-hosted runner customers, not just us. In my view, this is GitHub extracting more revenue from the ecosystem for a service that is slow, unreliable, and that GitHub has openly not invested in.
We will continue to do our best to provide the fastest GHA runners and keep them cheaper than GitHub-hosted runners.
[0] https://depot.dev
i think it's time to migrate like zig.
So can we just go back to using external CI platforms that just interact with GitHub's commit status API or whatever?
I have a love-hate relationship with GitHub Actions. Love because they are right there in my GitHub repository. Hate because they are very brittle once you move out of the happy path.
It seems GitLab has a much better experience in this department, but their pricing is hard to justify for us...
Genuinely curious if folks here had better experiences or recommendations for a smooth CI/CD experience.
Love-hate for me as well. Love that there is native github integration for triggering events and other github bits. Hate the brittleness and anymore the reliability even if you are just using the control plane. I've always sought to keep my actions as mainly just calling existing scripts, that is keep logic out of them and make them relatively dumb wrappers but it would still be some effort to get off it.
I read this and I'm thinking I should just get Claude to write me my own GitHub (with blackjack! and... nevermind)
I'm in the era of writing my own tools, not to share just for me or whatever group I'm working in. If you're going to charge me for something rife with annoying struggles, I might as well be annoyed by a tool I control.
ah! a fellow futurama lover, i see you
I was worried about this, but $10/mo for 5000 self-hosted minutes isn't terrible, the self-hosted runner feature is great for our use cases where the repo is too big to run in the cloud generally and/or ingress/egress is too expensive.
Why are there no changes for plans with included minutes e.g. enterprise that has 50000 since the runners are now cheaper? So now the included tier has effectively been reduced.
Do private orgs/repos get any free platform minutes? Currently I’m getting 2,000 free minutes of action runtime with a private org/repos.
how long before they start skimming OSS projects that are public but nonetheless have Github Sponsors income. I mean that's money right there for them right
Wasn't that the key concern of Zig moving off GitHub?
dunno, but this is only actions. You can use github without being dependent on actions.
TLDR: Github is no longer free for self-hosted actions in private repositories, although there is a free quota.
Everyone in this thread has gone absolutely insane. $5/month gets you 41 fucking _hours_ of continuous operation. If you're not utterly abusing the platform, this falls extremely below the threshold of caring. And if not, what the fuck are you even doing with all those hours? The new per-minute charge is less than one millisecond of engineer labor cost.
I have a nightly software build of a piece of software that takes 6 hours to create a 70GB artifact. The build process requires a GPU so it runs on my own HW. That's ~180 hours per month for this job alone. Is that really so hard to imagine?
I don't know how much of that 6 hours build is tangled up in github workflows, but if it's a single contiguous block, you probably could make it near zero by making the self-hosted runner do only the preparation and only the final upload process (workflow_dispatch when the build is complete).
Most of it is just time waiting either while the source assets are downloaded (I clean slate it, that's the point of CI after all), the build itself runs, or the artifact is uploading to it's storage home. I'm sure it could be re-architected to use less actions minutes but if I'm going to redo it I will probably just move away from actions altogether because it's only loosely linked to Github anyway (runs on a schedule) and that way I am insulated from any future changes they come up with. The hardest part will likely be figuring out the Slack bot posting, I do use the marketplace action for that, but that's probably low lift. With LLM assisted coding I'm leaning more and more to little in house apps for stuff like this, it keeps you from dealing with lock in and other extractive gotchas.
I think you significantly underestimate the number of CI minutes people are using in practice.
(Which, yes, has implications for energy use/climate change too for sure).
It doesn't look like i currently have access to the usage data on any of the lots-of-runners-lots-of-PRs projects I currently work on (which are still probably way less than some large companies).
> some large companies
Any "large companies" don't give a shit about things at this cost level. They spend more on the time it takes you to open the door. The number of CI minutes could be astronomical and it still wouldn't rate above the threshold of caring. The time people in this thread have spent wringing their hands is way more expensive.
per minute billing is hard to wrap around the head
On my larger organization, we have on average 20 to 30 *active* runners during business hours. Assuming 5 on the off-hours, my napkin math says it comes down to about 10 fully-utilized-runners per month, so about 864$/mo. For the size of my organization that is honestly totally acceptable.
This is assuming 0.002$ per minute of job being actively executed. If it turns out to be 0.002$ per minute of *runner being registered* on the control plane, it would increase quite a bit. We are still using the old HorizontalRunnerAutoscaler with actions-runner-controller, with quite a pool of prewarmed runners idling to pick up a job. It would be a strong reason to use the new RunnerScaleSet (to take advantage of the reactive webhook-based scaling) and keep a very lean pool of prewarmed runners.
It could be 1 dollar a month, I'm still not paying to use my own ressources
Well, you obviously are using their resources, to kick off and register statuses of the jobs running on your resources, right? That is probably worth $1/month to you?
Doesn't this depend a lot on how long your actions run? Like, you may have already invested in your own hardware (maybe because your actions use a lot of resources and it's cheaper) and now you have to pay per-minute of action runtime for the API that does the bookkeeping?