Actions Runner Controller (ARC) vs Managed Runners
ARC runs self-hosted runners on your Kubernetes cluster - powerful, but you operate the cluster, scaling, and upgrades.
Actions Runner Controller (ARC) is GitHub-backed tooling to run self-hosted runners as pods on Kubernetes with autoscaling. It is great if you already run K8s - but it is still self-hosting. Here is how it compares to managed runners.
| ARC (self-hosted on K8s) | Managed (Latchkey) | |
|---|---|---|
| Compute cost | Raw cluster cost | Low (~69% under hosted) |
| Requires Kubernetes | Yes (you operate it) | No |
| Scaling | You configure autoscaling | Warm pools (built in) |
| Patching / upgrades | You own controller + nodes | Handled for you |
| Flaky-failure recovery | No | Self-healing auto-retry |
| Setup effort | High (Helm, controller, scaling) | Label swap |
When ARC fits
ARC is a strong choice if you already run Kubernetes, want runners co-located with your cluster, and have a platform team to operate the controller, node pools, and autoscaling.
The ops reality
ARC is still self-hosting: you own the controller upgrades, runner image maintenance, scaling tuning, and the reliability of the underlying nodes. That is real, ongoing platform work.
Managed alternative
Managed runners like Latchkey give similar compute savings (~69% under GitHub-hosted) without any Kubernetes to run, with warm pools for instant pickup and self-healing that auto-retries transient failures.
The verdict
Use ARC if you have a Kubernetes platform team and want runners in your own cluster. If you want the cost savings without operating K8s, managed runners are the lower-effort, self-healing path - start free.