GitLab Runners – A Complete Guide

If you’re using GitLab SaaS (GitLab Cloud), you have multiple runner options to execute your CI/CD jobs. Each runner source gives you different levels of control, performance, and cost efficiency.

Here’s a complete and up-to-date list of runner sources available to you on GitLab Cloud (GitLab.com) as of version 18.0 (May 2026):

✅ Available Runner Sources in GitLab Cloud

🔧 Summary of Executors by Runner Type

📌 Special GitLab SaaS-Hosted Runners

🎯 When to Use What

✅ How to View/Add Runners in GitLab Cloud

• Project > Settings > CI/CD > Runners
  • Shows shared runners, and allows adding project-specific ones
• Group > Settings > CI/CD > Runners
  • For group-level runners
• Admin Runners Page (for instance-level visibility, GitLab self-managed only)

As of GitLab 18.x, GitLab supports several types of runners to execute CI/CD jobs. Here’s a clear and updated breakdown:

🏃 Types of GitLab Runners in GitLab 18.x

1. Shared Runners

• Scope: Available to all projects in an instance or group.
• Managed by: GitLab instance admin (self-hosted or GitLab.com).
• Use case: Ideal for teams that don’t want to manage infrastructure for builds.
• Example: GitLab.com provides autoscaling shared runners using Docker Machine.

✅ Pros:

• Easy to set up
• Great for small teams and quick pipelines
  ⚠️ Cons:
• Queues can be long on GitLab.com during peak usage

2. Group Runners

• Scope: Available to all projects within a group.
• Managed by: Group owners
• Use case: For teams managing multiple related projects needing the same CI resources.

✅ Pros:

• Centralized control at group level
• Avoids redundancy for project-specific runners

3. Project-specific Runners

• Scope: Tied to a single project only.
• Managed by: Project maintainers/owners
• Use case: When a project needs specialized tools or secure execution.

✅ Pros:

• Full control
• Secure, isolated builds
  ⚠️ Cons:
• More setup and maintenance overhead

🔧 Execution Environments (Runners’ Executor Types)

Each runner (regardless of shared/group/project) uses an executor to determine how jobs are run:

🧠 Special Note on GitLab SaaS vs Self-Managed

GitLab.com (SaaS) does not support Group-level runners for security/resource isolation reasons.

🔄 Registering a Runner

To register a runner in GitLab 18.0, follow these steps:GitLab Docs

1. Install GitLab Runner: Ensure GitLab Runner is installed on your desired host machine.
2. Obtain a Registration Token:
   • Instance Runner: Available in the Admin Area under CI/CD > Runners.
   • Group Runner: Found in the group’s Settings > CI/CD > Runners section.
   • Project Runner: Located in the project’s Settings > CI/CD > Runners section.
3. Register the Runner:
   • Run the following command and follow the prompts:about.gitlab.com+6GitLab Docs+6GitLab Forum+6GitLab Docs+2GitLab Docs+2GitLab Docs+2GitLab Docs+1Exoscale+1 bashCopyEditgitlab-runner register
   • Provide the GitLab instance URL, registration token, description, tags, and executor type as prompted.GitLab Docs

After successful registration, the runner will appear in the GitLab UI under the appropriate scope (instance, group, or project). GitLab Docs

Rajesh Kumar

I’m a DevOps/SRE/DevSecOps/Cloud Expert passionate about sharing knowledge and experiences. I have worked at Cotocus. I share tech blog at DevOps School, travel stories at Holiday Landmark, stock market tips at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow , and SEO strategies at Wizbrand.

Do you want to learn Quantum Computing?

Please find my social handles as below;

Rajesh Kumar Personal Website
Rajesh Kumar at YOUTUBE
Rajesh Kumar at INSTAGRAM
Rajesh Kumar at X
Rajesh Kumar at FACEBOOK
Rajesh Kumar at LINKEDIN
Rajesh Kumar at WIZBRAND

Rajesh Kumar DailyLogs