# 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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/bf61a608-2d7e-49c1-9473-5132d5a95508.png align="center")

### ❓ 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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/c8c0dab7-4cdd-4e94-ac7d-614a483a7576.png align="center")

### ⚙️ 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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/34e2daea-4f25-4111-a2c3-5bc53a38edb1.png align="center")

### 🏛️ 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:

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/138647b4-cc87-4541-b78e-173ee12f8831.png align="center")

## 🧩 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.yml` file.
    

### ☁️ 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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/d2c0ce33-6ab6-4762-8126-269bc667e21b.png align="center")

## 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:

```shell
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:

```shell
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.

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/e5b2d1c5-ff57-43c0-bfb7-c0d110f277d6.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/e5076d84-6643-499e-b8cb-b4a2751d5fc0.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/6083339b-58a1-420e-ae20-34304393ab6d.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/113a3f01-1c9b-4f9c-a2ec-175faf4adba8.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/e58d6daf-791f-4c45-bbae-230a2714b620.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/94ba577b-a252-4553-b614-8a2e9bf3abbd.png align="center")

### 🏷️ Runner Tags

*   What are Runner Tags?
    
*   Why Runner Tags are used
    
*   Assigning tags while registering a runner
    
*   Using tags in `.gitlab-ci.yml`
    
*   Practical example
    

```yaml
build:
  tags:
    - docker
  script:
    - echo "Running on Docker Runner"
```

### 📝 Pipeline Editor

*   What is Pipeline Editor?
    
*   Where to find it
    
*   Creating/editing `.gitlab-ci.yml`
    
*   Validate CI/CD configuration
    
*   Commit changes directly from GitLab
    

### ⚡ Parallel Jobs

Explain that multiple jobs in the same stage can run simultaneously.

```yaml
stages:
  - test

unit_test:
  stage: test
  tags:
    - test
  script:
    - echo "Running Unit Tests"

integration_test:
  stage: test
  tags:
    - test
  script:
    - echo "Running Integration Tests"
```

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/2aaa0d89-bd58-49a8-8ff1-cfed352e9ac7.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/bfbd2710-6c5d-40f1-944d-bfb66b166747.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/21e65f24-53b6-4310-8762-ee84e3e2d82c.png align="center")

![](https://cdn.hashnode.com/uploads/covers/685cdc0d5ca95e55fac3ab09/dfa9dcc5-c1d9-4d71-9096-af3c4fc654b9.png align="center")

## 🎯 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**](mailto:gujjarapurv181@gmail.com)

🌐 **Portfolio:** [**https://www.apurv-gujjar.co.in**](https://www.apurv-gujjar.co.in)

🐙 **GitHub:** [**https://github.com/ApurvGujjar07**](https://github.com/ApurvGujjar07)

💼 **LinkedIn:** [**https://www.linkedin.com/in/apurv-gujjar**](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.