How do you design an autoscaling architecture for self-hosted GitHub Actions runners, and what are the key components for scaling to zero?

Imagine a taxi dispatch system at an airport. When flights land (workflow jobs queue), dispatchers (controllers) call in taxis (runners) from a standby pool. When traffic is light, taxis go home. A scale-to-zero system means there are no taxis idling at the airport—they only appear when a flight arrives. This is exactly how modern self-hosted runner autoscaling works, except the 'taxis' are ephemeral compute instances.

The core architecture centers on detecting queued workflow jobs and provisioning runners to claim them. GitHub emits a 'workflow_job' webhook event with action 'queued' when a job needs a runner. An autoscaler listens for these webhooks, provisions a new runner (VM, container, or Kubernetes pod), registers it with GitHub using a just-in-time (JIT) runner token, and the runner picks up exactly one job. After the job completes, the runner deregisters and the compute resource is destroyed. This ephemeral model ensures a clean environment for every job and prevents credential leakage between runs.

The most widely adopted solution is Actions Runner Controller (ARC), which runs on Kubernetes. ARC v2 uses a listener pod that monitors for workflow_job webhook events via a GitHub App. When a job is queued for a matching runner scale set, the listener instructs Kubernetes to create a new runner pod. The runner pod starts, picks up the job, executes it, and terminates. ARC's architecture includes the controller (manages CRDs), the listener (watches for jobs), and ephemeral runner pods. For non-Kubernetes environments, tools like Philips terraform-aws-github-runner use AWS Lambda to receive webhooks and launch EC2 instances or Fargate tasks as runners.

In production, organizations like payments-api-platform running 500+ daily workflows need careful tuning. Key configuration includes setting minRunners to 0 for true scale-to-zero, maxRunners to cap costs, and configuring runner group permissions to restrict which repositories can target which runner pools. You should use runner labels strategically—for example, 'gpu-enabled' for ML training jobs, 'large-8cpu' for compilation, and 'arm64' for cross-platform builds. Warm pools of 2-3 pre-provisioned runners reduce cold-start latency for critical pipelines. OIDC federation with cloud providers eliminates long-lived credentials on runners, and you should mount tool caches as persistent volumes to avoid re-downloading SDKs for every job.

The biggest gotcha is webhook delivery reliability. If your webhook endpoint goes down, queued jobs sit indefinitely because no runner spins up to claim them. Mitigate this with a fallback polling mechanism that periodically checks the GitHub API for pending jobs. Also watch out for the runner registration race condition: if two autoscaler instances both respond to the same webhook, you get double-provisioning. Use distributed locks or idempotency keys to prevent this. Docker-in-Docker (DinD) on Kubernetes runners requires privileged mode or rootless alternatives like Sysbox, which introduces security considerations. Finally, ephemeral runners using JIT tokens have a 24-hour registration window—if a runner takes too long to start, the token expires and the runner cannot register.