Runner Scale Sets, Actions Runner Controller, and Kubernetes Autoscaling: Configuration, Design Patterns, and Trade-Offs

1. Start with workload trust, not Kubernetes enthusiasm

Ask five questions before choosing ARC: Who authors the workflow? Can pull requests contain untrusted code? What internal network/data must jobs reach? How quickly must capacity appear? Who will patch and monitor the Kubernetes control plane? If the answer to the last question is “nobody,” GitHub-hosted runners are usually the safer default.

2. GitHub-hosted versus ARC-managed runners

3. Persistent fleet versus ephemeral scale set

Persistent runners reduce cold start and can keep expensive tool caches locally, but they create cross-job residual-state risk and require explicit cleanup. Ephemeral ARC runners are designed for one-job lifetimes, making state reuse less likely and autoscaling simpler. The trade-off is startup latency and dependence on external artifact/cache services.

Production default for mixed workloads: prefer ephemeral runners and move durable outputs to explicit artifacts/caches rather than relying on runner disk.

4. DinD versus Kubernetes mode

5. Shared cluster versus isolated runner cluster

GitHub explicitly recommends isolating production ARC workloads. Workflows execute arbitrary code. If runner pods share a cluster with production services, a container escape, over-broad service account, node compromise, insecure storage class or permissive network policy can turn CI code into production access.

A strong design uses a dedicated runner cluster or at minimum dedicated nodes/namespaces, default-deny network policy, bounded RBAC, no production service-account mounts, admission policy, resource quotas and centralized logs. Labels alone do none of this.

6. Runner group, scale-set name and labels solve different problems

Runner groups control which repositories/organizations may access runner resources. A scale-set name is a routable target and can be used directly in runs-on. Current ARC also supports runnerScaleSetLabels so multiple labels can target a scale set. Those labels are fleet routing metadata; they are not equivalent to arbitrary per-host labels on classic persistent runners, and they are not an isolation mechanism.

runnerGroup: arc-lab-group
runnerScaleSetName: arc-linux-build
runnerScaleSetLabels:
  - linux
  - build
  - isolated-ci

7. Capacity policy: warm floor, hard ceiling, drain

minRunners is an idle-capacity floor. maxRunners is a hard scale ceiling. Omitting both allows demand-driven growth with scale-to-zero, which can be appropriate only when cluster quota and cost bounds exist elsewhere. A safer production policy normally sets an explicit ceiling.

8. ARC versus a custom Runner Scale Set Client

ARC is the supported Kubernetes operator path and already implements listener/controller/JIT runner lifecycle. GitHub also documents a Runner Scale Set Client for platform teams building custom autoscaling integrations. Choose the custom client only when Kubernetes is the wrong substrate or when an infrastructure provider needs a different control plane and is prepared to own scheduling, isolation, logs, upgrades and failure recovery.

The custom client is not “less infrastructure”; it transfers more of the control plane into your code and operations.

9. Upgrade compatibility is a state transition

Pin controller and runner-scale-set chart versions separately in GitOps. Before upgrading, record current CRDs, chart versions, controller image, runner image, Kubernetes version, values, workload queue depth and rollback package. Test chart/CRD changes in a disposable cluster. Do not let latest silently change the runner image underneath a regulated release process.

10. Worked decision: internal build fleet

Knowledge check

Official references and version notes

• GitHub Docs — Actions Runner Controller — control-plane architecture, listener/JIT registration and ephemeral runner lifecycle.
• GitHub Docs — Deploy runner scale sets — Helm deployment, runner groups, min/max runners, pod templates, container modes and security guidance.
• GitHub Docs — Use ARC in a workflow — scale-set names and scale-set labels in runs-on.
• GitHub Docs — Troubleshoot ARC — controller/listener/runner diagnostic workflow.
• ARC release 0.14.2 — pinned release used for concrete examples in this chapter.
• GitHub Actions runner container image — minimal runner image published with runner releases.