GitLab CI-CD

GitLab CI/CD

Definition: GitLab’s built-in CI/CD system, deeply integrated into its all-in-one DevOps platform covering source control, CI/CD, issue tracking, and a container registry together. GitLab itself was created by Dmitriy Zaporozhets in 2011 as an open-source project for managing Git repositories, and CI/CD — originally a semi-separate feature — was folded into the core product in GitLab 8.0 in September 2015, making every GitLab project CI/CD-capable out of the box. That single-application philosophy remains its defining difference from GitHub Actions and Jenkins: the pipeline, the code review, the issue tracker, and the container registry all live in one product rather than being stitched together from separate tools.

Core Services & Concepts

.gitlab-ci.yml — CI/CD pipeline definition file at the root of a repo, describing every stage and job for that project’s pipelines
Stages and jobs — jobs are grouped into ordered stages (commonly build, test, deploy), and jobs within the same stage run in parallel by default
Runners — the agents, written in Go, that execute pipeline jobs; either GitLab-hosted (SaaS) or self-hosted, and registered as shared, group, or project-specific
Auto DevOps — an opinionated, largely automatic CI/CD pipeline GitLab can generate for common project types, detecting the language and assembling build/test/deploy stages automatically
Pipelines — merge request pipelines, branch pipelines, scheduled pipelines, and parent-child pipelines that split a large .gitlab-ci.yml into linked sub-pipelines
CI/CD variables — project-, group-, or instance-level variables, including protected and masked secrets, injected into jobs at runtime
Environments — named deployment targets (staging, production) that GitLab tracks with full deployment history and rollback support
Container Registry — a Docker registry built directly into every GitLab project, commonly the image store a pipeline pushes to and later deploys from
DAG pipelines (needs) — the needs keyword lets a job bypass strict stage ordering and start as soon as its specific dependencies finish, rather than waiting on an entire stage

How It Works: Pipeline/Stage/Job Model & Native Repo Integration

A pipeline is triggered by a repo event — push, merge request, tag, or schedule — and is composed of stages, each a named group of jobs such as build, test, and deploy
Jobs within a stage run in parallel across available runners by default, and the next stage waits for the entire current stage to finish, unless DAG needs overrides that ordering
GitLab Runner executes each job using one of several executors — shell, Docker, Docker Machine, Kubernetes, or SSH — chosen based on how isolated and scalable the job needs to be
Merge request pipelines run against the proposed merge result and surface pass/fail status inline in the merge request UI alongside code review, tightly coupling CI status to review itself
Auto DevOps inspects the repository, selects a matching buildpack, and assembles a full build-test-deploy pipeline without the project needing a hand-written .gitlab-ci.yml at all
Because source control, CI/CD, issue tracking, and the container registry are one product, a pipeline can reference merge request metadata, issue IDs, and registry images without external integration glue

How Pricing Works

GitLab.com’s Free tier includes a monthly allotment of compute minutes for SaaS-hosted runners, enough for small projects and typical open-source work
Premium and Ultimate tiers add more compute minutes, advanced pipeline features like multi-project pipelines and extra approval rules, and — at Ultimate — built-in security and compliance scanning
Self-managed GitLab Community Edition is free and open-source, running CI/CD entirely on the organization’s own infrastructure with unlimited self-hosted runner minutes
Self-managed Enterprise Edition, at Premium or Ultimate, is license-priced per user, aimed at organizations needing GitLab’s advanced features behind their own firewall
Self-hosted runners, whether attached to SaaS GitLab or a self-managed instance, don’t draw down the compute-minute quota since the organization supplies its own compute

Pros

All-in-one platform — source control, CI/CD, issue tracking, and a container registry ship together in one product
Merge request pipelines put CI/CD status directly in the code review flow instead of a separate check to go look up
Mature, deeply configurable pipeline syntax, including DAG ordering, parent-child pipelines, and reusable includes and templates
Auto DevOps gives simple projects a working pipeline with effectively zero hand-written YAML
Strong self-hosted option for teams needing to keep source code and pipelines entirely on their own infrastructure
Built-in container registry and, on paid tiers, security scanning remove the need for several separate third-party tools

Cons

Can feel heavier and more complex than GitHub Actions for a small project that just wants a simple test-on-push pipeline
Self-hosted GitLab instances require real, ongoing maintenance — upgrades, runner scaling, backups — that SaaS-only competitors don’t impose
The most compelling security and compliance features are locked behind the Ultimate tier, a substantial cost step up from Free or Premium
.gitlab-ci.yml syntax, once a project leans on extends, include, and rules conditionals, can become as tangled as any large YAML codebase
Smaller third-party marketplace than GitHub Actions — most integrations are either built-in or maintained by GitLab itself rather than a broad community
Runner executor choice (shell vs Docker vs Kubernetes) carries real security and isolation implications that teams sometimes get wrong early on

Comparison: GitLab CI/CD vs GitHub Actions vs Jenkins

	GitLab CI/CD	GitHub Actions	Jenkins
Hosting model	SaaS (GitLab.com) or self-hosted	SaaS (GitHub-hosted) or self-hosted runners	Self-hosted only, no official SaaS offering
Config format	YAML in a single `.gitlab-ci.yml`	YAML workflows in `.github/workflows/`	Groovy-based Jenkinsfile, or legacy UI jobs
Setup effort	Minimal if the project already lives on GitLab	Minimal if the project already lives on GitHub	Significant — install, configure, and maintain a server
Extensibility	Built-in features plus shareable templates/includes	Marketplace Actions built by the community	Massive plugin ecosystem, roughly 1,800+ plugins
Maintenance burden	Low to medium, higher if self-hosted	Low, GitHub manages hosted runners	High — the team owns the entire server and agent fleet
Pricing model	Free tier plus tiered compute-minute billing	Free public repos, per-minute billing for private	Free and open-source, cost is entirely infra and ops time
Best fit	Teams wanting one all-in-one DevOps platform	Projects already hosted on GitHub	Teams needing maximum customization and full control

Best For

Teams wanting one platform for source control, CI/CD, and project tracking together, especially with self-hosting requirements
Organizations with compliance or on-premises requirements that need CI/CD to stay entirely inside their own infrastructure
Projects that want a working pipeline immediately via Auto DevOps without hand-writing YAML from scratch

Real Examples

GitLab Inc. famously dogfoods its own product, building and releasing GitLab itself entirely on GitLab CI/CD
Widely adopted by large enterprises in regulated industries — finance, government, and defense contractors — that require self-hosted CI/CD
Many organizations migrating off Jenkins cite GitLab CI/CD’s all-in-one platform and merge request integration as the deciding factor

Use Cases

End-to-end DevOps pipelines — build, test, security scan, and deploy — within a single platform and config file
Self-hosted CI/CD for compliance-sensitive organizations that cannot send code or credentials to a third-party SaaS
Review apps — automatically deploying a live, disposable environment per merge request for manual QA before merge
Auto DevOps pipelines for straightforward projects that don’t need custom pipeline logic
Multi-project and parent-child pipelines coordinating deployments across microservices owned by different teams
Container image build-and-publish workflows using the integrated Container Registry as the artifact store

Integration Notes & Common Pitfalls

Choose the runner executor deliberately — shell executors run jobs directly on the host with far less isolation than Docker or Kubernetes executors
Use rules: rather than the deprecated only/except keywords for conditional job execution, since rules is the actively maintained, more expressive syntax
Distinguish artifacts (uploaded and downloadable, retained per policy) from cache (a performance optimization with no durability guarantee) — conflating them causes real pipeline bugs
Mark deployment variables and runners as protected, so they’re only exposed to protected branches and tags, keeping production credentials away from feature-branch pipelines
Break a large .gitlab-ci.yml into included template files once it grows unwieldy, mirroring how large codebases get split into modules
Runner registration tokens are sensitive credentials — a leaked token lets an attacker register a rogue runner capable of intercepting pipeline secrets

Code Example

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - npm ci
    - npm run build

test-job:
  stage: test
  script:
    - npm test

deploy-job:
  stage: deploy
  script:
    - ./deploy.sh production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Code Example: DAG Pipeline With `needs`

build-frontend:
  stage: build
  script: [npm run build:frontend]

build-backend:
  stage: build
  script: [npm run build:backend]

test-frontend:
  stage: test
  needs: [build-frontend]
  script: [npm run test:frontend]

test-backend:
  stage: test
  needs: [build-backend]
  script: [npm run test:backend]

Ecosystem

GitLab Runner — the open-source Go binary that executes pipeline jobs, installable on nearly any OS or as a Kubernetes deployment
Auto DevOps — GitLab’s opinionated, buildpack-driven pipeline generator for projects that don’t need custom CI/CD logic
GitLab Pages — static site hosting built directly into the platform, commonly deployed as the final stage of a documentation pipeline
GitLab Container Registry — the built-in Docker registry every project gets by default, tightly integrated with pipeline push/pull credentials
CI/CD templates — GitLab-maintained, include-able pipeline templates for common languages and deployment targets, reducing hand-written YAML

Best Practices

Use merge request pipelines rather than plain branch pipelines where possible, so CI status reflects the actual merge result, not just the source branch alone
Cache dependency directories (node_modules, .m2, etc.) explicitly, since GitLab’s cache is keyed and scoped rather than automatic
Adopt DAG ordering with needs once a pipeline’s strict stage sequencing starts adding unnecessary wait time between independent jobs
Keep secrets in masked, protected CI/CD variables rather than committed into .gitlab-ci.yml, even inside a private repository
Split shared pipeline logic into included templates so multiple projects or teams aren’t maintaining near-duplicate YAML
Right-size runner executors per workload — Kubernetes executors for elastic scaling, shell executors only for trusted, low-risk jobs

FAQ

Is GitLab CI/CD free? Yes — GitLab.com’s Free tier includes a monthly compute-minute allowance for SaaS runners, and self-managed Community Edition is free and open-source with unlimited self-hosted runner capacity.

Do I need a separate CI tool if I’m already using GitLab for source control? No — CI/CD has been a core, built-in part of GitLab since it merged into the main product in GitLab 8.0, so no separate installation or integration is required.

What is Auto DevOps? An opinionated pipeline GitLab can generate automatically by detecting a project’s language and structure, producing working build, test, and deploy stages without a hand-written .gitlab-ci.yml.

How does GitLab CI/CD compare to GitHub Actions? Both are YAML-based and tightly integrated with their respective platform’s repository events, but GitLab CI/CD is one piece of a broader all-in-one DevOps platform, while GitHub Actions leans on a more marketplace-driven, action-composition model.

Can GitLab CI/CD deploy to Kubernetes? Yes, natively — GitLab has long-standing built-in Kubernetes integration for deploying pipeline output directly to a cluster, including through Auto DevOps.

Common Interview Questions

“What’s the difference between a GitLab pipeline stage and a job?” — expect stages described as ordered groups and jobs as the actual units of work running in parallel within a stage
“How would you speed up a GitLab pipeline with many independent jobs?” — expect a discussion of DAG pipelines using needs instead of strict stage-by-stage waiting
“What’s the difference between artifacts and cache in GitLab CI/CD?” — expect artifacts as durable, downloadable outputs and cache as a best-effort performance optimization
“How do you keep production secrets safe in a GitLab pipeline?” — expect protected variables scoped to protected branches, plus masked variables to keep values out of job logs

History

GitLab was created by Dmitriy Zaporozhets in 2011 as an open-source project, initially built to manage his own team’s Git repositories
Sid Sijbrandij joined shortly after and became CEO, taking the project through Y Combinator in 2015 and scaling it into a company
CI/CD, originally a semi-separate feature, was merged into GitLab’s core product in GitLab 8.0 in September 2015, making every GitLab project CI/CD-capable by default
Grew through the later 2010s around a “single application for the DevOps lifecycle” positioning, adding security scanning, package registries, and more
GitLab Inc. went public on Nasdaq via direct listing in October 2021
Continues expanding Auto DevOps, built-in security scanning, and AI-assisted features across the platform

Referenced by

Dig deeper

Spot an error in this note?