Stop paying for idle CI: GitLab Runners on Kubernetes
Scale CI up for Monday peaks, then tear capacity down at night and weekends — the five-minute guide with both walkthrough videos.
Most teams pay for continuous integration as if every night and every weekend were still Monday morning. GitLab Runners on Kubernetes flip that model: spin capacity up when pipelines arrive, then tear it down when the office goes quiet. Read the technical deep dive for Helm values, executor settings and the cost model.
Watch the videos
1. Runners & pipelines — autoscaling GitLab Runner workloads on Kubernetes.
2. GitLab Server on HA Kubernetes — deploy with the Operator in a few minutes.
youtu.be/fu82hENYNEs · Docs: GitLab Operator
The expensive habit
- Daytime: merge requests and tests spike demand.
- Nights: activity drops; fixed VMs still burn CPU and RAM.
- Weekends: often near-idle — yet disks and nodes may still be billed.
You are not paying for builds done. You are paying for capacity that exists whether anyone uses it or not.
A simpler picture
GitLab’s Runner executes pipeline jobs. Kubernetes can create those workers as short-lived pods and delete them when the job finishes. At hyperscale the same idea applies to nodes: more when the queue is deep; fewer — ideally almost none — overnight and at weekends.
Where huge cost savings come from
- Scale up when people (or bots) are working — parallel job pods up to your concurrency and cluster limits.
- Scale down hard when demand disappears — pods go away; with cluster autoscaling, empty nodes leave the pool.
- Stop wasting CPU, RAM and storage on always-on runner fleets during quiet hours.
- Pay for outcomes, not furniture — keep GitLab and a thin runner manager; let the farm evaporate when idle.
Huge savings show up when Monday’s peak no longer dictates Tuesday-at-3am’s bill — and when Saturday’s silence finally looks quiet on the invoice.
Official docs
- Install GitLab Runner with the Helm chart
- Configure the Runner Helm chart
- Kubernetes executor
- Autoscaling GitLab Runner
- GitLab Operator installation
Read next: the hyperscale technical article covers Operator vs Helm tracks, concurrency, DinD, observability and a FinOps checklist. Course build prompt: gitlab-runners-k3s-hyperscale-course.prompt.md in the Workstation website repo (replaces the retired devops.git link).
Published by Workstation.