[werewrsdf]

I recently set up AWS Github runners with this terraform. It works well and you don't have to pay any extra in addition to AWS.

https://github.com/philips-labs/terraform-aws-github-runner

[striking]

I helped set this up at my workplace and can second that it works fairly well, but it definitely does have scale issues (we tend to exhaust our GH org's API ratelimit and end up being unable to scale up sometimes, as well as seeing containers be prematurely terminated because the scale down lambda doesn't seem to always see them in the GH API) and it's definitely lacking a lot of tooling around building runner images and caching optimization that we ended up building in-house.

Definitely linking OP to my team now.

[SOLAR_FIELDS]

We looked at this Phillips solution originally in a previous org and eventually decided on Karpenter + Actions Runner Controller instead, configured with webhook aka push based triggers. It’s really the best solution for scale but it does take awhile to implement and tune to get right. If you have dedicated infra people I can recommend it. If you don’t, I would look to a more managed solution like OP’s offering

[jacobwg]

Yeah this is a good option if you'd like something to deploy yourself! You can also build an AMI from GitHub's upstream image definition (https://github.com/actions/runner-images/tree/main/images/ub...) if you'd like it to match what's available in GitHub-hosted Actions.

With Depot, we're moving towards deeper performance optimizations and observability than vanilla GitHub runners - we've integrated the runners with a cache storage cluster for instance, and we're working on deeper integration with the compute platform that we built for distributed container image builds - as well as expanding the types of builds we can process beyond Actions and Docker, for instance.

But different options will be better for different folks, and the `philips-labs` project is good at what it does.