3 min read6 days ago

–

Press enter or click to view image in full size

GitLab Runners Workflow

If you are learning GitLab CI/CD, one term you will hear again and again is GitLab Runner. Many people understand pipelines, YAML files, and stages but still feel confused about what a runner really does and how things actually execute behind the scenes.

In this article I will try to explain GitLab Runners in a simple way, using simple language, real-life analogies, and practical flow so that even beginners can clearly visualize what’s happening.

The Big Picture (Before We Go Deep)

Let’s start with the most important idea: GitLab does NOT build, test, or deploy your code by itself. It only stores your code , reads your pipeline configuration, and shows results in the UI. The actual work is done by GitLab Runners.

A Real-Life Analogy

Imagine a factory: • GitLab is the manager • GitLab Runner is the worker • .gitlab-ci.yml is the instruction manual

The manager says: > “Build this application” > “Run tests” > “Deploy to production”. But the manager doesn’t touch tools or machines. The workers (runners) do the real job. Hence, no workers = no work.

What Exactly Is a GitLab Runner?

A GitLab Runner is a small program, installed on a machine (VM, server, container, or Kubernetes) that connects to GitLab , waits for CI/CD jobs, and executes commands step by step. Think of it as a robot that follows instructions without thinking.

Why GitLab Needs Runners?

GitLab itself cannot compile code, run tests, build Docker images, and even deploy applications. Because these tasks require CPU, RAM, Operating system, Network access, etc. GitLab Runners provide these resources for any jobs to complete.

How GitLab CI/CD Works (Step-by-Step)

Let’s walk through the full flow in simple terms.

Step 1: You Push Code

git push origin main

Step 2: GitLab Reads .gitlab-ci.yml

Example:

build: script: — npm install — npm run build

Get Bibek Sitaula’s stories in your inbox

Join Medium for free to get updates from this writer.

GitLab understands that “Someone needs to run these commands”

Step 3: GitLab Searches for a Runner

GitLab asks: “Is there any runner available?” An idle runner replies: “Yes, I can do this job.”

Step 4: Runner Executes the Job

The runner then downloads your code, prepares the environment, runs commands exactly as written.

npm install npm run build

Runner just executes the code as written without any guessing or intelligence involved.

Step 5: Runner Reports Back

No the runner sends logs, whether the job is successful or failed. GitLab simply displays the result.

Types of GitLab Runners

1. Shared Runners • Provided by GitLab • Used by many projects • Limited customization Like using public transport

2. Specific Runners • Dedicated to a single project • Installed and managed by you • Faster and more secure Like owning your own car

3. Group Runners • Shared across a group of projects Like company transport

Runner Registration (Briefly)

Each runner is registered using a token: gitlab-runner register The runner then knows which GitLab instance to talk to, which project or group it belongs to.

Why Runners Matter in Production

Well-designed runner setup gives you faster pipelines, better security, isolation between jobs, and scalable CI/CD. Poor runner design causes slow builds, random failures, and security risks.

To Summarize

• GitLab — — — — — → Brain • Runner — — — — → Hands •** .gitlab-ci.yml** — — — — — → Instruction manual • Executor — — — — — — -> Tools

GitLab Runner is an agent that executes CI/CD jobs by fetching code from GitLab, running pipeline instructions in a defined environment, and reporting results back to GitLab.

If this helped you, feel free to share it with your team or fellow DevOps learners.