[_pdp_]

I am sure Blacksmith is the easy path if you don't want to do any extra work and I am also sure their solution will scale much better as this is what they do full-time.

However, I can share what we did to ease on our GitHub Actions bills if it helps.

Effectively we have our own runners hooked so that a job is scheduled, a runner picks it up and goes with it. We still use GitHub Actions but our monthly bill is now flat because we pay for a server. It is about 6x cheaper if not more.

The solution is not open source but it boils down to a Go service that orchestrates firecracker vms. All the vms are pre-warmed so there is always a fresh supply of workers to pick jobs of various sizes.

It is basic and it works. We have not had any issues since deployed.

The runners can be anything from 1 cpu 2 GB to 64GB 8 cpus. We can add more worker types in a config file.

I am not exaggerating when I say that we used to pay 1000s per month for this. Now our bills are in the range of a few hundred. Other dev boxes are done in the same way.

[arusahni]

> We still use GitHub Actions but our monthly bill is now flat because we pay for a server.

Caveat here being that GitHub is exploring charging a usage-based fee for self-hosted GitHub Action runners [1]. While they've halted it for now, it's something worth being aware of as you assess your costs. This is probably a drop in the bucket compared to the order of magnitude savings you've described.

[1]: https://github.blog/changelog/2025-12-16-coming-soon-simpler...

[inigyou]

Allegedly this is because whenever you have a self-hosted runner, it's actually a Microsoft-hosted runner that is notifying your runner and then polling for it to complete. I wish I was joking.

[watermelon0]

Self-hosted runners make a ton of API calls during job execution, so they might not be completely wrong here.

[inigyou]

That's for console output and status.

[_pdp_]

Thanks. I did not know.

[esafak]

Also note that managing self-hosted runners with Kubernetes is no walk in the park.

[_pdp_]

Haha, we don't use Kubernetes. It is a single large server with plenty of space for runners. It is as simple and boring as it gets. The only fun part is that we use Firecracker for the actual runners. It is provides nice isolation and it is very easy to work with.

[esafak]

https://fireactions.io/ ?

[_pdp_]

We looked into it but it id not quite fit what we wanted. Other than that I think it is great software.

[calgoo]

As someone who has worked with gitlab for the last 5 years, i find it amazing how over complicated the github flow it for CICD! Spin up a server and add the gitlab agent and done! You need more? Fine spin up a EKS k8 cluster and done!

[js2]

You can do the same with GitHub Actions. Spin up a server and start the actions runner on it and done! But if you want to dynamically scale your runners in response to load using a Kubernetes cluster, then they provide Action Runner Controller and it's a bit more complicated.