> You know how I know GitHub’s runners are bad? Because there’s an entire cottage industry of companies whose sole product is “GitHub Actions, but the runners don’t suck.” Namespace, Blacksmith, Actuated, Runs-on, BuildJet

He's not wrong. Buildjet just announced they were shutting down though, citing recent improvements to the GitHub Actions platform.

For the record I maintain the Runs-on [1] he's talking about, as a solo developer.

[1] https://runs-on.com

For alternatives, I maintain a benchmark at https://runs-on.com/benchmarks/github-actions-cpu-performanc...

Not fully OSS, but you can have a look at https://github.com/runs-on/runs-on

Thanks for posting this :) runs-on.com domain posts never get traction, wonder if this could be due to YCombinator investment in 5+ startups in that space... Oh well.

I am developing a self-hosted solution for this [1]. It’s true that it’s somewhat of a pain but JIT runners allow a lot of flexibility that we don’t find elsewhere.

[1] https://runs-on.com

I did something very similar.

Create/start/stop/terminate EC2.

https://github.com/redoapp/fast-actions-runner-ec2

In my experience even with runs-on it is a bit painful with runner cancellations.

Probably long overdue, but per-minute price vs per-job is quite expensive. Wouldn’t like to be in the shoes of “only” 2x cheaper third parties. If they follow up with faster runners… interested to see if they ever come up with a good SDK for their scale set API, will integrate it in RunsOn!

But you can self-host github actions runners as well.

It is not transparent though, so it doesn't work with all the other actions that use the cache toolkit, and you have to reference a specific action.

At this point this is considered a baseline feature of every good GitHub Actions third-party provider, but nice to see the write-up and solution they came up with!

Note that GitHub Actions Cache v2 is actually very good in terms of download/upload speed right now, when running from GitHub managed runners. The low speed Blacksmith was seeing before is just due to their slow (Hetzner?) network.

I benchmarked most providers (I maintain RunsOn) with regards to their cache performance here: https://runs-on.com/benchmarks/github-actions-cache-performa...

Also note this open-source project that shows a way to implement this: https://github.com/falcondev-oss/github-actions-cache-server

FYI you can also use a local S3 bucket as cache backend, and get 5x faster bandwidth and unlimited storage compared to a runner managed by GitHub: https://github.com/runs-on/cache