It does? I feel like it implies that they want third-party runners like Blacksmith out of the ecosystem, which is why they're now financially penalizing customers who use them.
It used to suprise me that people saw cool tech from Microsoft (like VSCode) and complain about it.
I now see the first innings of a very silly game Microsoft are going to start playing over the next few years. Sure, they are going to make lots of money, but a whole generation of developers are learning to avoid them.
Thanks for trying to warn us old heads!
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.
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.
(I work exclusively on public repo open source at the moment, and get Github actions for free).
The writing is in the wall. First it was UX annoyances. Then it was GitHub Actions woes. Now it is paying money for running their software on your own hardware. It's only going to go downhill. Is it a good time now to learn from our mistakes and convince our teams and management to use community-maintained, libre alternatives? They may be inferior. They may lack features. But they're not going to pull user hostile tricks like this on you and me. And hey, if they are lacking features, maybe we should convince our management to let us contribute time to the community to add those features? It's a much better investment than sinking money into a software that will only grow more and more user hostile, isn't 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...
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.
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-...
This is $2.88/day, $86.4/month, $1051.2/year. For them to do essentially nothing.
Most notably, this is the same price as their hosted "Linux 1-core" on a per-minute basis. Meaning they're charging you the same for running it yourself, as you'd pay for them to host it for you...
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.
The only variable is how long after acquisition before they gut it. It's almost never right away. GitHub was acquired 7 years ago, but it started showing symptoms perhaps 2 years ago.
With this I think it's clear the wound was fatal. GitHub will stumble on for a few more years with ever-decreasing quality, before going the way of Skype.
So, I guess we're all migrating to gitlab? Or is it time to launch gittube? Githamster?
Anyone using GitLab or any other VCM that you'd recommend? I'm absolutely done with Github. Or is everything else just as bad?
1. Services like blacksmith and 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.
Overall - it is worse for Github users, but options like blacksmith and WarpBuild are still the better option.
1. https://medium.com/@the_atomic_architect/github-vs-gitlab-20...
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.
https://tangled.org/tangled.org/core/blob/master/docs/spindl...
(no affiliation)
---
Blog post about Tangled's CI: https://blog.tangled.org/ci
* Codeberg https://codeberg.org/
* Sourcehut https://sr.ht/ [1]
i think it should be illegal or otherwise extremely damaging to do this kind of thing
Charging a per-workflow-minute platform fee makes a lot of sense and the price is negligible. They're ingesting logs from all the runners, making them available to us, etc. Helps incentivize faster workflows, too, so pretty customer-aligned. We use self-hosted runners (actually WarpBuild) so we don't benefit from the reduced default price of the Github-hosted runners, but that's a nice improvement as well for most customers. And Actions are still free for public repos.
Now if only they'd let us say "this action is required to pass _if it runs_, otherwise it's not required" as part of branch protection rules. Then we'd really be in heaven!
Now Microsoft will charge "data plane usage" (CRUDing a row that contains (id, ts, state_enum, acc_id ...) in essence) 2.5 more than what Ubicloud offers for WHOLE compute. Also to have "fair pricing" they'll make you pay 2.5 more the compute's price for being able to use their data plane.
cool.
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.
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.
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&...
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.
It’s been awhile since I looked. What’s a good alternative?
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?
Actually there were alternatives that were far superior (seriously, no way to group projects?) but also more than 2x as expensive. If GH "fixes the glitch" then it will be plan B time.
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.
* its 7 VPS because we separated the tests by modules and we have 7 major modules. * edit: formatting
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>.
Is it that egregious?. I read it as they are redistributing the costs. It is in combination dropping the managed runner costs by a good margin and charging for the orchestration infrastructure. The log storage and real time streaming infra isn't free for them (not $84/month/runner expensive perhaps but certainly not cheap )
We don't need to use the orchestration layer at all, even if we want to use rest of the platform, either for orchestration or runners. Github APIs have robust hooks(not charged extra) and third-party services(and self-hostable projects) already provide runners, they will all add the orchestration layer now after this news.
--
Competition is good, free[2] kills competition. Microsoft is the master of doing that with Internet Explorer or Teams today.
Nobody was looking at doing the orchestration layer because Github Actions was good enough at free[1], now the likes of BuildJet, Namespace Labs etc are going to be.
[1] Scheduler issues in Github Actions not withstanding, it was hard to compete against a free product that costs money to build and run.
[2] i.e. bundled into package pricing,
- charge the same you would pay for the GitHub runners
- you have to factor YOUR server cost also, so self hosted will cost more than the platform option
- you jump to the platform runners and save on servers, sysadmin, DevOps, etc.
And then they grab you by the balls and raise the prices.
So the question becomes: is $0.002/minute a good price for this. I have never run GitHub Actions, so I am going to assume that experience on other, similar, systems applies.
So if your job takes an hour to build and run though all tests (a bit on the long side, but I have some tests that run for days), then you are going to pay GitHub $.12 for that run. You are probably going to pay significantly more for the compute for running that (especially if you are running on multiple testers simultaneously). So this does not seem to be too bad.
This is probably going to push a lot of people to invest more in parallelizing their workloads, and/or putting them on faster machines in order to reduce the number of minutes they are billed for.
I should note that if you are doing something similar in AWS using SMS (Systems Management Service), that I found that if you are running small jobs on lots of system that the AWS charges can add up very quickly. I had to abandon a monitoring system idea I had for our fleet (~800 systems) because the per-hit cost of just a monitoring ping was $1.84 (I needed a small mount of data from an on-worker process). Running that every 10 minutes was going to be more than $250/day. Writing/running my own monitoring system was much cheaper.
Or shortly summarized: lock in through pricing.
Pretty sure this will explode straight in their faces though. And pretty damn hard.
If you don't want to pay, you'd have to not use GitHub Actions at all, maybe by using their API to test new commits and PRs and mark them as failed or passed.
They don't care about people actually self-hosting. They care about people "self hosting" with these guys:
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?
This isn't aimed at people actually self-hosting; it's aimed at alternative hosted runners providers. See this list
It's there a particular reason you're extending the benefit of the doubt here? This seems like the classic playbook of making something free, waiting for people to depend on it, then charging for it, all in order to maximize revenue. Where does the idea that they're really doing this in order to deliver a more valuable service come from?
(plz correct me if i'm wrong)
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.
1) company uses exclusively free software, spends more time dealing with the shortcomings of said software than developing product, product is half baked and doesn't sell well, company dies.
2) company uses proprietary but cheap/free (as in beer) software that does the job really well, focuses on developing product, product is good and sells well, company how has a ton of money they could use to replicate the proprietary product from scratch if they wanted to.
A purist approach like in scenario 1 leaves everyone poor. A pragmatic approach like scenario 2 ends up earning enough money that can be used to recreate the proprietary software from scratch (and open-source it if you wanted to).
In this case the problem isn't even the proprietariness of the software, it's the fact that companies are reliant on someone else hosting the software (GH being FOSS wouldn't actually change anything here - whoever is hosting it can still enforce whatever terms they want).
FOSS alternatives already exist, it's just that our industry is so consumed by grifters that nobody knows how to do things anymore (because it's more profitable for every individual not to); running software on a server (what used to be table stakes for any shop and junior sysadmin) is nowadays lost knowledge. Microsoft and SaaS software providers are capitalizing on this.
"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."
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.
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...
> Actions is down again, call Brent so he can fix it again...
- Introducing a cheap 1-core runner
- Lowering the price of GitHub-hosted runners
- Making it slightly more expensive to use self-hosted runners
- There is actually a fourth one: the vnet integration, which also allows you to run public runners in your own infra
As a bonus, for some people it means something that was free is now not free. Those who are willing to pay rather than go, might prefer to use GitHub-hosted if they are going to pay anyway.
This is clearly an incentive to use github-hosted, and their sales reps are also going this way.
That depends, not always. Sometimes the employees of said company manages to contribute back upstream, on the dime of the company. If the "free software" they used and contributed to have a lot of users, it's certainly not "leaves everyone poor" but rather "helps everyone, beyond monetary gain".
Sure, you can make the argument that it isn't that great for the company, and you may be right. But the world is bigger than companies making money, killing a few companies along the way to make small iterative steps on making free software for absolutely everyone is probably a worthwhile sacrifice, if you zoom out a bit.
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.
Can't we switch to something more advanced in terms of protocols (like one that always maintain 3 copies, and where people can give ressources (cpu/bandwidth/memory) in the forms of tokens)?
Are Control Plane costs already separately charged?
Why would a public repo use a self-hosted runner ? because the self-hosted runner storage available is only 14GB !!
The real mistake was GH not charging anything for self-hosted runners in the first place, setting an expectation.
Considering that the lifetime of our sun system is finite that statement is undeniably true.
Also we don't know how a non-Microsoft GitHub could have developed.
For a company, I'd recommend self-hosting forgejo (which also has actions), which powers codeberg.
(forgejo started as a fork of gitea)
https://docs.github.com/en/enterprise-cloud@latest/admin/con...
[0]: https://docs.gitlab.com/user/project/repository/branches/pro...
The split between tag and branch pipelines seems like intentional obfuscation with no upsides (you can't build non-latest commit from a branch, and when you use a tag to select the commit, GitLab intentionally hides all branch-related info, and skips jobs that depend on branch names).
"CI components" are not really components, but copy-paste of YAML into global state. Merging of jobs merges objects but not arrays, making composition unreliable or impossible.
The `steps` are still unstable/experimental. Composing multiple steps either is a mess of appending lines of bash, or you have go all the way in the other direction and build layered Docker images.
I could go on all day. Programming in YAML is annoying, and GitLab is full of issues that make it even clunkier than it needs to be.
https://bsky.app/profile/tangled.org
There looks to be a blog post here: https://blog.tangled.org/ci
It was govt thing and they are required to put a new bid every few years and their bid was EVIDENTLY "just list what our current hosting provider has, we can't be arsed to spend months migrating infrastructure every few years", but the clever weasels in the sales managed to get them.
I am not open to GitHub extracting usage-based rent for me using my own hardware.
This is the first time in my 15+ years of using GitHub that I'm seriously evaluating alternative products to move my company to.
It makes sense to do usage-based pricing with a generously-sized free tier, which seems to be what they're doing? Offering the entire service for free at any scale would imply that you're "paying" for/subsidizing this orchestration elsewhere in your transactions with GitHub. This is more-transparent pricing.
Although, this puts downward pressure on orgs' willingness to pay such a large price for GH enterprise licenses, as this service was hitherto "implicitly" baked into that fee. I don't think the license fees are going to go down any time soon, though :P
Now the GitHub pricing change definitely? costs more than both servers combined a month ... (They cost about 60$ together )
3 step GitHub action builds around 1200 nix packages and derivations , but produces only around 50 lines of logs total if successful and maybe 200 lines of log once when a failure occurs And I'm supposed to pay 4$ a day for that ? Wonder what kind of actual costs are involved on their side of waiting for a runner to complete and storing 50 lines of log
Unless you're on the free org plan, they're hardly doing it "for free" today…
Right, instead, they now charge the full cost of orchestration plus runner for just the orchestration part, making the basic runner free.
(Considering that compute for "self-hosted" runners is often also rented from some party that isn't Microsoft, this is arguably leveraging the market power in CI orchestration that is itself derived from their market power in code hosting to create/extend market power in compute for runners, which sounds like a potential violation of both the Sherman Act and the Clayton Act.)
Absolutely not, since it's the same price as their cheapest hosted option. If all they're doing is orchestration, why the hell are they charging per-minute instead of per-action or some other measure that recognizes the difference in their cost between self-hosted and github-hosted?
> Or shortly summarized: lock in through pricing.
how would increasing price make you locked in more ?
> If you don't really care about the metadata all it pretty much takes is moving git repositories with their history.
moving PR/CI/CD/Ticket flow is very significant effort, as in most companies that stuff is referenced everywhere. Having your commits refer ticket ID from system that no longer exists is royal PITA
I checked out Forgejo's site just now, they are kind of politically oriented instead of code oriented so I wouldn't use them:
"Brought to you by an inclusive community under the umbrella of Codeberg e.V., a democratic non-profit organization..."
Inclusive == Strike 1 democratic == Strike 2
Overall costs go up for everyone but we remain the better option.
I mean maybe https://github.com/rust-lang/bors is enough to fully replace Github Actions? (not sure)
Except the alternative is I do this for free but also I'm doing all the testing and providing the hardware.
I'm only going to charge you if you do most of the work yourself
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.
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
(ofc, that'd only mean they stop updating the status page, so eh)
Orchestration, logging, caching, result storage.
It's not nothing. Whether it's worth it to you is a value judgement, and having run a bunch of different CI systems I'd say this is still at least competitive.
Of course entirely expected after MS buyout, if anything I'm surprised it took that long
Maybe this is designed to scare people away from self-hosting altogether?
They seem to care much less about free users than in the past but businesses still flock to it. GitLab is the only other platform I’ve seen in the workplace of anywhere I worked, with the exception of a big tech company I worked at. They had both GitHub enterprise and an internally maintained platform which was being phased out. if I recall correctly it based on Phabricator
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?
Right now at my company our biggest complaint are macOS Intel runners from GitHub which somehow take 15+ minutes to provision and are the slowest of the bunch.
I get being charged per-run, to recoup the infra cost, but what about my total runtime on my machine impacts what GH needs to spend to trigger my build?
It was free, so anything other than free isn't really a good price. It's hard to estimate the cost on github's side when the hardware is mine and therefore accept this easily.
(Github is already polling my agent to know it's status so whether is "idle" or "running action" shouldn't really change a lot on their side.)
...And we already pay montly subscription for team members and copilot.
I have a self-hosted runner because I must have many tools installed for my builds and find it kinda counter productive to always reinstall those tools for each build as this takes a long time. (Yeah, I know "reproducible builds" aso, but I only have 24h in most of my days)
Even for a few hundreds minutes a month, we're still under a few $ so not worth spending two days to improve anything... yet.
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.
-- Winston Churchill (probably)
I was just using act (https://github.com/nektos/act) on my local server to build the X64 packages for my project, since I want to streamline it with ARM64 support, I migrated to the github self hosted runners.
This is really ridiculous, is M$ really lack that money just to schedule the Jobs running not in there infra?
I do not know what route are these companies taking. Microsoft has been crazy for past 2-3 years, but it is sad to see BitBucket and other alternatives also taking similar route :/
[0] https://docs.gitea.com/usage/actions/overview
[1] https://gitea.com/gitea/act / https://gitea.com/gitea/act_runner
TLDR - On January 1, 2026, we are lowering the price of hosted runners, and beginning March 1, 2026, we are charging $0.002 per-minute across self-hosted runners. The vast majority of customers will not see a change to their bill. Actions will remain free in public repositories.
We’re announcing updates to our pricing and product models for GitHub Actions.
Historically, self-hosted runner customers were able to leverage much of GitHub Actions’ infrastructure and services at no cost. This meant that the cost of maintaining and evolving these essential services was largely being subsidized by the prices set for GitHub-hosted runners. By updating our pricing, we’re aligning costs more closely with usage and the value delivered to every Actions user, while fueling further innovation and investment across the platform. The vast majority of users, especially individuals and small teams, will see no price increase.
We will have a GitHub Actions pricing calculator available where you will know how much you will be charged. You can see the Actions pricing calculator to estimate your future costs. 96% of customers will see no change to their bill. Of the 4% of Actions users impacted by this change, 85% of this cohort will see their Actions bill decrease and the remaining 15% who are impacted across all face a median increase around $13.
GitHub Actions will remain free for public repositories. In 2025, we saw developers use 11.5 billion total Actions minutes in public projects for free (~$184 million) and we will continue to invest in Actions to provide a fast, reliable, and predictable experience for our users.
When we shipped Actions in 2018, we had no idea how popular it would become. By early 2024, the platform was running about 23 million jobs per day and our existing architecture couldn’t reliably support our growth curve. In order to increase feature velocity, we first needed to improve reliability and modernize the legacy frameworks that supported GitHub Actions.
Our solution was to re-architect the core backend services powering GitHub Actions jobs and runners with the goals of improving uptime and resilience against infrastructure issues, enhancing performance, reducing internal throttles, and leveraging GitHub’s broader platform investments and developer experience improvements. This work is paying off by helping us handle our current scale, even as we work through the last pieces of stabilizing our new platform.
Since August, all GitHub Actions jobs have run on our new architecture, which handles 71 million jobs per day (over 3x from where we started). Individual enterprises are able to start 7x more jobs per minute than our previous architecture could support.
As with any product, our goal at GitHub has been to meet customer needs while providing enterprises with flexibility and transparency.
This change better supports a world where CI/CD must be faster and more reliable, better caching, more workflow flexibility, rock-solid reliability, and strengthens the core experience while positioning GitHub Actions to power GitHub’s open, secure platform for agentic workloads.
Starting today, we’re charging fairly for Actions across the board which reduces the price of GItHub Hosted Runners and the price the average GitHub customer pays. And we’re reducing the net cost of GitHub-hosted runners by up to 39%, depending on which machine type is used.
This reduction is driven by a ~40% price reduction across all runner sizes, paired with the addition of a new $0.002 per-minute GitHub Actions cloud platform charge. For GitHub-hosted runners, the new Actions cloud platform charge is already included into the reduced meter price.
Standard GitHub-hosted or self-hosted runner usage on public repositories will remain free. GitHub Enterprise Server pricing is not impacted by this change.
The price reduction you will see in your account depends on the types of machines that you use most frequently – smaller runners will have a smaller relative price reduction, larger runners will see a larger relative reduction.
This price reduction makes high-performance compute more accessible for both high-volume CI workloads and the agent jobs that rely on fast, secure execution environments.
For full pricing update details, see the updated Actions runner prices in our documentation.
This price change will go into effect on January 1, 2026.
We are introducing a $0.002 per-minute Actions cloud platform charge for all Actions workflows across GitHub-hosted and self-hosted runners. The new listed GitHub-runner rates include this charge. This will not impact Actions usage in public repositories or GitHub Enterprise Server customers.
This aligns pricing to match consumption patterns and ensures consistent service quality as usage grows across both hosting modalities.
This will impact self-hosted runner pricing starting March 1, 2026.
We are increasing our investment into our self-hosted experience to ensure that we can provide autoscaling for scenarios beyond just Linux containers. This will include new approaches to scaling, new platform support, Windows support, and more as we move through the next 12 months. Here’s a preview of what to expect in the new year:
This new client provides enterprises with a lightweight Go SDK to build custom autoscaling solutions without the complexity of Kubernetes or reliance on ARC. It integrates seamlessly with existing infrastructure—containers, virtual machines, cloud instances, or bare metal—while managing job queuing, secure configuration, and intelligent scaling logic. Customers gain a supported path to implement flexible autoscaling, reduce setup friction, and extend GitHub Actions beyond workflows to scenarios such as self-hosted Dependabot and Copilot Coding Agent.
We are reintroducing multi-label functionality for both GitHub-hosted larger runners and self-hosted runners, including those managed by Actions Runner Controller (ARC) and the new Scale Set Client.
This upcoming release introduces major quality-of-life improvements, including refined Helm charts for easier Docker configuration, enhanced logging, updated metrics, and formalized versioning requirements. It also announces the deprecation of legacy ARC, providing a clear migration path to a more reliable and maintainable architecture. Customers benefit from simplified setup, improved observability, and confidence in long-term support, reducing operational friction and improving scalability.
The Actions Data Stream will deliver a near real-time, authoritative feed of GitHub Actions workflow and job event data, including metadata such as the version of the action that was executed on any given workflow run. This capability enhances observability and troubleshooting by enabling organizations to integrate event data into monitoring and analytics systems for compliance and operational insights. By providing structured, high-fidelity data at scale, it eliminates reliance on manual log parsing and empowers teams to proactively manage reliability and performance.
Agents are expanding what teams can automate—but CI/CD remains the heartbeat of modern software delivery. These updates enable both a faster, more reliable CI/CD experience for every developer, and a scalable, flexible, secure execution layer to power GitHub’s agentic platform.
Our goal is to ensure GitHub Actions continues to meet the needs of the largest enterprises and of individual developers alike, with clear pricing, stronger performance, and a product direction built for the next decade of software development.
Why am I being charged to use my own hardware?
Historically, self-hosted runner customers were able to leverage much of GitHub Actions’ infrastructure and services at no cost. This meant that the cost of maintaining and evolving these essential services was largely being subsidized by the prices set for GitHub-hosted runners. By updating our pricing, we’re aligning costs more closely with usage and the value delivered to every Actions user, while fueling further innovation and investment across the platform. The vast majority of users, especially individuals and small teams, will see no price increase.
You can see the Actions pricing calculator to estimate your future costs.
What are the new GitHub-hosted runner rates?
See the GitHub Actions runner pricing reference for the updated rates that will go into effect on January 1, 2026. These listed rates include the new $0.002 per-minute Actions cloud platform charge.
Q: Why is .002/minute the right price for self-hosted runners on cloud?
We determined per-minute was deemed the most fair and accurate by our users, and compared to other self-hosted CI solutions in the market. We believe this is a sustainable option that will not deeply impact our lightly- nor heavily-active customers, while still delivering fast, flexible workloads for the best end user experience.
Which job execution scenarios for GitHub Actions are affected by this pricing change?
Standard GitHub-hosted or self-hosted runner usage on public repositories will remain free. GitHub Enterprise Server pricing is not impacted by this change.
When will this pricing change take effect?
The price decrease for GitHub-hosted runners will take effect on January 1, 2026. The new charge for self-hosted runners will apply beginning on March 1, 2026. The price changes will impact all customers on these dates.
Will the free usage quota available in my plan change?
Beginning March 1, 2026, self-hosted runners will be included within your free usage quota, and will consume available usage based on list price the same way that Linux, Windows, and MacOS standard runners work today.
Will self-hosted runner usage consume from my free usage minutes?
Yes, billable self-hosted runner usage will be able to consume minutes from the free quota associated with your plan.
How does this pricing change affect customers on GitHub Enterprise Server?
This pricing change does not affect customers using GitHub Enterprise Server. Customers running Actions jobs on self-hosted runners on GitHub Enterprise Server may continue to host, manage, troubleshoot and use Actions on and in conjunction with their implementation free of charge.
Can I bill my self-hosted runner usage on private repositories through Azure?
Yes, as long as you have an active Azure subscription ID associated with your GitHub Enterprise or Organization(s).
What is the overall impact of this change to GitHub customers?
96% of customers will see no change to their bill. Of the 4% of Actions users impacted by this change, 85% of this cohort will see their Actions bill decrease and the remaining 15% who are impacted across all face a median increase around $13.
Did GitHub consider how this impacts individual developers, not just Enterprise scale customers of GitHub?
From our individual users (free & Pro plans) of those who used GitHub Actions in the last month in private repos only 0.09% would end up with a price increase, with a median increase of under $2 a month. Note that this impact is after these users have made use of their included minutes in their plans today, entitling them to over 33 hours of included GitHub compute, and this has no impact on their free use of public repos. A further 2.8% of this total user base will see a decrease in their monthly cost as a result of these changes. The rest are unimpacted by this change.
How can I figure out what my new monthly cost for Actions looks like?
GitHub Actions provides detailed usage reports for the current and prior year. You can use this prior usage alongside the rate changes that will be introduced in January and March to estimate cost under the new pricing structure. We have created a Python script to help you leverage full usage reports to calculate your expected cost after the price updates.
We have also updated our Actions pricing calculator, making it easier to estimate your future costs, particularly if your historical usage is limited or not representative of expected future usage.
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
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
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 don't know if it's worth the amount they are targeting, but it's definitely not zero either.
It is a way of increasing lock-in for smaller-medium clients, without driving away their medium-large ones.
The considerations for commercial users leaving github are probably pretty different, so perhaps they'll stay.
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.
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.
Nowadays GH has more sizes by WB continues to beat them in price and performance.
It’s highway robbery what GH charges for the crap they provide. I can highly recommend WarpBuild for Mac (and Linux) runners.
No matter what I did, every time I touched our CI pipeline code I could be sure to run into yet another Gitlab bug.
Oh and turns out GitHub also has that now: https://github.blog/changelog/2025-09-18-actions-yaml-anchor...
UPDATE: okay they botched it https://frenck.dev/github-actions-yaml-anchors-aliases-merge...
There's been years of discussion about ways to fix it with nothing moving forward.
https://gitlab.com/gitlab-org/gitlab/-/issues/263401
And the most recent tracking issue:
fun video on it: https://www.youtube.com/watch?v=E3_95BZYIVs
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.
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.
So, like I said, the question for you is whether that $140/month of service is worth that money to you, or can you find a better priced alternative, or build something that costs less yourself.
My guess is that once you think about this some more you will decide it is worth it, and probably spend some time trying to drive down your minutes/month a bit. But at $140 a month, how much time is that worth investing?
Running workers ourselves was the last resort, we tried everything else but it was impossible to get fast (and consistent) build times otherwise.
In a way we are now going to get charged for Github's poor execution on Actions.
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.
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.
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.
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.
Create/start/stop/terminate EC2.
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.
Using GitHub actions to coordinate the Valhalla builds was a nice-to-have, but this is a deal-breaker for my pull request workflows.
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
This is like if Dropbox started charging you money for the files you have stored on your backup hard drives.
... 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.
If its the price of runs, then its not always running.
If its price of the agent to exist, then thats not paying per runs- then you’re right that people tend to leave their runners online 24/7- but I’ve never worked anywhere that had workers building 24/7.
But other alternatives exist as well, like Sourcehut: https://sr.ht/
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.
This is going to be the downfall of GA
Charging "more than nothing" is certainly not what I would call maximizing revenue, and even it they were maximizing revenue I would still make the same decision to purchase or abandon based on its value to me. Have you interacted with the economy before?
The rest is correct. (Though you can hardlink the installation.) And you can disable self-update, though it does it by default.
That value to you is apparently less than $140/mo. Find the number you’re comfortable with and then move away from GH Actions if it’s less than $140.
More than 10 years of running my own CI infra with Jenkins on top. In 2023 I gave up Jenkins and paid for BuildKite. It’s still my hardware. BuildKite just provides the “services” I described earlier. Yet I paid them a lot of money to provide their services for me on my own hardware. GH actions, even while free, was never an option for me. I don’t like how it feels.
This is probably bad for GitHub but framing it as “charging me for my hardware” misses the point entirely.
Nice profit margin…
So they make CI a bit cheaper but a future migration to Forgejo harder.
In fact they could easily pull off some typical sleazy Microsoft bullshit and eventually make it a shit ton harder to migrate out of GitHub once you migrated back in.
I don’t know if that’s actually why they’re doing this, but it sounds plausible.
Now, if you are already looking at migrating, its also potentially a kick in the butt to do it now. But if you aren’t, the path of least resistance—or at least, the path of least present recurring cost—is a path to a greater degree of lock-in.
Where do you live that that seems like a bad idea?
People would be better served by not expecting anything different from Microsoft. As you say yourself, this is how they roll.
> The only learning to take away is never ever use anything from the big tech companies
Do you even believe in this yourself? Not being dependent on them would be a good start.
- 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.
and you expect it to stay this way?
The first checks I setup are build and test. The rest is “extra”.
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.
- 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
This is not uncommon in some orgs - less number of concurrent runners, slow builds, loads of jobs because of automation or how hooks for the runners are setup.
In the context of discussion that doesn't matter, OP's point distills to that they use minimum of 720 hours / month of orchestration time or some multiple of that on self hosted runners running 24x7.
Github will now charge $84 extra per month for single self-hosted runner running 24x7 - i.e. that is the cost for 43,200 build minutes for only their orchestration alone.
In a more typical setup that is equivalent to say 5 self-hosted running running ~4.5 hours a day(i.e 144/hours/runner/month)
Either way, we will likely pay 8-hours4-pipelines5-days=160 hours per week, just shy of 168-hours for true 24/7. This currently costs $0 just for context.
And trust me, they are running a lot of public and private repositories.
And there are many more orgs and govs throughout Europe doing similar things because there's a (growing) zeitgeist here that the Trump administration nor any American SaaS company can be trusted. This started, by the way, after Microsoft suspended the ICJ from using Microsoft 365 on orders from the White House.
What color are you?
I'm sure I can find a company that supports ethnostates if you need that for your next project.
Nothing kills morale faster than wrenching on the unreliable piece of infrastructure everyone hates. Every time I see an alert in slack github is having issues with actions (again) all I think is, "I'm glad that isn't me" and go about my day
Listen to webhooks for new commits + PRs, and then use the commit status API to push statuses: https://docs.github.com/en/rest/commits/statuses?apiVersion=...
Maybe it's bad business dealing with lots of non-standardized external hosts, and it drags you down.
Maybe people are abusing the free orchestration to do non-CI stuff and they're compromising legitimate users.
Look, I understand it's frustrating to some consumers. However, it's not irrational from GitHub's point of view.
It used to suprise me that people saw cool tech from Microsoft (like VSCode) and complain about it.
I now see the first innings of a very silly game Microsoft are going to start playing over the next few years. Sure, they are going to make lots of money, but a whole generation of developers are learning to avoid them.
Thanks for trying to warn us old heads!
Post statuses, and add rulesets to require those statuses before a PR can be merged. The step after that is to lock out pushing to the branch entirely and perform the integration externally but that has its own challenges.
> My guess is that once you think about this some more you will decide it is worth it, and probably spend some time trying to drive down your minutes/month a bit. But at $140 a month, how much time is that worth investing?
It's $140 right now. And if they want to squeeze you for cents worth of CPU time (because for artifact storage you're already paying separately), they *will* squeeze harder.
And more importantly *RIGHT NOW* it costs more per minute than running decent sized runner!
> I would still make the same decision to purchase or abandon based on its value to me.
Scheduling jobs, actually getting them running, is virtually instant with GitLab but it's slow AF for GitHub for no discernable reason.
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.
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.
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.
I have seen this sentiment more and more, which is welcome to me as it’s a drum I have been banging for 15 years.
I have never had so many empathetic conversations than I have recently.
I'd happily pay a fixed monthly fee for this service, as I already do for GitHub.
The problem here is that this is like a grocery store charging me money for every bag I bring to bag my own groceries.
> But at $140 a month, how much time is that worth investing?
It's not $140/month. It's $140/month today, when my company is still relatively small and it's just me. This cost will scale as my company scales, in a way that is completely bonkers.
Everybody now is like "Hey, we can take something like Kubernetes which is open source and is backed by a worldwide community, and you know like OpenStack which is open source and is backed by a worldwide community and we can build our own computing platform and deploy services and online communities and stuff on top of that"
And I was like "Wait, you guys are realizing that NOW?!? I've been an activist and part of a movement urging you all to try and be less dependent on US Big Tech and focus more on decentralization for YEARS"
Like you I am really happy things seem to get rolling now, though :)
Contrast with a declarative system like github actions: "I would like an immutable environment like this, and then perform X actions and send the logs/report back to the centralized single pane of glass in github". Google's "cloud run" product is pretty good in this regard as well. Sure, developers can add foot guns to your GHA/Cloud Run workflow, but since it is inherently git-tracked, you can simply revert those atomically.
I used Jenkins for 5-7 years across several jobs and I don't miss it at all.
Maybe they can market it as the Github Actions corkage fee
If it is so easy why don’t you write your own orchestrator to run jobs on the hardware you own?
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.
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.
This is an odd take because you're completely discounting the value of the orchestration. In your grocery store analogy, who's the orchestrator? It isn't you.
but realistically, publishing a web page is practically free. you could be sending 100x as much data and I would still be laughing all the way to the bank
If you think that's easy, do it for me. I have some projects to migrate, give me the link of your service.
For scheduled work, cron + a log sink is fine, and for pull request CI there's plenty of alternatives that don't charge by the minute to use your own hardware. The irony here, unfortunately, is that the latter requires I move entirely off of GitHub now.