Efficient GitLab Runner capacity comes from measured queue time, job resource profiles, executor isolation, and predictable recovery—not universal savings percentages or fixed jobs-per-instance rules. GitLab has deprecated the Docker Machine executor and plans to remove it in GitLab 20.0, scheduled for May 2027.
Current as of 2026-08-15
GitLab’s Docker Machine documentation directs users toward the Instance or Docker Autoscaler executors. Kubernetes remains a separate supported executor and may be appropriate when an organization already operates that platform.
Decision summary
- Measure workload distributions before choosing instance types or concurrency.
- Plan migration away from Docker Machine before GitLab 20.0.
- Keep runner managers off interruptible capacity and deploy at least two where availability matters.
- Treat Spot savings, cache behavior, and autoscaling values as environment-specific.
Choose the executor first
Instance and Docker Autoscaler separate the runner manager from ephemeral job capacity. Kubernetes schedules jobs as pods and adds cluster-level controls and operational dependencies. Shell or static Docker runners may be simpler for stable trusted workloads but require deliberate isolation and patching.
Build a workload baseline
- Queue duration by project, runner tag, and time of day.
- CPU, memory, disk, network, and job duration percentiles.
- Cache hit rate and cache-transfer time.
- Failure and retry rate, including interruptible-capacity events.
- Provisioning time and idle-capacity cost.
- Sensitive workloads that require dedicated isolation.
Configure the selected executor accurately
GitLab’s advanced configuration reference documents global concurrency and executor-specific settings. Do not copy Docker Machine IdleCount or IdleTime examples into a current autoscaler configuration. Validate configuration against the exact runner version and executor.
Use Spot capacity with explicit failure handling
Interruptible instances can reduce compute cost, but the savings vary by market and interruption rate. Use them for retry-safe jobs, preserve artifacts and caches independently, and keep noninterruptible fallback capacity for critical pipelines.
- Never place the runner manager only on Spot capacity.
- Test interruption and retry behavior.
- Set budget and queue-time alerts.
- Separate untrusted jobs from privileged build paths.
Make efficiency a controlled experiment
Change one capacity policy at a time. Compare queue time, job duration, failure rate, and cost for a defined period. Roll back when user-visible delay or reliability exceeds the agreed threshold.
For related guidance from ITECS, see ITECS Linux IT support.
Sources and update trigger
- GitLab — Docker Machine executor deprecation
- GitLab — Runner autoscaling
- GitLab — Advanced configuration
- GitLab — Kubernetes executor
- GitLab — Fleet scaling
Review trigger: Review on GitLab Runner upgrades, executor deprecation milestones, or a sustained change in queue, failure, or cost data.
continue reading
More ITECS blog articles
About ITECS Team
The ITECS team consists of experienced IT professionals dedicated to delivering enterprise-grade technology solutions and insights to businesses in Dallas and beyond.
View full profile and articles