It is us, developers, who convinced our management to purchase GitHub Enterprise to be our forge. We didn't pay any heed to the values of software freedom. A closed source, proprietary software had good features. We saw that and convinced our management to purchase it. Never mind what cost it would impose in the future when the good software gets bad owners. Never mind that there were alternatives that were inferior but were community-developed, community-maintained and libre.
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?
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.
Takes like these do not account for the value you gained by using the software in the meantime. Here are 2 scenarios:
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.
> A purist approach like in scenario 1 leaves everyone poor.
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.
or alternative hire right people that know what they are doing and don’t need a whole lot of junk to work on and deploy. I have been coding 31 years now and don’t have the slighest clue why anyone would ever need a “github action”
I really enjoy how they list the price PER MINUTE to make it sound like this isn't absurdly expensive. A lot of people leave their self-hosted runners running 24/7 because, after all, they're self-hosted.
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...
How can they charge for something self hosted per minute? Thats very weird to me. If I run the software I should pay a single time only, if I don't own it then why self-host im the first place?
Maybe this is designed to scare people away from self-hosting altogether?
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.
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.
OP means to say he has many jobs in the merge queue that the runners are always busy 24/7.
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)
If you have a lot of not very time sensitive jobs, e.g. large merge trains, it was reasonable to have a not very fast runner run close to full utilization. Now that you'd pay by the run-minute, it'll be cheaper to move to a faster runner and run it at 10%.
I guess some people just always have something running since it's owned hardware. Daily builds of popular OSS projects or constant vuln scans or whatever?
$1k per year if you run an action 24/7. How many minutes per month do you actually use? How does that compare to the cost of the machines being used as runners?
The real mistake was GH not charging anything for self-hosted runners in the first place, setting an expectation.
Personally, I quite liked GitLab CI when I used it circa 2021-23. Just now I did a quick search and found this article^1 suggesting (even before this GH pricing change) Gitlab CI may be a better choice than Github Actions.
I LOVE gitlab, but their new pricing is absurd. It feels like they are trying to shovelware their AI stuff. Their cheapest plan is more than 7x the cost of github, AND more expensive than github enterprise! And thats on the _cheapest_ non free gitlab plan.
If you self host gitlab entirely, you can't even get branch/force-push protection. If they could bring their pricing to even just 2x github by having a NON-AI plan, I would purchase again in a heartbeat.
I had to go check to see what their pricing was, and I couldn't believe it. The base tier was $4/month, now that tier is gone and the premium tier is 2x what it used to be only 5 years ago.
GitLab CI is _excellent_. Github Actions has come a long way, but a few years back it was absolutely painful working with GA when I had GitLab CI for reference.
used to self-host gitlab CI runners around the same year also for our long running CI's due to db migrations + prepared data loading for tests.
we rent 7*4$ VPS, install gitlab CI runners on them, saving us from hundreds $$$ per month and 45mins/merge (with test running on main branch only) to 7*4$/month and 7-9mins/commit (yes, we run full test on each commit and let gitlab auto-cancel older one).
with bonus: FE team get live version of their changes on each MR.
* its 7 VPS because we separated the tests by modules and we have 7 major modules.
* edit: formatting
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.
My ready example of a GitLab pain point is parallel matrix job names include the matrix variables and quite easily, in complex configurations, exceed the static 255 character limit of job names, preventing job creation/execution.
There's been years of discussion about ways to fix it with nothing moving forward.
I have fond memories of using GitLab CI in 2018–2019 and I'm still pissed GitHub didn't just life and shift that kind of a model. Not sure about the particular issues you're running into but I remember GitLab supporting a lot of the YAML features missing in GitHub like anchors in order to build/compose stuff.
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.
So, let me get this straight, the "platform fee" is baked into the runner cost, but, their cheapest runner is the _same price_ as the platform fee? So its the same price to have them run it vs have me run it?
- 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.
Reminds me of a customer that had in their contract requirements GHz amount so after we won the contract we digged out some old P4 based Xeons (everything after for a long time had lower clocks) and they got their stuff ran on old junk because it would be breach of contact not to.
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.
GitHub has still been managing the orchestration and monitoring of runs that you run on your own (or other cloud) hardware. They have just decided that they are no longer going to do this for free.
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.
As a solo Founder who recently invested in self-hosted build infrastructure because my company runs ~70,000 minutes/month, this change is going to add an extra $140/month for hardware I own. And that's just today; this number will only go up over time.
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.
But it is not for hardware you own. It is for the use of GutHubs coordinators, which they have been donating the use of to you for free. They have now decided that that service is something they are going to charge for. Your objection to GitHub "extracting usage-based rent from me" seems to ignore that you have been getting usage of their hardware for free up to now.
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?
No. It is not worth a time-scaled cost each month for them to start a job on my machines and store a few megabytes of log files.
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.
> The problem here is that this is like a grocery store charging me money for every bag I bring to bag my own groceries.
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.
so they are selling cent of their CPU time for a minute's worth
> 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 get the frustration. And I’m no GitHub apologist either. But you’re not being charged for hardware you own. You’re being charged for the services surrounding it (the action runner/executor binary you didn’t build, the orchestrator configurable in their DSL you write, the artefact and log retention you’re getting, the plug-n-play with your repo, etc). Whether or not you think that is a fair price is beside the point.
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.
Yeah, I'm no GitHub apologist, but I'll be one in this context. This is actually a not-unreasonable thing to charge for. And a price point that's not-unreasonable.
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
I run about 1 action a day taking 18h running on 2 runners
One being self hosted 24gb ram 8 core ARM vps and one being a 64gb 13900k x86 dedicated server
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
> They have just decided that they are no longer going to do this for free.
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?
Sure, but that shouldn't be a time-dependent charge. If my build takes an hour to build on GH's hardware, sure thing, charge me for that time. But if my build takes an hour to build on _my_ hardware, then why am I paying GH for that hour?
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.
The runner sends progress info, polls for jobs and so on. The runners don't have to be accessible from GitHub, they just needs general internet access (like through a NAT device).
Because they know Forgejo is starting to get attention from major players and thus becoming competitive, and hosting your own CI infrastructure will make completely moving away from GitHub all that easier - If you don't really care about the metadata all it pretty much takes is moving git repositories with their history.
Or shortly summarized: lock in through pricing.
Pretty sure this will explode straight in their faces though. And pretty damn hard.
Not sure why you think forgejo is competition and not Gitlab.
> 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
Where does GitHub even make most of their money? Their compliance posture makes them a non-starter for any regulated industries (which is atypical for a Microsoft property, generally MS is the market leader for compliance in all of their products).
Representatives from the Dutch government recently had a chat with representatives from Forgejo because they are quite interested in migrating their SCM infrastructure from Github to Forgejo.
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.
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 :)
How can you lock in through charging money?
Seems it’s like the opposite and they are charging because people are already locked in and they can or am I misreading your comment?
Microsoft "suddenly" does not seem to want you to run your own CI, which is a key part of running your own SCM. And this decision miraculously happens the moment a lot of big orgs are looking at self-hosting a cost effective (because open source) near 1:1 alternative to GitHub (=Forgejo).
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.
If you make running your own runners as expensive as running on Github's runners on top of the cost of actually hosting the runners, then if you are currently on Github and not able to migrate off immediately, the price conscious decision is to migrate runners into Github. But then, its even harder if you ever decide to migrate your whole operation out.
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.
The idea is that they let you stay locked in for free. They dissuade people from making their CI pipeline forge-agnostic by charging you if you if you take steps to not be dependent on them. This means they can keep charging in other areas, and keep people in GitHub so that it stays dominant. Dominance is something that can be used to keep people in the Microsoft ecosystem, keep GitHub as the place where code goes so they have training data for LLMs, and dominance can simply be cashed in down the line.
I don’t know if that’s actually why they’re doing this, but it sounds plausible.
Because GHA was stagnant and expensive and multiple services like https://www.warpbuild.com/ popped up, with better performance and much lower price. Looks like they ate enough of GH’s lunch…
Hey, WarpBuild founder here.
While it makes it harder for us to communicate this, we're still, we're still faster and cheaper even after the $0.002/min self hosting tax.
Overall costs go up for everyone but we remain the better option.
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.
One problem is that GitHub Actions isn't good. It's not like you're happily paying for some top tier "orchestration". It's there and integrated, which does make it convenient, but any price on this piece of garbage makes switching/self-hosting something to seriously consider.
Github being a single pane of glass for developers with a single login is pretty powerful. Github hosting the runners is also pretty useful, ask anyone who has had to actually manage/scale them what their opinion is about Jenkins is. Being a "Jenkins Farmer" is a thankless job that means a lot of on-call work to fix the build system in the middle of the night at 2am on a Sunday. Paying a small monthly fee is absolutely worth it to rescue the morale of your infra/platform/devops/sre team.
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
I run Jenkins (have done so at multiple jobs) and it's totally fine. Jenkins, like other super customizable systems, is as reliable or crappy as you make it. It's decent out of the box, but if you load it down with a billion plugins and whatnot then yeah it's going to be a nightmare to maintain. It all comes down to whether you've done a good job setting it up, IMO.
Lots of systems are "fine" until they aren't. As you pointed out, Jenkins being super-customizable means it isn't strongly opinionated, and there is plenty of opportunity for a well-meaning developer to add several foot-guns, doing some simple point and click in the GUI. Or the worst case scenario: cleaning up someone elses' Jenkins mess after they leave the company.
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.
Yeah, it seems like a half-assed version of what Jenkins and other tools have been doing for ages. Not that Jenkins is some magical wonderful tool, but I still haven't found a reasonable way to test my actions outside of running them on real Github.
Everyone who has Actions built into their workflow now has to go change it. Microsoft just conned a bunch more people with the same classic tech lock-in strategy they've always pursued, people are right to be pissed. The only learning to take away is never ever use anything from the big tech companies, even if it seems easier or cheaper right now to do so, because they're just waiting for the right moment to try and claw it back from you.
Yep, this mostly works fine (and can be necessary already in some setups anyway), the main issues are that each status update requires an API call (over v3, AFAIK updating statuses was never added to v4) so if you have a lot of statuses and PR traffic you can hit rate limits annoyingly quickly, and github will regularly fail to deliver or forward webhooks (also no ordering guarantees).
We have internal integrations with GitHub webhooks that will hit our server to checkout a branch, run some compute, and then post a comment on the thread. Not sure if you can integrate something like that to help block a PR from being merged like Actions CI checks, but you can receive webhooks and make API calls for free (for now). Would definitely result in some extra overhead to implement outside of Actions for some tasks.
> Not sure if you can integrate something like that to help block a PR from being merged like Actions CI checks
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.
Because they make money from charging way over cost price for per-minute CI runners, and they don't want people using much much cheaper alternative providers.
They don't care about people actually self-hosting. They care about people "self hosting" with these guys:
If you do it all, you can optimize the whole supply chain. Maybe you can put some expensive capacity you built to use and leverage it when otherwise impossible, etc.
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.
no, I'd cut the monthly seat cost and grow my user base to include more low-volume devs
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
Companies like Ubicloud gives hosted actions faster and far more cheaper (5-10x) than Microsoft itself.
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.
Why not just self-host Gitea? CI/CD, runners, all included. Freedom. Don't have the time do keep it going and safe? No worries, folks like https://federated.computer do that.
Postman pulled this same stunt in 2022, limiting how many times you can run your own API class from your machine. To this day I've never reconciled with them or their product management decisions.
Your pricing page seems to have changed intra-day. but now it's about $400ish.
30 users + 500 builds.
However I don't know what counts as a build, since a typical commit to an open PR uses 10 GH runner machines simultaneously doing odd jobs like integration tests, releases, deploys, etc...
They're charging you for orchestration, log storage, artifact storage, continued development of the runner binary itself and features available to self-hosted machines. What would your own machine do without the runner and service it connects to?
I really wanted to like it but the UI always put me off. Also tending to prefer a more open development model these days. Thankfully at least for dev gitea and forgejo have both come a long way and the CI is pretty decent now (though they still dont have a gui workflow builder!).
Microsoft are really sweating GitHub now aren't they? It wouldn't be so bad if it improving but there is certainly a perception that it is costing more for a poorer product, irrespective of the new features they're layering on.
I'm happy to see they're investing in Actions — charging for it should help make sure it continues to work. It's a huge reason Github is so valuable: having the status checks run on every PR, automatically, is great. Even though I'm more of a fan of Buildkite when it comes to configuring the workflows, I still need something to kick them off when PRs change, etc.
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!
This pricing model will continue to incentivize them internally to not fix the hundreds of clearly documented issues that causes CI to be incredibly slow. Everything from their self-inflicted bottlenecking of file transfers to the safe_sleep bug that randomly makes a runner run forever until it times out. All of it now makes them more money
I don't think it makes sense to charge per minute just for logs. If they want to charge for log retention, sure, go ahead. But that is pennies, let's be real.
> charging for it should help make sure it continues to work
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?
Yeah. This is a reaction to providers like blacksmith or self-hosted solutions like the k8s operator being better at operating their very bad runner then them, at cheaper prices, with better performance, more storage and warm caches. The price cut is good, the anticompetitive bit where they charge you to use computers they don't provide isn't. My guess is that either we're all gonna move to act or that one of the SaaS startups sue.
I appreciate being able to pay for a service I rely on. Using self-hosted runners, I previously paid nothing for Github Actions — now I do pay something for it. The price is extremely cheap and seems reasonable considering the benefits I receive. They've shown continued interest in investing in the product, and have a variety of things on their public roadmap that I'm looking forward to (including parallel steps) — https://github.com/orgs/github/projects/4247?pane=issue&item....
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?
Charging by minute might push people toward shorter, noisier and more fragmented pipelines. It feels more like a lever to discourage selfhosting over time.
It's not outrageous money today, but it's a clear signal about where they want CI to live.
GitHub actions are expensive enough that self-hosted was the only real option. I can't imagine this will do anything other than push people from the entire ecosystem.
I assume they want us to pay for their orchestration and also push customers back to using their compute so everything is stickier.
But nothing they've done in the last few years has demonstrated improvement in this area. As the person with both purchasing and final authority on these things in my org, it's hard to stomach.
Given that I can dump hundreds of TBs into the private container registry without paying anything I'm pretty surprised that they now charge for what is basically providing log streaming and retention.
The reason this makes sense, at least for Github, is because the only valid reason to run your own action runners is compliance. And if you are doing it for compliance, price doesn't really matter. You don't really have a choice.
If you've been running your runners on your own infra for cost reasons, you're not really that interesting to the Github business.
Github runners are slow. We're using WarpBuild and they are still cheaper per-minute, even with all the changes Github has made. Then there's the fact that the machines are faster, so we are using fewer minutes.
There are multiple competitors in this space. If you are (or were) paying for Github runners for any reason, you really shouldn't be.
We also use WarpBuild and very happy with the performance gain. This changes nothing except maybe it should signal to WarpBuild to start supporting other providers than Github. We are clearly entering the enshitiffication phase of Github.
Maybe if everything you use is public-cloud-deployed.
Self-hosted runners help bridge the gap with on-prem servers, since you can pop a runner VM inside your infra and give it the connectivity/permissions to do deployments.
This announcement pisses me off, because it's not something related to abuse/recouping cost, since they could impose limits on free plans or whatever.
This will definitely influence me to ensure all builds/deployments are fully bash/powershell scripted without GH Action-specific steps. Actions are a bit of a dumpster fire anyway, so maybe I'll just go back to TeamCity like I used before Actions.
CircleCI does only charge for self-hosted runners generated egress and/or artifact storage:
"Any Network Egress to CircleCI will be charged. At this current time, this includes CircleCI Caches, Workspaces, and Artifacts and will be charged at the normal rate according to your Usage Controls.
The only network traffic that will result in billing is accrued through restoring caches and workspaces, and downloading artifacts to self-hosted runners. Retention of artifacts, workspace, and cache objects will result in billing for storage usage.
Since your builds will not be running on CircleCI's Infrastructure, you will not be charged compute credits"
I think that's fair. In my personal opinion most people started using GitHub Actions because it “came for free with the VCS and/or our MS contract” and it was “good enough for the job”. Now might be a good time to look around at the alternatives again. There is a reason that f.e. CircleCI is doing fully focused CI/CD for 10+ years and is still going strong. Plenty of businesses don’t want to put all their eggs in one (MS) basket, for all kinds of reasons. I guess today one of these reasons became obvious.
They're squeezing their customers after locking in to juice their margins, having become a monopoly/monopsony. This is the classic enshitificaton playbook.
Nobody is locked in (unless they made some incredibly bad decisions) and this is a tiny fee in exchange for a useful service. I’m just baffled by the response to this.
"Here is how platforms die: First, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die."
We are on step 2: then they abuse their users to make things better for their business customers.
Maybe with this "investment" will get an actual solution for Github Actions sh*t version management of actions[1] after just closing the Immutable Actions issue with a "sucks to be you" comment[2]. AI-Native Github action Agentic package management for Copilot /s
It is us, developers, who convinced our management to purchase GitHub Enterprise to be our forge. We didn't pay any heed to the values of software freedom. A closed source, proprietary software had good features. We saw that and convinced our management to purchase it. Never mind what cost it would impose in the future when the good software gets bad owners. Never mind that there were alternatives that were inferior but were community-developed, community-maintained and libre.
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?
> alternatives that were inferior
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.
Have any suggestions to those community-developed and maintained options?
Takes like these do not account for the value you gained by using the software in the meantime. Here are 2 scenarios:
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.
> A purist approach like in scenario 1 leaves everyone poor.
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.
or alternative hire right people that know what they are doing and don’t need a whole lot of junk to work on and deploy. I have been coding 31 years now and don’t have the slighest clue why anyone would ever need a “github action”
AWS code (build|deploy) supports GitHub actions workflow, gitlab does, gitea (codeberg, forgejo) too
The biggest issue is the compatibility, forgejo doesn’t have all the actions available that GitHub does nor some of the same functionality
I really enjoy how they list the price PER MINUTE to make it sound like this isn't absurdly expensive. A lot of people leave their self-hosted runners running 24/7 because, after all, they're self-hosted.
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...
How can they charge for something self hosted per minute? Thats very weird to me. If I run the software I should pay a single time only, if I don't own it then why self-host im the first place?
Maybe this is designed to scare people away from self-hosting altogether?
> For them to do essentially nothing.
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.
They are charging for storage separately already! Why are you lying ?
Lying implies intent, I don't think the person you're replying to is necessarily lying, even though they might be wrong on this specific point.
You can get far bigger VM for that per month. It's ridiculus.
Of course entirely expected after MS buyout, if anything I'm surprised it took that long
Wait.. is this how they're billing it?? Not the duration of runs??
It is duration of runs. He was just highlighting the absurde cost if you were to run it 24/7 like some people with their own self hosted runners do.
I am not understanding something.
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.
OP means to say he has many jobs in the merge queue that the runners are always busy 24/7.
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)
If you have a lot of not very time sensitive jobs, e.g. large merge trains, it was reasonable to have a not very fast runner run close to full utilization. Now that you'd pay by the run-minute, it'll be cheaper to move to a faster runner and run it at 10%.
I guess some people just always have something running since it's owned hardware. Daily builds of popular OSS projects or constant vuln scans or whatever?
$1k per year if you run an action 24/7. How many minutes per month do you actually use? How does that compare to the cost of the machines being used as runners?
The real mistake was GH not charging anything for self-hosted runners in the first place, setting an expectation.
Personally, I quite liked GitLab CI when I used it circa 2021-23. Just now I did a quick search and found this article^1 suggesting (even before this GH pricing change) Gitlab CI may be a better choice than Github Actions.
1. https://medium.com/@the_atomic_architect/github-vs-gitlab-20...
I LOVE gitlab, but their new pricing is absurd. It feels like they are trying to shovelware their AI stuff. Their cheapest plan is more than 7x the cost of github, AND more expensive than github enterprise! And thats on the _cheapest_ non free gitlab plan. If you self host gitlab entirely, you can't even get branch/force-push protection. If they could bring their pricing to even just 2x github by having a NON-AI plan, I would purchase again in a heartbeat.
I had to go check to see what their pricing was, and I couldn't believe it. The base tier was $4/month, now that tier is gone and the premium tier is 2x what it used to be only 5 years ago.
You mean "Protected branches"? Last time I checked that was part of the free tier, and the documentation[0] states the same.
[0]: https://docs.gitlab.com/user/project/repository/branches/pro...
GitLab CI is _excellent_. Github Actions has come a long way, but a few years back it was absolutely painful working with GA when I had GitLab CI for reference.
used to self-host gitlab CI runners around the same year also for our long running CI's due to db migrations + prepared data loading for tests. we rent 7*4$ VPS, install gitlab CI runners on them, saving us from hundreds $$$ per month and 45mins/merge (with test running on main branch only) to 7*4$/month and 7-9mins/commit (yes, we run full test on each commit and let gitlab auto-cancel older one). with bonus: FE team get live version of their changes on each MR.
* its 7 VPS because we separated the tests by modules and we have 7 major modules. * edit: formatting
GitLab CI is quite good. Have been using it for several years.
I can't tolerate it.
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.
My ready example of a GitLab pain point is parallel matrix job names include the matrix variables and quite easily, in complex configurations, exceed the static 255 character limit of job names, preventing job creation/execution.
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:
https://gitlab.com/gitlab-org/gitlab/-/issues/285853
I have fond memories of using GitLab CI in 2018–2019 and I'm still pissed GitHub didn't just life and shift that kind of a model. Not sure about the particular issues you're running into but I remember GitLab supporting a lot of the YAML features missing in GitHub like anchors in order to build/compose stuff.
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...
Absolutely ridiculous. Just absolutely abhorrent and downright abusive move on Microsoft's part.
> abhorrent and downright abusive move
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,
So, let me get this straight, the "platform fee" is baked into the runner cost, but, their cheapest runner is the _same price_ as the platform fee? So its the same price to have them run it vs have me run it?
It's seems like a solid plan to me:
- 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.
Seriously. They're charging me for using MY cpus? Forgejo incoming testing period..
A lot of server software does that. People were paying absurd prices for fast Xeons to save on their Oracle bills.
Reminds me of a customer that had in their contract requirements GHz amount so after we won the contract we digged out some old P4 based Xeons (everything after for a long time had lower clocks) and they got their stuff ran on old junk because it would be breach of contact not to.
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.
It’s not unheard of, similarish to many core licensing schemes. Like mssql.
Not the same thing. The equivalent would be mssql charging by web server connections to it.
Like BYO wine I guess.
Zig's decision to ditch GitHub actions seems remarkably prescient, no?
yes ! i'm actually doing the same as i saw the safe_sleep.sh code on their runners ... insane story ...
Can you elaborate on what you're referring to? Sounds interesting.
https://github.com/actions/runner/issues/3792
fun video on it: https://www.youtube.com/watch?v=E3_95BZYIVs
Wow, that's horrifyingly bad. Like "didn't think about it for more than 30 seconds before committing" bad.
This seems backwards. Why charge for me to run the thing myself instead of them?
GitHub has still been managing the orchestration and monitoring of runs that you run on your own (or other cloud) hardware. They have just decided that they are no longer going to do this for free.
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.
As a solo Founder who recently invested in self-hosted build infrastructure because my company runs ~70,000 minutes/month, this change is going to add an extra $140/month for hardware I own. And that's just today; this number will only go up over time.
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.
But it is not for hardware you own. It is for the use of GutHubs coordinators, which they have been donating the use of to you for free. They have now decided that that service is something they are going to charge for. Your objection to GitHub "extracting usage-based rent from me" seems to ignore that you have been getting usage of their hardware for free up to now.
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?
No. It is not worth a time-scaled cost each month for them to start a job on my machines and store a few megabytes of log files.
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.
> The problem here is that this is like a grocery store charging me money for every bag I bring to bag my own groceries.
Maybe they can market it as the Github Actions corkage fee
> It is not worth a time-scaled cost each month for them to start a job on my machines and store a few megabytes of log files
If it is so easy why don’t you write your own orchestrator to run jobs on the hardware you own?
> The problem here is that this is like a grocery store charging me money for every bag I bring to bag my own groceries.
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.
Do you feel that orchestration runs on a per-minute basis?
As long as they're reserving resources for your job during the period of execution, it does.
Charging people to maintain a row in a database by the minute is top-tier, I agree.
Feel free to launch a competitor!
so they are selling cent of their CPU time for a minute's worth
> 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 get the frustration. And I’m no GitHub apologist either. But you’re not being charged for hardware you own. You’re being charged for the services surrounding it (the action runner/executor binary you didn’t build, the orchestrator configurable in their DSL you write, the artefact and log retention you’re getting, the plug-n-play with your repo, etc). Whether or not you think that is a fair price is beside the point.
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.
feels like a new generation is learning what life is like when microsoft has a lot of power. (tl;dr: they try to use it.)
Feels like listening to Halo generation being surprised MS fucks them over, because they thought they were Good Guys, coz they Made Thing They like
ABuse it.
Yeah, I'm no GitHub apologist, but I'll be one in this context. This is actually a not-unreasonable thing to charge for. And a price point that's not-unreasonable.
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
I run about 1 action a day taking 18h running on 2 runners One being self hosted 24gb ram 8 core ARM vps and one being a 64gb 13900k x86 dedicated server
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
Somewhere around 0.00004$ probably.
Nice profit margin…
> They have just decided that they are no longer going to do this for free.
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.)
> is $0.002/minute a good price for this
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?
You know, one might ask what the base fee of $4k/mo (in my org's case) is covering, if not the control plane?
Unless you're on the free org plan, they're hardly doing it "for free" today…
Exactly this. It’s not like they don’t have plenty of other fees and charges. What’s next, charging mil rates for webhook deliveries?
Sure, but that shouldn't be a time-dependent charge. If my build takes an hour to build on GH's hardware, sure thing, charge me for that time. But if my build takes an hour to build on _my_ hardware, then why am I paying GH for that hour?
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?
> is $0.002/minute a good price for this
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.
Is it polling the runner, or is the runner sending it progress?
The runner sends progress info, polls for jobs and so on. The runners don't have to be accessible from GitHub, they just needs general internet access (like through a NAT device).
Additionally, they could just self-host their code since code is data is a moat.
Because they know Forgejo is starting to get attention from major players and thus becoming competitive, and hosting your own CI infrastructure will make completely moving away from GitHub all that easier - If you don't really care about the metadata all it pretty much takes is moving git repositories with their history.
Or shortly summarized: lock in through pricing.
Pretty sure this will explode straight in their faces though. And pretty damn hard.
Not sure why you think forgejo is competition and not Gitlab.
> 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 don't think Forgejo is competitive in the markets GitHub makes most of their money from, nor does it seem Forgejo developers want it to be.
Where does GitHub even make most of their money? Their compliance posture makes them a non-starter for any regulated industries (which is atypical for a Microsoft property, generally MS is the market leader for compliance in all of their products).
Given that a lot of places that deal with money use them, I find your comment quite interesting and would like to learn more :)
Representatives from the Dutch government recently had a chat with representatives from Forgejo because they are quite interested in migrating their SCM infrastructure from Github to Forgejo.
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.
Can confirm.
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.
Sounds familiar!
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 :)
The Dutch government represenrative mentioned contacts with French colleagues about this also.
How can you lock in through charging money? Seems it’s like the opposite and they are charging because people are already locked in and they can or am I misreading your comment?
Microsoft "suddenly" does not seem to want you to run your own CI, which is a key part of running your own SCM. And this decision miraculously happens the moment a lot of big orgs are looking at self-hosting a cost effective (because open source) near 1:1 alternative to GitHub (=Forgejo).
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.
If you make running your own runners as expensive as running on Github's runners on top of the cost of actually hosting the runners, then if you are currently on Github and not able to migrate off immediately, the price conscious decision is to migrate runners into Github. But then, its even harder if you ever decide to migrate your whole operation out.
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.
The idea is that they let you stay locked in for free. They dissuade people from making their CI pipeline forge-agnostic by charging you if you if you take steps to not be dependent on them. This means they can keep charging in other areas, and keep people in GitHub so that it stays dominant. Dominance is something that can be used to keep people in the Microsoft ecosystem, keep GitHub as the place where code goes so they have training data for LLMs, and dominance can simply be cashed in down the line.
I don’t know if that’s actually why they’re doing this, but it sounds plausible.
I would keep repos on GH but use Jenkins though.
My view is it's their platform but it seems like a scummy move to tax selfhosters.
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
Democratic organization is a strike?
Where do you live that that seems like a bad idea?
Inclusivity and democratic governance of a project is a strike to you? Seems like perhaps your hat is showing...
Inclusive is strike 1?
What color are you?
I'm sure I can find a company that supports ethnostates if you need that for your next project.
Because GHA was stagnant and expensive and multiple services like https://www.warpbuild.com/ popped up, with better performance and much lower price. Looks like they ate enough of GH’s lunch…
Hey, WarpBuild founder here. While it makes it harder for us to communicate this, we're still, we're still faster and cheaper even after the $0.002/min self hosting tax.
Overall costs go up for everyone but we remain the better option.
They still run the whole orchestration.
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.
One problem is that GitHub Actions isn't good. It's not like you're happily paying for some top tier "orchestration". It's there and integrated, which does make it convenient, but any price on this piece of garbage makes switching/self-hosting something to seriously consider.
Github being a single pane of glass for developers with a single login is pretty powerful. Github hosting the runners is also pretty useful, ask anyone who has had to actually manage/scale them what their opinion is about Jenkins is. Being a "Jenkins Farmer" is a thankless job that means a lot of on-call work to fix the build system in the middle of the night at 2am on a Sunday. Paying a small monthly fee is absolutely worth it to rescue the morale of your infra/platform/devops/sre team.
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
I run Jenkins (have done so at multiple jobs) and it's totally fine. Jenkins, like other super customizable systems, is as reliable or crappy as you make it. It's decent out of the box, but if you load it down with a billion plugins and whatnot then yeah it's going to be a nightmare to maintain. It all comes down to whether you've done a good job setting it up, IMO.
Lots of systems are "fine" until they aren't. As you pointed out, Jenkins being super-customizable means it isn't strongly opinionated, and there is plenty of opportunity for a well-meaning developer to add several foot-guns, doing some simple point and click in the GUI. Or the worst case scenario: cleaning up someone elses' Jenkins mess after they leave the company.
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.
Yeah, it seems like a half-assed version of what Jenkins and other tools have been doing for ages. Not that Jenkins is some magical wonderful tool, but I still haven't found a reasonable way to test my actions outside of running them on real Github.
Everyone who has Actions built into their workflow now has to go change it. Microsoft just conned a bunch more people with the same classic tech lock-in strategy they've always pursued, people are right to be pissed. The only learning to take away is never ever use anything from the big tech companies, even if it seems easier or cheaper right now to do so, because they're just waiting for the right moment to try and claw it back from you.
> Microsoft just conned a bunch more people with the same classic tech lock-in strategy they've always pursued, people are right to be pissed
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.
Can someone share a Github bot that doesn't depend on actions?
I mean maybe https://github.com/rust-lang/bors is enough to fully replace Github Actions? (not sure)
You can use webhooks to replace Github Actions: https://docs.github.com/en/webhooks/about-webhooks
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=...
Yep, this mostly works fine (and can be necessary already in some setups anyway), the main issues are that each status update requires an API call (over v3, AFAIK updating statuses was never added to v4) so if you have a lot of statuses and PR traffic you can hit rate limits annoyingly quickly, and github will regularly fail to deliver or forward webhooks (also no ordering guarantees).
We have internal integrations with GitHub webhooks that will hit our server to checkout a branch, run some compute, and then post a comment on the thread. Not sure if you can integrate something like that to help block a PR from being merged like Actions CI checks, but you can receive webhooks and make API calls for free (for now). Would definitely result in some extra overhead to implement outside of Actions for some tasks.
> Not sure if you can integrate something like that to help block a PR from being merged like Actions CI checks
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.
Because charging you brings more profits than not charging you.
Because they make money from charging way over cost price for per-minute CI runners, and they don't want people using much much cheaper alternative providers.
They don't care about people actually self-hosting. They care about people "self hosting" with these guys:
https://github.com/neysofu/awesome-github-actions-runners
The scheduler isn’t free, I always wondered how the financials work on this one. Turns out they didn’t ;)
Anyway, GitHub actions is a dumpster fire even without this change.
I develop software, I also test and run it. All in my machines.
But you (yes, you personally) have to collect the results and publish them to a webpage for me. For free.
Would you make this deal?
It sounds like a bad deal right?
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
If you do it all, you can optimize the whole supply chain. Maybe you can put some expensive capacity you built to use and leverage it when otherwise impossible, etc.
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.
This is actually about abusing Microsoft's market position to eliminate competitors in related markets, plain & simple.
But I get to read all your code and use it for training my AI, right?
My projects are public anyway. If you respect the license and make the AI comply to valid license reuse, I'm game.
if you were paying me a monthly license fee for each developer working on your repos, I'd probably consider it
What happens if I am, and now my developers suddenly start to produce changes much faster? Like, one developer now produces the volume of five.
Would you keep charging the same rate per head?
no, I'd cut the monthly seat cost and grow my user base to include more low-volume devs
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
Publishing the page is only the last step. It's orchestrating the stuff THEN publishing it.
If you think that's easy, do it for me. I have some projects to migrate, give me the link of your service.
Because they host the artifacts, logs, and schedule jobs which run on your runners, I assume.
Then why do they charge by the minute instead of gigabytes and number of events?
they charge you for artifacts and logs separately, already
> Coming soon: Simpler pricing and a better experience for GitHub Actions
i think it should be illegal or otherwise extremely damaging to do this kind of thing
Come on, editorializing the post title is against HN guidelines, but making it illegal is a bit too harsh.
Didn't see it mentioned yet but I like gitea and it's runner. It's all in Go so very low overhead.
https://docs.gitea.com/usage/actions/act-runner
Also supported by Forgejo actions: https://forgejo.org/docs/latest/user/actions/quick-start/ - both based on https://github.com/nektos/act
sadly they, afaik, do not implement the permission model. So no way to control the token permissions.
(plz correct me if i'm wrong)
Companies like Ubicloud gives hosted actions faster and far more cheaper (5-10x) than Microsoft itself.
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.
it's rather egregious that it is a "per minute" tax rather than a $0.002 per job.
Why not just self-host Gitea? CI/CD, runners, all included. Freedom. Don't have the time do keep it going and safe? No worries, folks like https://federated.computer do that.
Forgejo might be a better option for that now.
I would remind everyone that lots of free solutions like Forgejo exist with much better security posture.
This seems totally unreasonable. How can they justify charging you based on usage when it's running on and using your resources?
Postman pulled this same stunt in 2022, limiting how many times you can run your own API class from your machine. To this day I've never reconciled with them or their product management decisions.
Well sounds like $40 per month more for us. Looked at CircleCI pricing, and mostly because of HOW they charge, it would be $3000, so Github it is.
Is that because you have loads of users? (curious CircleCI employee here)
Your pricing page seems to have changed intra-day. but now it's about $400ish.
30 users + 500 builds.
However I don't know what counts as a build, since a typical commit to an open PR uses 10 GH runner machines simultaneously doing odd jobs like integration tests, releases, deploys, etc...
This is a serious issue. How is it possible for GitHub/Microsoft to charge me for using my own machine as a self-hosted GitHub Actions runner?
They're charging you for orchestration, log storage, artifact storage, continued development of the runner binary itself and features available to self-hosted machines. What would your own machine do without the runner and service it connects to?
For the same reason they charge you for running Word, even though you're the one who has to write, I guess?
They still have to manage state between their servers and yours.
I'll be investigating gitlab tomorrow
Have used all of the big 4 forges in anger over the last decade. GitLab isn't perfect, but I'd take it over GitHub any day of the week.
it charges you to use the platform features that enable your use of self-hosted runners
More than 6 years users of OneDev (onedev.io).
- Git repo - Ticketing, Kaban - Full helpdesk - Complete and full CI/CD - everything links via custom workflow - self hosted
I still dont know why everyone hasn't switch yet to that banger.
I really wanted to like it but the UI always put me off. Also tending to prefer a more open development model these days. Thankfully at least for dev gitea and forgejo have both come a long way and the CI is pretty decent now (though they still dont have a gui workflow builder!).
So Microsoft is slowly killing it. Not surprising.
Microsoft are really sweating GitHub now aren't they? It wouldn't be so bad if it improving but there is certainly a perception that it is costing more for a poorer product, irrespective of the new features they're layering on.
I'm happy to see they're investing in Actions — charging for it should help make sure it continues to work. It's a huge reason Github is so valuable: having the status checks run on every PR, automatically, is great. Even though I'm more of a fan of Buildkite when it comes to configuring the workflows, I still need something to kick them off when PRs change, etc.
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!
This pricing model will continue to incentivize them internally to not fix the hundreds of clearly documented issues that causes CI to be incredibly slow. Everything from their self-inflicted bottlenecking of file transfers to the safe_sleep bug that randomly makes a runner run forever until it times out. All of it now makes them more money
I don't think it makes sense to charge per minute just for logs. If they want to charge for log retention, sure, go ahead. But that is pennies, let's be real.
> charging for it should help make sure it continues to work
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?
Yeah. This is a reaction to providers like blacksmith or self-hosted solutions like the k8s operator being better at operating their very bad runner then them, at cheaper prices, with better performance, more storage and warm caches. The price cut is good, the anticompetitive bit where they charge you to use computers they don't provide isn't. My guess is that either we're all gonna move to act or that one of the SaaS startups sue.
I appreciate being able to pay for a service I rely on. Using self-hosted runners, I previously paid nothing for Github Actions — now I do pay something for it. The price is extremely cheap and seems reasonable considering the benefits I receive. They've shown continued interest in investing in the product, and have a variety of things on their public roadmap that I'm looking forward to (including parallel steps) — https://github.com/orgs/github/projects/4247?pane=issue&item....
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 price is extremely cheap
and you expect it to stay this way?
> and seems reasonable considering the benefits I receive.
> I would still make the same decision to purchase or abandon based on its value to me.
Charging by minute might push people toward shorter, noisier and more fragmented pipelines. It feels more like a lever to discourage selfhosting over time.
It's not outrageous money today, but it's a clear signal about where they want CI to live.
GitHub actions are expensive enough that self-hosted was the only real option. I can't imagine this will do anything other than push people from the entire ecosystem.
I assume they want us to pay for their orchestration and also push customers back to using their compute so everything is stickier.
But nothing they've done in the last few years has demonstrated improvement in this area. As the person with both purchasing and final authority on these things in my org, it's hard to stomach.
Atlassian recently did this with BitBucket self hosted runners. Is there a CI/CD cartel or something?
Given that I can dump hundreds of TBs into the private container registry without paying anything I'm pretty surprised that they now charge for what is basically providing log streaming and retention.
If they charge me for my self-hosted runner i will just move to Gitlab. This is theft..or let's say this is microsoft.
Geez. This would've been much more agreeable had they bothered to fix years-old open bugs with self-hosted runners
this is the third article about it, we know, good times are over, will start migrating towards something else
It definitely adds to frustration for some people; this can not be denied.
don’t lie you’ll just bitch and moan and keep using it anyway
The reason this makes sense, at least for Github, is because the only valid reason to run your own action runners is compliance. And if you are doing it for compliance, price doesn't really matter. You don't really have a choice.
If you've been running your runners on your own infra for cost reasons, you're not really that interesting to the Github business.
Github runners are slow. We're using WarpBuild and they are still cheaper per-minute, even with all the changes Github has made. Then there's the fact that the machines are faster, so we are using fewer minutes.
There are multiple competitors in this space. If you are (or were) paying for Github runners for any reason, you really shouldn't be.
Thanks for the WarpBuild love!
Performance is the primary lever to pay less $0.002/min self hosting tax and we strive to provide the best performance runners.
We also use WarpBuild and very happy with the performance gain. This changes nothing except maybe it should signal to WarpBuild to start supporting other providers than Github. We are clearly entering the enshitiffication phase of Github.
thanks for the love! we are actively considering supporting other providers.
Not just compliance, we run CI against machines that they don’t offer, like those with big GPUs.
I needed arm64 workers, because x86 would take ~25 minutes to do a build.
if it's useful, they do actually have arm workers now for linux and mac: https://github.com/actions/runner-images/tree/main?tab=readm...
TIL amd64 is also called x86-64.
They have these now.
Only for public repos though - if you're in an org with private repositories you don't get access to them (yet).
You do, you just have to set them up at the organization level. Windows/Linux/macOS are all available.
Maybe if everything you use is public-cloud-deployed.
Self-hosted runners help bridge the gap with on-prem servers, since you can pop a runner VM inside your infra and give it the connectivity/permissions to do deployments.
This announcement pisses me off, because it's not something related to abuse/recouping cost, since they could impose limits on free plans or whatever.
This will definitely influence me to ensure all builds/deployments are fully bash/powershell scripted without GH Action-specific steps. Actions are a bit of a dumpster fire anyway, so maybe I'll just go back to TeamCity like I used before Actions.
Performance and data locality.
You can throw tons of cores and ram locally at problems without any licensing costs.
Your data may be local, makes sense to work with it locally.
Are there bring-your-own-agent CI platforms that don't have pricing structures like this? Buildkite and CircleCI do.
CircleCI does only charge for self-hosted runners generated egress and/or artifact storage:
"Any Network Egress to CircleCI will be charged. At this current time, this includes CircleCI Caches, Workspaces, and Artifacts and will be charged at the normal rate according to your Usage Controls.
The only network traffic that will result in billing is accrued through restoring caches and workspaces, and downloading artifacts to self-hosted runners. Retention of artifacts, workspace, and cache objects will result in billing for storage usage.
Since your builds will not be running on CircleCI's Infrastructure, you will not be charged compute credits"
https://support.circleci.com/hc/en-us/articles/2064321965685...
I think that's fair. In my personal opinion most people started using GitHub Actions because it “came for free with the VCS and/or our MS contract” and it was “good enough for the job”. Now might be a good time to look around at the alternatives again. There is a reason that f.e. CircleCI is doing fully focused CI/CD for 10+ years and is still going strong. Plenty of businesses don’t want to put all their eggs in one (MS) basket, for all kinds of reasons. I guess today one of these reasons became obvious.
Disclaimer: I work at CircleCI.
gitlab
I guess Jenkins gets back in the game.
related: https://news.ycombinator.com/item?id=46291156
This customer will be leaving GitHub action runners for punishing self-hosting.
GitLab CI and others seem to be perfectly serviceable.
Gitlab here I come
it looks ms wants to kill all their IP, xbox, windows, now github
blanket 30% profit margin is great right?
Oh great. I finally get used to GitHub Actions after Travis CI shat the bed, and now I have to find something else.
Thanks, enshittification.
Hey man, that's not fair. They cannot enshittify what has always been shit to begin with.
Oh you sweet summer child
What part of this is “enshittification”? It’s just a company starting to charge for a formerly free service. Hardly seems like that aggressive a move.
They're squeezing their customers after locking in to juice their margins, having become a monopoly/monopsony. This is the classic enshitificaton playbook.
Nobody is locked in (unless they made some incredibly bad decisions) and this is a tiny fee in exchange for a useful service. I’m just baffled by the response to this.
From https://www.wired.com/story/tiktok-platforms-cory-doctorow/
"Here is how platforms die: First, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die."
We are on step 2: then they abuse their users to make things better for their business customers.
It is not abuse to charge what amounts to a relatively small fee for a useful service.
Maybe with this "investment" will get an actual solution for Github Actions sh*t version management of actions[1] after just closing the Immutable Actions issue with a "sucks to be you" comment[2]. AI-Native Github action Agentic package management for Copilot /s
[1] https://nesbitt.io/2025/12/06/github-actions-package-manager... [2] https://github.com/github/roadmap/issues/592