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 Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.