Self-hosted Actions runners without dedicating a whole machine to CI

[u/AroundTech]

GitHub's standard self-hosted runner is convenient when you can give it a dedicated machine, but it's only one runner per machine.

But keeping a separate box just for CI can get expensive, and I'd rather not have build scripts and leftover containers messing with a machine I also use for other things.

What I like about gh-runnerd is that it runs multiple runners on one machine, with each job getting its own fully isolated VM.

When the job finishes, the whole VM gets destroyed, and the next job starts fresh.

Is anyone here using this or something similar?

https://github.com/RefireLab/gh-runnerd

[u/ImDevinC]

GitHub runners are not limited to one per machine, they already run as VMs https://docs.github.com/en/actions/concepts/runners/github-hosted-runners

[u/AroundTech → u/ImDevinC]

Yep, GitHub-hosted runners already offer that disposable-VM setup, and the costs can add up.

I was referring to self-hosted runners, gh-runnerd brings that same approach to your own hardware

[u/ImDevinC → u/AroundTech]

self-hosted runners work the same way... I run a pool of my own self-hosted runners on my local machine already as docker images or using their ARC kubernetes controller for kubernetes management.

[u/DarthCocktail → u/ImDevinC]

Same, using ARC controller on a k3s 4-node cluster with scale to zero, wakes up and runs up to 4 runners on command from GitHub. No open ports, just an Operator. Works great.

[u/mrkurtz → u/ImDevinC]

And there’s literally nothing stopping you from installing multiple runner services on a static, persistent instance or VM. I’ve done it before, for certain needs. We use ARC but it can absolutely be done.

[u/Torutofu_Raeva]

yeah we just park a few disposable VMs on one box and have each runner unregister before wipe so nothing sticks around

[u/Zealousideal_Yard651]

You can run multiple runners on the same machine, you could split the server up using VM's, or you could even run it as a container in docker.

[u/AroundTech → u/Zealousideal_Yard651]

Yep, Docker can work too, but regular containers still share the host's kernel.
Totally valid approach, just not quite the same level of isolation

[u/franktheworm → u/AroundTech]

A cursory look at your docs says that the install process is curl <blah> | sudo bash...

You don't get to try take the moral high ground on security while you have that as your install and upgrade process.

[u/zMynxx]

You can deploy several runners on a single host. We’ve had that setup until we switched over to ARC

[u/jnnngs_eth]

Each machine has one stock runner, but you don't need a box per runner. I built Zoomies (free, AGPL, single Go binary, SQLite, no Kubernetes), which runs ephemeral runners per job on a host or across several hosts, and scales on webhooks. It's aimed at exactly this home-lab and small-team case. Happy to answer questions if useful: https://zoomies.sh. If you only need a couple of runners, a plain container-per-job setup is also fine.

[u/Gotti5]

im using avrea for my runners, each job gets its own fresh vms and dep gets cached after 1st build 

[u/moltar]

I run on CodeBuild runners. No infra to manage or maintain. Choose from whatever compute choices CodeBuild provides.

[u/evilneuro → u/moltar]

I used them heavily with github, takes a couple of mins to provision but nice and cheap for low workloads. then i discovered they don’t support github enterprise with data residency, so that sucked.

[u/moltar → u/evilneuro]

If it takes a couple of minutes most likely you are not using a very common image which takes time to pull and not cached. Check your stage timings and see which stage takes longest. For me it takes maybe 30 seconds. I recently switched some to ARM and provisioning got slower as I guess less ARM machines are available. But build times sped up. In the end it was pretty much a wash. 😀

[u/evilneuro → u/moltar]

we’re using aws/codebuild/standard:7