When GitHub Actions pipelines hit thousands of daily builds, your runner strategy becomes a first-class infrastructure decision — here's how to choose between self-hosted runners, larger hosted runners, and the Kubernetes executor.
You'll learn:
- How GitHub-hosted larger runners (up to 64-core) reduce ops overhead versus self-hosted, and where the cost curve flips
- Self-hosted runner autoscaling with actions-runner-controller (ARC) on Kubernetes — ephemeral pods per job, KEDA-based scaling triggers
- Kubernetes executor trade-offs: pod startup latency, RBAC isolation, and shared caching via persistent volumes or S3-backed artifact stores
- Queue depth, job concurrency limits, and why runner group segmentation matters at 10K+ builds per day
- Common failure modes: runner re-use contamination, Docker-in-Docker socket conflicts, and rate-limit exhaustion on the GitHub API
Keywords: GitHub Actions self-hosted runners, actions-runner-controller Kubernetes, scaling CI pipelines, GitHub larger runners, ARC autoscaling
🎧 Listen, then go deeper — DevOps & Cloud interview-prep ebooks at DevOpsInterview.Cloud
