Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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...





> 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 ?

I know they charge for Artifact storage, but outside of uploaded artifacts I don't think that the logs and results of builds are billed separately?

Additionally, I thought that caching came out of a separate limit, and was not billed like artifact storage?


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.

GH enterprise cloud is charging for storage separately, as an organization admin just navigate to the org admin page to see it.

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?


I do believe, this is to disincentivize self-hosting for smaller-medium workloads. In essence, they're saying that if you're small, you should just use their Linux 1-Core, but if you're medium-to-large you won't care about the high cost.

It is a way of increasing lock-in for smaller-medium clients, without driving away their medium-large ones.


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%.

OP replied and clarified that that's not the case.

His workload is close to the more typical one i mentioned as scenario b. It will cost them $84/month.

For me, we do about 800,000 build minutes/month, for orchestration alone it is going to be $1600/month. In contrast the runner host we use (Namespace labs) cost $0.0015 / minute[1] which is less than orchestration cost for GH, that is just ridiculous.

---

[1] It is even worse, the first 250,000 minutes is fixed at $250, so the base is $0.001 /minute for the runner.


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?

When you've already paid for the hardware, it is essentially free after that (aside electricity, I suppose). So there wasn't a reason to ration our runners, and we actually added additional workloads/scans/etc just because we could.

We're targeting 4x different deployment pipelines, so while we aren't running 24/7, we are running the same number of hours but split over all our runners. Often runs are queued during our busy 8-hour work-day, and then unused for 16-hours.

Either way, we will likely pay 8-hours4-pipelines5-days=160 hours per week, just shy of 168-hours for true 24/7. This currently costs $0 just for context.


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


Yup. Took wayyy longer than I actually expected as well. But the change of top management and closer integration with the whole MS behemoth is likely to make those kind of things accelerate now

$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.


I was about to call you off and say your math is wrong, you must be an order of magnitude wrong.

But you are right, this is ridiculous!


> A lot of people leave their self-hosted runners running 24/7

Don't they generally only kick in when you push or merge?


Per machine. Definitely more than one machine here.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: