Day 5 : GitLab Runners & Pipeline Execution
Learn GitLab Runners, Hosted vs Self-Hosted Runners, Runner Registration, Tags, Pipeline Editor & Parallel Jobs
📖 Introduction
In the previous article, we created our first GitLab CI/CD pipeline and learned how pipelines, stages, and jobs work.
But one important question remains:
Who actually executes these pipeline jobs?
The answer is GitLab Runner.
A GitLab Runner is responsible for executing the jobs defined in your .gitlab-ci.yml file. Whenever a pipeline is triggered, GitLab assigns the jobs to an available runner, which performs the required tasks and reports the results back to GitLab.
In this article, you'll learn how GitLab Runners work, the difference between Hosted and Self-Hosted Runners, how to register a runner, use runner tags, and optimize pipelines with parallel jobs.
🎯 What You'll Learn
After completing this article, you'll understand:
✅ What is a GitLab Runner?
✅ Why GitLab Runners are Required
✅ How GitLab Runners Work
✅ GitLab Runner Architecture
✅ Hosted Runner vs Self-Hosted Runner
✅ Registering a GitLab Runner
✅ Runner Tags
✅ Pipeline Editor
✅ Parallel Jobs
📚 Prerequisites
Before continuing, make sure you have:
A GitLab account
A GitLab repository
A working GitLab CI/CD pipeline (Day 4)
Basic knowledge of Git and GitLab
🚀 What is a GitLab Runner?
A GitLab Runner is an application that executes the jobs defined in your .gitlab-ci.yml file.
Whenever a pipeline is triggered, GitLab sends the job to an available runner. The runner executes the commands, collects the results, and sends the status back to GitLab.
Without a GitLab Runner, a pipeline cannot execute any jobs.
❓ Why Do We Need a GitLab Runner?
GitLab is responsible for creating and managing pipelines, but it does not execute the jobs itself.
Whenever a pipeline is triggered, GitLab sends each job to an available GitLab Runner. The runner then executes the commands defined in the .gitlab-ci.yml file and returns the results to GitLab.
Without a runner, the pipeline will remain in a Pending state because there is no machine available to execute the jobs.
⚙️ How GitLab Runner Works
Whenever a developer pushes code, GitLab creates a pipeline based on the .gitlab-ci.yml file. It then assigns each job to an available GitLab Runner.
The runner executes the job, collects the output, and sends the execution status back to GitLab. The pipeline is updated automatically with the job results.
🏛️ GitLab Runner Architecture
GitLab Runner works as a bridge between GitLab and the machine where your jobs are executed.
When a pipeline is triggered, GitLab sends the job to an available runner. The runner uses an Executor (such as Docker or Shell) to execute the job and then sends the results back to GitLab.
The architecture looks like this:
🧩 Components of the Architecture
GitLab Server → Creates and manages pipelines.
GitLab Runner → Receives and executes jobs.
Executor → Runs the job using Docker, Shell, Kubernetes, or another supported environment.
Job → The commands defined in the
.gitlab-ci.ymlfile.
☁️ Hosted Runner vs Self-Hosted Runner
GitLab provides two types of runners to execute CI/CD jobs: Hosted Runners and Self-Hosted Runners.
The main difference is where the runner is managed.
Hosted Runners are managed by GitLab, so you don't need to install or maintain them.
Self-Hosted Runners are installed and managed by you on your own infrastructure, such as a Virtual Machine, physical server, or Kubernetes cluster.
📊 Hosted Runner vs Self-Hosted Runner
| Feature | Hosted Runner | Self-Hosted Runner |
|---|---|---|
| Managed By | GitLab | You |
| Setup Required | No | Yes |
| Infrastructure | GitLab | Your Server / VM |
| Maintenance | GitLab | You |
| Custom Software | Limited | Full Control |
| Best For | Small projects & beginners | Production & enterprise projects |
🚀 Hosted Runner
Hosted Runners are ready to use and require no installation. GitLab automatically provisions the infrastructure needed to execute your pipeline jobs.
They are ideal for learning GitLab, personal projects, and small teams.
🖥️ Self-Hosted Runner
A Self-Hosted Runner is installed on your own machine or server. It gives you complete control over the execution environment, allowing you to install custom tools, access private networks, and optimize performance.
Most production environments use Self-Hosted Runners because they offer greater flexibility and security.
💼 Real-World Example
A startup building a portfolio website may use Hosted Runners because they're simple to set up.
A company deploying applications to a private Kubernetes cluster or AWS environment typically uses Self-Hosted Runners to securely access internal resources and customize the execution environment.
🛠️ Registering a GitLab Runner
To use a Self-Hosted Runner, you first need to register it with your GitLab project. During registration, the runner connects to GitLab and becomes available to execute pipeline jobs.
Step 1: Install GitLab Runner
Install GitLab Runner on your Linux server by following the official installation steps for your operating system.
Step 2: Get the Registration Token
In your GitLab project, navigate to:
Settings → CI/CD → Runners
Copy the Runner Authentication Token (or registration token, depending on your GitLab version).
Step 3: Register the Runner
Run the following command on your server:
sudo gitlab-runner register
During registration, you'll be asked to provide:
GitLab instance URL
Runner Authentication Token
Runner name
Executor (Docker, Shell, Kubernetes, etc.)
After successful registration, the runner will appear in your project's Runners section.
🏷️ Runner Tags
What are Runner Tags?
Why Runner Tags are used
Assigning tags while registering a runner
Using tags in
.gitlab-ci.ymlPractical example
build:
tags:
- docker
script:
- echo "Running on Docker Runner"
📝 Pipeline Editor
What is Pipeline Editor?
Where to find it
Creating/editing
.gitlab-ci.ymlValidate CI/CD configuration
Commit changes directly from GitLab
⚡ Parallel Jobs
Explain that multiple jobs in the same stage can run simultaneously.
stages:
- test
unit_test:
stage: test
tags:
- test
script:
- echo "Running Unit Tests"
integration_test:
stage: test
tags:
- test
script:
- echo "Running Integration Tests"
🎯 Summary
Congratulations! 🎉 You have completed Day 5 of the GitLab learning series.
In this article, you learned how GitLab Runners execute CI/CD jobs, explored Runner Architecture, compared Hosted and Self-Hosted Runners, registered your first Self-Hosted Runner, configured Runner Tags, and executed jobs in parallel.
👨💻 About the Author
Hi, I'm Apurv Gujjar, a DevOps Engineer passionate about Cloud, AWS, Kubernetes, Docker, Terraform, GitLab, and Infrastructure Automation.
I share practical DevOps tutorials, real-world projects, certification guides, interview preparation, and cloud engineering best practices to help students and professionals build production-ready skills.
📬 Connect With Me
📧 Email: gujjarapurv181@gmail.com
🌐 Portfolio: https://www.apurv-gujjar.co.in
🐙 GitHub: https://github.com/ApurvGujjar07
💼 LinkedIn: https://www.linkedin.com/in/apurv-gujjar
If you enjoy DevOps, Cloud, and GitLab content, feel free to connect with me. I'm always happy to share knowledge and discuss modern cloud technologies.
