I put together a detailed write-up on setting up self-hosted GitHub Actions Runners using ARC (Actions Runner Controller) on AWS using EKS.<p>This includes terraform code for provisioning the infrastructure, and helm configurations for Karpenter v1.0 setup. We also ran a couple of variants in configuration for cost and performance comparison using Karpenter for autoscaling and other best practices.<p>Using a couple of PostHog's OSS repo workflows as for testing, the variations of config were basically allowing Karpenter to pick runners of arbitrary sizes from the same instance family and figure out the scaling, vs forcing one node per job.<p>The most interesting part from the post is added below.<p>## Performance and Scalability<p>All the jobs are run on the same underlying CPU family (m7a) and request the same amount of resources (vcpu and memory).<p>ARC runners with varied node sizes exhibited slower performance primarily because multiple runners shared disk and network resources on the same node, causing bottlenecks despite larger node sizes.<p>To address these bottlenecks, we tested a 1 Job Per Node configuration with ARC, where each job ran on its own node. This approach significantly improved performance. However, it introduced higher job start delays due to the time required to provision new nodes.<p>Job start delays are directly influenced by the time needed to provision a new node and pull the container image.<p>Total Jobs: 960
ARC (Varied Node Sizes): $45.88
ARC (1 Job Per Node): $42.60<p>What are some other optimizations that can be done?
Are there other considerations that could be added to extend the post?<p>Let me know what you think.<p>Full post: <a href="https://www.warpbuild.com/blog/setup-actions-runner-controller">https://www.warpbuild.com/blog/setup-actions-runner-controll...</a>
Code: <a href="https://github.com/WarpBuilds/github-arc-setup">https://github.com/WarpBuilds/github-arc-setup</a>