« Blog Home

Fix GitLab CI Minutes Limit: Switch to Private Runners in Minutes (2026 Guide)

March 3, 2026 ¬ 8:40 amh.GitLab Support

Exhausted your GitLab CI minutes on shared runners?
Don’t panic. You can migrate to unlimited private GitLab runners using Docker in under 10 minutes, bypassing shared runner quotas entirely.

Why Switch to GitLab Private Runners Now?

GitLab.com shared runners consume precious CI/CD minutes that run out fast for active projects. Private (self-hosted) runners give you unlimited compute on your own infrastructure without extra costs beyond your hosting. Perfect for DevOps teams hitting limits during heavy testing or CI spikes.

Prerequisites: What You Need

Any server/VM/laptop with Docker installed and internet access to gitlab.com
GitLab project registration token (found in project Settings > CI/CD > Runners)
5-10 minutes of setup time

No Kubernetes or complex infra required for this quick fix.

Step 1: Grab Your GitLab Runner Registration Token

Navigate to your GitLab project: Settings > CI/CD > Runners
Expand New project runner section
Copy the registration token and note the URL (https://gitlab.com/)

For group-level runners (shared across projects), use the group CI/CD settings instead.

Step 2: Spin Up GitLab Runner with Docker (Fastest Method)

On your runner host, run these commands:

# Start persistent GitLab Runner container
docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

docker exec -it gitlab-runner gitlab-runner register \
  --non-interactive \
  --url "https://gitlab.com/" \
  --registration-token "YOUR_TOKEN_HERE" \
  --executor "docker" \
  --description "docker-private-runner" \
  --docker-image "docker:24.0" \
  --docker-volumes "/var/run/docker.sock:/var/run/docker.sock"

This creates a Docker-in-Docker runner using your host’s Docker daemon – ready for most CI workloads immediately.

Step 3: Configure Jobs to Use Private Runner

Option A: Automatic (untagged jobs)

Leave runner without tags
Jobs without tags: in .gitlab-ci.yml will pick it automatically

Option B: Tagged jobs (recommended for control)
Add tags during registration or edit /etc/gitlab-runner/config.toml:

text# In your .gitlab-ci.yml
test-job:
  tags:
    - private
  script:
    - echo "Running on my private runner!"

Step 4: Disable Shared Runners (Stop Minute Consumption)

Critical step! In project Settings > CI/CD > Runners:

Toggle Disable shared runners to ON
Verify your private runner appears as “Available”

Now all pipelines run exclusively on your private capacity. No more CI minute usage.

Step 5: Scale and Optimize

Immediate enhancements:

# Edit config.toml for concurrency
concurrent = 4  # Max parallel jobs

# Add tags for job routing
tags = ["docker", "private", "fast"]

Next level scaling:

Multiple runners on separate hosts
Kubernetes executor for auto-scaling
Machine pools (AWS EC2, GCP, etc.)

Troubleshooting Common Issues

Issue	Solution
Runner shows “offline”	Check Docker container status, network connectivity to gitlab.com
Jobs stuck in “pending”	Verify shared runners disabled, tags match job requirements
Slow performance	Increase VM resources, use SSD storage
Docker permission errors	Ensure `/var/run/docker.sock` mounted correctly

Cost Comparison: Shared vs Private Runners

Type	CI Minutes	Cost	Scalability	Control
Shared	400 free/month or more if using commercial Premium / Ultimate editions or buying extra compute CI minutes	$0-$$	GitLab-managed	Low
Private (Docker VM)	Unlimited	~$10/month	Manual	High (self-hosted)
Autoscaling K8s	Unlimited	$$-$$$	Automatic	Maximum

When to Upgrade Beyond Basic Docker Runner

This Docker setup handles 90% of workloads perfectly. Consider Kubernetes autoscaling when you hit:

10+ concurrent jobs regularly
Variable traffic patterns
Multi-region deployment needs

Pro tip for DevOps pros: Start with Docker runner today, migrate to GitLab Runner Operator on Kubernetes later. Zero pipeline changes required.

Your pipelines will run immediately after disabling shared runners. Need Kubernetes setup instead? Let me know your cluster details.

Our company, ALM Toolbox, has helped hundreds of customers transition to git and GitLab (since 2015) and in supporing GitLab, Docker, Kubernetes, CI/CD and secure development SaaS / self-hosted environments.
We’ve also been partnering with GitLab globally since 2016.
For more details and asking for assistance with GitLab, contact us: gitlab@almtoolbox.com or call us.