Pricing Changes for GitHub Actions • Hacker News Board

Re: Pricing Changes for GitHub Actions

#621

Post by bigbuppo » Wed, Dec 17, 2025, 3:28 AM UTC

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…

Nearly 20 years ago, some VP at a security products company now owned by Broadcom threatened us during contract renewal with, "The price is what it is. Your contract is up in two weeks. What are you going to do? Move to a competing product?"

We had it done with a week to spare.

Re: Pricing Changes for GitHub Actions

#622

Post by franklyworks » Wed, Dec 17, 2025, 3:33 AM UTC

IshKebab wrote: post #104

lherron wrote: post #37

Why would the self-hosted runner fee be per-minute instead of per-job? I don’t get it.

Because the competitor services that provide much cheaper hosted runners also charge per minute. This isn't aimed at people actually self-hosting; it's aimed at alternative hosted runners providers. See this list https://github.com/neysofu/awesome-github-actions-runners

Runner price based on CPU/memory and time makes sense, since those are the costs associated with executing runners.

The costs for GitHub doing action workflows (excluding running) is less related to job duration.

The most charitable interpretation is that per-minute pricing is easier to understand, especially if you already pay runners per minute.

The less charitable interpretation is that they charge that because they can, as they have the mindshare and network effect to keep you from changing.

Re: Pricing Changes for GitHub Actions

#623

Post by tlhunter » Wed, Dec 17, 2025, 3:37 AM UTC

Just dropping in to say how lovely the Gerrit experience is when compared to GitHub: https://www.gerritcodereview.com/

Re: Pricing Changes for GitHub Actions

#624

Post by franklyworks » Wed, Dec 17, 2025, 3:37 AM UTC

suryao wrote: post #129

Here are the practical implications and considerations to optimize for cost, given the new pricing. These are generic and ensure you think through your workflows and runners before making any changes. 1. Self-hosting runners is still cheaper than not Despite the $0.002/minute self-hosted runner tax, self-hosting runners on your cloud (aws/gcp/azure/...) remains the cheaper option. 2. Prefer larger runners If your wor…

Any thoughts on what to extent GitHub is subsidizing OSS development with its CI?

This feels like one of the big issues that OSS projects might face when migrating to an alternative.

What might a less GitHub centric CI ecosystem look like for OSS community?

Re: Pricing Changes for GitHub Actions

#625

Post by cyberax » Wed, Dec 17, 2025, 3:41 AM UTC

Nextgrid wrote: post #590

cyberax wrote: post #396

Earlier quoted context omitted.

> And I mean sure, everything is kinda janky on Jenkins, but everything falls into an expectable corridor of jank you get used to. Self-hosting Jenkins on an EC2 instance is probably going to result in a _better_ experience at this point. Github Cache is barely better than just downloading assets directly, and with Jenkins you can trivially use a local disk for caching. Or if you're feeling fancy and want more isolat…

Self-hosting on a host whose data actually persists is an even better experience, as it removes a lot of the tedium and workarounds such as extracting/down-/up-loading caches and so on. Get another host for redundancy and call it a day. Hardware is getting cheaper and cheaper, but the fear-mongering around running a Linux machine has successfully prevented most businesses from reaping those cost reductions.

Complete persistence has its downsides, as you can start getting "path dependency". E.g. a build succeeds only because some images were pre-cached by a previous build.

But having an _option_ to not download everything every time is great. You can add a periodic cache flushing, after all.

Re: Pricing Changes for GitHub Actions

#626

Post by rileymat2 » Wed, Dec 17, 2025, 3:53 AM UTC

gabrielgio wrote: post #508

rileymat2 wrote: post #415

Earlier quoted context omitted.

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.

In some sense, core licensing is worse, in that you are also paying for idle capacity. But when you try to scale by activity, I think you will see it is not that much different.

Re: Pricing Changes for GitHub Actions

#627

Post by greatgib » Wed, Dec 17, 2025, 3:58 AM UTC

Wild to see that they make you pay an expensive price to use your own hardware... First, they are free quota and the free self hosted runners to kill the previously existing competitors by dumping their price very hard, then, once alternatives are already dead, they can start to take their margin. Disgusting!

Re: Pricing Changes for GitHub Actions

#628

Post by mattraibert » Wed, Dec 17, 2025, 3:59 AM UTC

suryao wrote: post #348

cprecioso wrote: post #339

Earlier quoted context omitted.

I checked the WarpBuild website and got excited because the header in the menu says you have macOS Intel runners, but then you click through and it doesn't seem to be so? Right now at my company our biggest complaint are macOS Intel runners from GitHub which somehow take 15+ minutes to provision and are the slowest of the bunch.

We only have macos arm64 (M-series) runners. Can you point me to the intel reference so I can fix it?

Hover the top nav. Under "CI Runners" it's says:

macOS Runners Apple Silicon and Intel support

Re: Pricing Changes for GitHub Actions

#629

Post by cweagans » Wed, Dec 17, 2025, 4:10 AM UTC

featherless wrote: post #307

cweagans wrote: post #106

Earlier quoted context omitted.

That's not exactly true. You just won't be able to use self-hosted infra to validate GitHub PRs a) using GHA and b) for free. GitHub still supports e.g. PR checks that originate from other systems. We had PR checks before GHA and it's easy enough to go back to that. Jenkins has some stuff built in or you can make some simple API calls. It's not as convenient, but it works just fine.

Won't those other systems create a cost that is metered in terms of run-time?

I suppose any compute resources would, but it wouldn’t be GitHub charging you for it if you’re not using GHA.

Re: Pricing Changes for GitHub Actions

#630

Post by donatj » Wed, Dec 17, 2025, 4:12 AM UTC

BugsJustFindMe wrote: post #94

Everyone in this thread has gone absolutely insane. $5/month gets you 41 fucking _hours_ of continuous operation. If you're not utterly abusing the platform, this falls extremely below the threshold of caring. And if not, what the fuck are you even doing with all those hours? The new per-minute charge is less than one millisecond of engineer labor cost.

$3 gets me 730 hours of comparable Vultr VPS time.