Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pricing Changes for GitHub Actions

resources.github.com

Post reply on HN
Print view View original

231–240 of 853 posts

Re: Pricing Changes for GitHub Actions

#231

Post by suryao »

simonw wrote: post #90

Could this change mainly be about competition with their own hosted runners? Today it's possible to spin up a company that sells GitHub Actions runners with a lower price and higher performance than GitHub's own hosted runners. These new fees will make that a lot less economically viable.

With these changes, three things hold:

1. Services like WarpBuild (I'm the founder) are still cheaper than GitHub hosted runners, even after including the $0.002/min self-hosting tax.

2. The biggest lever for controlling costs now is reducing the number of minutes used in CI. Given how slow Github's runners are, or even the ones on AWS compared to our baremetal processor single core performance + nvme disks, it makes even more sense to use WarpBuild. This actually makes a better case for moving from slow AWS instances running with actions-runner-controller etc. to WarpBuild!

3. Messaging this to most users is harder since the first reaction is that Github options make more sense. After some rational thought, it is the opposite.

Re: Pricing Changes for GitHub Actions

#232

Post by [deleted] »

lukeasrodgers wrote: post #203
ilvez wrote: post #176

Earlier quoted context omitted.

Isn't it like way more expensive and restricted? They were very competitive in the early days, but currently they are more capped than anything else it seems. Especially for self hosting.. > Hosted Agents > > 2,000 minutes/month :-o

Buildkite doesn't have per-minute charges for self-hosted agents.

[deleted]

Re: Pricing Changes for GitHub Actions

#233

Post by hoten »

I wonder how much they made from engineering practices such as https://github.com/actions/runner/issues/3792.

To spell it out: jobs can hang forever because of some ridiculously bad code on their end, they have a 6 hour cap, so that's 6 hours of billable $$$ per-instance of the bug (assuming it wasn't manually canceled). I know I've seen jobs hang forever regularly over the course of my years using GitHub for work.

Note: pretty sure this has been resolved.

Re: Pricing Changes for GitHub Actions

#234

Post by esafak »

golovast wrote: post #131

I got contacted by our rep a couple weeks ago, who informed me of this news. I thought it was a disaster and it really pissed me off. The rep couldn't even explain the reasoning well. It basically summed up to "because we can" and "where are you going to go?". He was shocked to find out that I didn't like it. We currently self-host on kubernets/aws. The thing that really got to me isn't the new charge per se. It's th…

Any official Github action today:

"Thank you for your interest in this GitHub action, however, right now we are not taking contributions.

We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time. The GitHub public roadmap is the best place to follow along for any updates on features we’re working on and what stage they’re in."

Re: Pricing Changes for GitHub Actions

#235

Post by kylegalbraith »

Founder of Depot[0] here. I'm disappointed by this change and by the impact this is going to have on all self-hosted runner customers, not just us. In my view, this is GitHub extracting more revenue from the ecosystem for a service that is slow, unreliable, and that GitHub has openly not invested in.

We will continue to do our best to provide the fastest GHA runners and keep them cheaper than GitHub-hosted runners.

[0] https://depot.dev

Re: Pricing Changes for GitHub Actions

#236

Post by elashri »

stephen_cagle wrote: post #134

The email I received from them this morning claims that this will be cheaper for 96% of users... I have cron jobs on several github projects that runs once a day and I have never been charged anything for it (other than my github membership). Should I expect to be charged for this?

I would think that majority of users does not use GitHub actions at all or have very light infrequent usage so that would be true. I think with my personal project I have never exceeded the resources they give me as part of personal pro subscription.

Re: Pricing Changes for GitHub Actions

#237

Post by esafak »

featherless wrote: post #122
Eikon wrote: post #114

Earlier quoted context omitted.

On ZeroFS [0] I am doing around 80 000 minutes a month. A lot of it is wasted in build time though, due to a lack of appropriate caching facilities with GitHub actions. [0] https://github.com/Barre/ZeroFS/tree/main/.github/workflows

I found that implementing a local cache on the runners has been helpful. Ingress/egress on local network is hella slow, especially when each build has ~10-20GB of artifacts to manage.

What do you use for the local cache?

Re: Pricing Changes for GitHub Actions

#238

Post by yjftsjthsd-h »

wiether wrote: post #195
zahlman wrote: post #152

Earlier quoted context omitted.

Based on my experience I really do think most people are using it for things that they could perfectly well do locally with far less complication. Perhaps that isn't most use of it; the big projects are really big.

Care to provide examples? Fundamentally, yes, what you run in a CI pipeline can run locally. That's doesn't mean it should. Because if we follow this line of thought, then datacenters are useless. Most people could perfectly host their services locally.

> Because if we follow this line of thought, then datacenters are useless. Most people could perfectly host their services locally.

There are a rather lot of people who do argue that? Like, I actually agree that non-local CI is useful, but this is a poor argument for it.

Re: Pricing Changes for GitHub Actions

#239

Post by nyrikki »

MathiasPius wrote: post #16

Introducing a separate charge specifically targeting those of your customers who choose to self-host your hilariously fragile infrastructure is certainly a choice.. And one I assume is in no way tied to adoption/usage-based KPIs. Of course, if you can just fence in your competition and charge admission, it'd be silly to invest time in building a superior product.

I resorted to a local forgejo + woodpecker-ci. Every time I am forced back to GitHub for some reason it confirms I made the right choice.

In my experience gitlab always felt clunky and overly complicated on the back end, but for my needs local forgejo is better than the cloud options.

Re: Pricing Changes for GitHub Actions

#240

Post by featherless »

esafak wrote: post #237
featherless wrote: post #122

Earlier quoted context omitted.

I found that implementing a local cache on the runners has been helpful. Ingress/egress on local network is hella slow, especially when each build has ~10-20GB of artifacts to manage.

What do you use for the local cache?

Just wrote about my approach yesterday: https://jeffverkoeyen.com/blog/2025/12/15/SlotWarmedCaching/

tl;dr uses a local slot-based cache that is pre-warmed after every merge to main, taking Sidecar builds from ~10-15 minutes to <60 seconds.

Post reply on HN