What Is Actions Runner Controller (ARC)? Runners on Kubernetes
Actions Runner Controller (ARC) is an open-source Kubernetes operator that runs and autoscales self-hosted GitHub Actions runners as pods in your own cluster.
ARC is the popular way to self-host runners at scale on Kubernetes. It turns runner capacity into pods that scale with demand - powerful, but it makes your CI fleet a Kubernetes workload you now have to operate.
What ARC does
ARC watches GitHub for queued jobs and creates ephemeral runner pods to handle them, scaling up under load and down to zero when idle. Each runner is a pod scheduled onto your cluster nodes.
Why teams adopt it
- Ephemeral, autoscaled runners without per-minute hosted pricing.
- Runners that live inside your network and security boundary.
- Reuse of existing Kubernetes platform investment.
The operational reality
ARC inherits all of Kubernetes ops: cluster upgrades, node autoscaling, controller updates, image maintenance, scaling tuning, and debugging pod scheduling. The runners are "free" of hosted pricing but expensive in platform-engineering time.
ARC vs managed runners
ARC and a managed platform target the same goal - cheap, ephemeral, autoscaled runners - but ARC is do-it-yourself on Kubernetes while a managed platform is run for you. The choice is whether you want to operate the fleet.
The zero-ops alternative
Latchkey delivers ephemeral, autoscaled, warm-pooled runners with no cluster to run - the ARC outcome without the Kubernetes operations, typically around 69% cheaper than GitHub-hosted.
Key takeaways
- ARC is a Kubernetes operator that autoscales self-hosted GitHub runners.
- It gives ephemeral, autoscaled runners inside your own cluster.
- It carries full Kubernetes operational overhead.
- Managed runners reach the same outcome with zero ops.