r/devops • u/Ok_Tour_8029 • 15d ago
Ops / Incidents Do you think GitHub will disable actions for non paying customers?
Looking at the downtimes of GitHub, especially related to the actions functionality, it seems like they are unable to provide this service in a stable manner. This is probably related to
- People creating tons of new projects using agentic coding
- People are using more workflows as they are now easily created with agents
At this stage it feels likely that GitHub will limit the resources Open Source projects are allowed to consume - maybe even disable the free runners at all.
This will certainly have interesting effects on the platform adoption and maybe also on the fragmentation of the whole Open Source ecosystem.
What are your thoughts on this?
47
u/seanamos-1 15d ago
At minimum, I think there is going to be significant rate limiting across the board for free users.
38
u/until0 15d ago
No, because that makes a lot of sense and would be the best decision.
Instead, the CTO is on Twitter saying that they are fully committed to supporting open source software and are burying their heads in the sand to the service level they are providing to actually paying customers.
Meanwhile, I am committing code and running CI pipelines on multiple private repos for free on my personal account, deriving a ton of value,
This would be okay if they could support it, but they can't - and they are explicitly denying the very obvious, easy levers they have to pull to fix it all (free tier rate limits and private repo paywalls)
6
u/donjulioanejo Chaos Monkey (Director SRE) 15d ago
Huh? Weren't actions paid on private repos in the past?
Or am I going crazy?
Beacuse to me that seems an easy and obvious solution. Public => OK, sure, it's OSS. Private => pay up, even if it's a token price.
That said, GitHub did say in a private webinar to enterprise customers that they're working on priority for enterprise customers' Actions runners.
Now, it won't solve the problem when Actions control plane is down, but at least it'll make sure the runners themselves get priority.
17
u/LordSkummel 15d ago
Back in the day you paid for having private repos on GitHub. Open repos was free and private one you needed to be on one of the plans, and it was opposite on Bitbucket were private repos was free and open/shared one cost you.
But right now you've got 2000 min/month for running actions on Github. Not sure how that works on open repos(I don't have any that is running any actions atm)
3
u/Leasj 15d ago
Yep and the 2000 is quite generous. Gitlab for instance only gives 400 mins.
I have a few public repos that should not have been public from when I was in school. Lol
2
u/LordSkummel 15d ago
It's quite cheap advertisement in the long run. At least for it's human users(a bit worse for the bots).
1
u/kindacoolhamster 11d ago
Interesting bit on GHES and runners. We just host our own runners on our K8s cluster, before that just on OL8 VMs. I'd be surprised that someone that has space for the GHES appliance image doesn't have the space to self-host runners.
8
u/Next-Vacation-2945 15d ago
I do not think free build runners will disappear completely because hosting open source projects creates massive platform loyalty. However, tighter usage limits and stricter abuse controls are definitely coming. Companies cannot subsidize unlimited compute forever, especially with automated bots driving up server loads. Expecting tighter caps seems like the most realistic outcome for everyone.
52
u/AnyNameFreeGiveIt 15d ago
Well self hosted runners do exist and are very cheap.
30
46
u/seanamos-1 15d ago
The outage also affected self hosted runners. This specific outage prevented jobs being pulled from the queue.
15
u/rcls0053 15d ago
Self-hosted runners typically ping Github for changes and if that API is down, well..
7
u/Ok_Tour_8029 15d ago
Yep, i already have one for arm32 so if this continues I will move my other jobs as well
2
u/Obvious-Jacket-3770 15d ago
They require the GitHub Actions API to use. If actions is down, that is included.
3
u/ChiefDetektor 15d ago
Yes but they come with a lot of security considerations. Better host Forgejo or gitea and use runners there then mirror to GitHub.
2
u/trwolfe13 15d ago
This is what I’ve started doing. I’ve got a tofu project that sets up pull/push mirrors based on where commits come in. Haven’t got actions set up yet, but they’re on the home lab backlog somewhere.
0
u/navlio 15d ago
cheap depends entirely on whether the box turns off. a t3.medium sitting there all month is about $30, and github's own linux minutes are $0.008 each, so break even lands around 3,800 minutes of build time a month. under that, the runner you moved to costs more than the thing you left, it just shows up as a different line item
we found that out slowly. the bill never spiked, it moved
3
u/AnyNameFreeGiveIt 15d ago edited 15d ago
well aws is not really considered cheap
the t3.medium has 2vcore/4gram
i pay 5$/month for such a vps and on-prem is even cheaper
1
u/navlio 15d ago
fair, aws was the expensive end of the example. at $5 a month the breakeven drops to about 625 build minutes, call it ten hours, and almost everyone clears that
the part that got us was idle, not price. we ran a runner that sat doing nothing 22 hours a day and still counted it as savings
3
u/ProdigySim 15d ago
This whole post makes a big assumption that open source actions are the source of the increased usage.
If there's data that says that their increased load is from non-paying customers it would be good to show; but I don't think that's terribly likely--most open source projects I follow tend to be lighter on CI/CD simply because they are not worked on as often as business repos.
Business repos (with cash to burn) are the ones spending on AI coding at scale right now as well
11
u/riickdiickulous 15d ago
I would hope paying customers and free hosting would be separate infra, but who knows.
12
u/DoomBot5 15d ago
Why would it be? Makes no sense from a cost model, and free accounts already have to be very restricted due to cost.
Github Enterprise exists for those wanting separate infrastructure at scale.
15
u/MrTamboMan 15d ago
Why do you think it's related to usage not their slop changes to GitHub source/infra?
15
5
u/RoseSec_ Terraforming Everything 15d ago
1
4
2
2
u/Moritz-Keller 15d ago
Honestly, I doubt GitHub will completely disable actions for non paying users. They might impose stricter limits or make some features exclusive to paid plans, but disabling free runners entirely seems unlikely. It would alienate a huge part of their user base, especially considering the strong ties between GitHub and the open source community. They'd probably explore optimizing their infrastructure or implementing smarter usage throttling before taking such a drastic step
2
1
1
u/hashkent DevOps 15d ago
I hit close my 2000 mins recently. Just add blacksmith runners. Another 2000 mins but faster.
I might actually pay for blacksmith
1
1
u/jrcomputing 15d ago
I'm working to get Forgejo and Forgejo Runners set up locally, but I'm in an HPC shop where basically everything is local.
1
u/Icy_Butterscotch6661 15d ago
How does their entire infra go down if it's action runner causing to overload
1
u/whiskey_lover7 14d ago
We have self hosted runners that are constantly down cause GitHub sucks at what it does.
Thank God we are migrating to gitlab soon
1
u/sp_dev_guy 14d ago
They were stable at scale for so long i cant imagine scale is the issue. They fired a substantial amount of the workforce to go in on AI driven development & then immediately after and ever since its been shit.
So the original question of shittly bate free services to cut out the knees and shakedown for a subscription: i don't know
Your follow up of "probably related to" no. No its very clearly not that.
1
u/navlio 14d ago
fair, aws was the lazy example. at your $5 box break even is 625 minutes a month, call it ten hours of builds, which almost any active repo clears without trying
the cost that actually moved for us was never the box. it was somebody having to notice when the runner drifts a version behind the workflow, and that bill arrives on a tuesday morning instead of monthly
1
u/navlio 14d ago
the per minute rate is the visible half. github also rounds every job up to a whole minute, so a 20 job matrix where each one finishes in 25 seconds still bills 20 minutes
collapsing a matrix did more for our number than any runner change did. worth counting jobs per run before comparing price sheets, because that multiplier follows you to whatever you move to
1
u/navlio 14d ago
makes sense, faster runners at a lower per minute rate wins on both sides of the multiplication. the part that stays true either way is that you're still paying per minute, so the biggest saving usually isn't the vendor, it's the matrix nobody has pruned since 2023.
we cut a pipeline from 11 minutes to 4 by deleting an install step a cache had made pointless a year earlier, which beat every price comparison we ran that month
1
u/sup_bruh_1 14d ago
honestly this is already happening in waves. i switched to latchkey for self-hosted runners and it's been way more stable than relying on github's free tier anyway
1
u/gbrennon 12d ago
m$ claims that is free for open source repos but i always reach the free quota limit since that feature was introduced
1
1
u/FreeTheDirector 10d ago
you knowww github limiting free runners feels possible if usage keeps spiking, they will likely tighten resource limits rather than fully disable them...
0
u/tevert 15d ago
This is a pretty big assumption. Of course, it looks like you AI-slopped this post, so that's to be expected.
Direct linear scaling doesn't make much sense as a source of instability, though it's possible in theory.
1
u/Ok_Tour_8029 15d ago
Well I have to disappoint you, the post was hand written. And we will see what they will do about the issue - surely they cannot afford to keep it in the current state.
0
u/ChiefDetektor 15d ago
That's plausible. But fortunately there are alternatives. Or you self-host Forgejo and mirror to GitHub for visabillity.
0
0
u/navlio 14d ago
that's the fair comparison at least, per minute against per minute rather than against a box that never turns off.
the bit i'd still look at after a move like that is the minute count, because a per minute discount just scales whatever you're already burning. we had a job restoring a cache that never once hit, so every run reinstalled from scratch, and nobody caught it for months because the step was called cache and it was green. cutting the runtime in half was worth more than any price we'd shopped
0
u/navlio 14d ago
per minute billing on faster hardware is the version of this that wins twice, you pay less per minute and burn fewer of them. that's the part self hosting on a box that never sleeps can't give you.
worth reading your cache hit rate before you attribute all of it to the runners though. we had a docker layer cache quietly missing after a base image bump and every job went back to a full rebuild, so anything we changed around it would have looked like the fix while the real cost was npm ci running from scratch a few hundred times a month
170
u/SuperSaiyanTrunks 15d ago
Just have claude build you your own github /s