// the find
actions/actions-runner-controller
Kubernetes controller for GitHub Actions self-hosted runners
Kubernetes operator that runs GitHub Actions self-hosted runners as ephemeral pods, scaling up/down based on queued workflow jobs. Now officially maintained by GitHub alongside community contributors. The main use case is teams that need self-hosted runners (private network access, custom hardware, cost control) without managing a static fleet.
- The newer scale-set mode uses a long-polling listener pod that receives job assignments directly from GitHub's backend, which is faster and more reliable than the legacy webhook/polling approaches and eliminates the thundering herd problem on scale-up.
- Ephemeral runner model means each job gets a clean pod - no state leakage between jobs, and failed runners just get replaced. This is the right default for CI.
- Helm charts are well-structured with extensive unit tests (using helm unittest), covering RBAC, proxy configs, DinD vs Kubernetes container modes, and TLS injection - not just smoke tests.
- Supports both GitHub App and PAT authentication, proxy configs, custom runner images, and Kubernetes-native container execution (without Docker-in-Docker), giving real flexibility for different security postures.
- There are now effectively two separate controller implementations living in the same repo (legacy summerwind mode under apis/actions.summerwind.net and the new GitHub-supported scale-set mode under apis/actions.github.com), with the legacy one only community-maintained. This split creates real confusion about what's actually supported and what will be deprecated.
- Minimum scale of zero means cold-start latency when no runners are warm - the scale-up-from-zero path depends on the listener pod getting a job assignment and then k8s scheduling a new pod, which can add 30-60+ seconds to job start time depending on cluster and image pull times.
- The 'experimental' chart variants (gha-runner-scale-set-experimental, gha-runner-scale-set-controller-experimental) sitting alongside the stable ones with no clear explanation of when/whether to prefer them adds unnecessary decision fatigue.
- No built-in support for pre-warming a runner pool - if you need consistently fast job starts, you have to set minRunners > 0 and pay for idle compute, with no smarter predictive scaling options.