Hacker News Reader

Comment by inigyou | Hacker News Reader

GitHub implements self hosted runners by running a normal runner that passes the environment to your runner and then polls it. That's why they cost as much as the smallest GitHub-hosted runner.

This is no surprise given standard Microsoft operating procedure - https://news.ycombinator.com/item?id=47616242

View on HN

they walked that back for now at least - self-hosted gh runners are still free: https://docs.github.com/en/billing/concepts/product-billing/...

Well, they're still implemented that way.

Can you share a source for this? it's not that I don't believe you but I've had difficulties finding one.

Do you have a source for this?

More likely is that the log streamer takes up some amount of resources and thus running it requires a baseline level of compute. But I doubt they spin up a small runner per-self-hosted runner, most likely some ruby workers (on distributed azure instances) are dedicated purely to streaming self-hosted runner logs to log consumers.

I'm certainly not surprised that they tried to sneak in billing self-hosted runner minutes at some ratio to potentially recoup the costs here.

0: https://docs.github.com/en/enterprise-server@3.21/admin/mana...

Oh that is pretty gross, thanks for sharing. I was not aware of that process, that explains the cost they attempted to roll out for runners too a few months back.

I think they kind of have to operate that way if you want a control plane/access to GitHub’s own layered services like caching and artifact storage. There are plenty of things to blame GitHub for, but this one doesn’t seem sinister at all.

Edit: to be clear, I mean the part where they maintain state on their end. I have no idea if they do that with another runner instance, that seems unlikely.

Reply on news.ycombinator.com