Tool Intelligence Profile

GitLab CI

GitLab’s built-in CI/CD: .gitlab-ci.yml pipelines, shared compute minutes, and self-hosted GitLab Runner for SaaS or self-managed.

general freemium 0

Pricing

Contact Sales

freemium

Category

general

0 features tracked

Overview

GitLab CI/CD is the continuous integration and delivery engine built into GitLab — the DevSecOps platform from GitLab Inc. You define pipelines in a repository-rooted .gitlab-ci.yml, jobs run on GitLab Runner (shared instance runners on GitLab.com, or your own project/group/instance runners), and results surface next to merge requests, environments, and security reports. Official docs live at docs.gitlab.com/ci; product positioning is on about.gitlab.com.

Unlike bolt-on CI that only talks to a repo host, GitLab CI is first-party: pipelines, registry, package registry, review apps, deployment environments, and (on higher tiers) security scanning and merge trains share one auth model and UI. It runs on GitLab.com (SaaS), Self-Managed, and GitLab Dedicated (single-tenant SaaS). That self-host path is a core reason teams pick GitLab CI over pure GitHub Actions when data residency or air-gapped control matter.

On GitLab.com, shared-runner usage is billed in compute minutes. Free namespaces get 400 minutes/month; Premium includes 10,000; Ultimate includes 50,000. Bring-your-own runners do not consume that quota.

In practice, “GitLab CI” means three things people mix up: (1) the YAML pipeline language and job model, (2) Runner executors (Docker, Kubernetes, shell, etc.), and (3) the GitLab.com hosted minutes product. Self-managed GitLab + private runners can be free of shared-minute pressure entirely; SaaS Free users often hit 400 minutes quickly and either add runners or buy packs at $10 per 1,000 minutes.

Key features

  • .gitlab-ci.yml pipelines — Stages, jobs, rules/only/except, needs/DAG, parallel matrix, artifacts, caches, services (e.g. Docker-in-Docker, Postgres), environments, and release jobs. Full keyword reference is maintained in the YAML syntax docs.
  • GitLab Runner — Open agent that polls for jobs. Executors include Docker, Kubernetes, shell, custom, and virtualbox/parallels for specialized OS images. Autoscaling and fleets are well documented for cloud VM and k8s clusters.
  • Hosted runners on GitLab.com — Shared Linux (x86-64 and Arm64) sizes with cost factors (small = 1×, medium = 2×, large = 3×, up through 2xlarge = 12×). Windows and macOS runners exist in beta with higher cost factors; GPU Linux medium is listed at 7×.
  • CI/CD components & Catalog — Reusable pipeline units versioned like software, discoverable in the CI/CD Catalog (GA path since the 17.x line). Prefer components over copy-pasted include: soup for multi-team platforms.
  • Includes, templates, parent-child & multi-project pipelines — Split monorepos into child pipelines; trigger downstream projects for microservices; share templates across groups.
  • Merge request pipelines, merged results, merge trains — Test the post-merge tree before merge; trains serialize merges to reduce “broken main” races (Premium+ features for advanced MR governance are tier-gated).
  • Artifacts & reports — JUnit, coverage, code quality, SAST/dependency/container scan report types that decorate MRs when tier allows full security UX.
  • Variables, protected environments, approvals — Scoped CI variables, protected branches/environments, and Premium-level MR approval rules for production gates.
  • Auto DevOps & review apps — Opinionated defaults for build/test/deploy; ephemeral environments for MRs when cluster/integration is set up.
  • Container & package registries — Build once in CI, push to GitLab’s registry without a separate SaaS token matrix (storage limits still apply on.com).
  • Duo / agentic CI helpers — Paid Duo Agent Platform (GitLab Credits) includes flows such as pipeline fix and CI modernization; not required for core CI, and billed separately from compute minutes.

Tip: Treat self-hosted runners as the default cost control. Shared minutes are for convenience and burst; heavy Docker builds, e2e, and monorepos almost always pay less on private runners than on shared compute with multi-× cost factors.

Pricing

GitLab CI itself is not a separate SKU: you pay for a GitLab plan (seats on SaaS or license on Self-Managed) plus optional compute minutes and storage on GitLab.com. Figures below match GitLab’s public pricing page as of mid-2026 (always re-check about.gitlab.com/pricing).

GitLab.com seats & included compute

Plan List price Compute minutes / month Storage (repo + LFS) CI-relevant notes
Free $0 400 10 GiB Built-in CI/CD; 5 licensed users on private top-level groups; card may be required to use shared runners (abuse controls)
Premium $29 / user / month (annual) 10,000 500 GiB / project (fixed ceiling) Advanced CI/CD, priority support, protected environments / richer MR controls; Duo credits promotional pool listed on pricing
Ultimate Custom (sales) 50,000 500 GiB / project Security dashboards, policies, full AppSec product UX; OSS/edu/startup programs can grant Ultimate + 50k minutes when eligible

Compute overage & self-hosted

  • Extra compute minutes: $10 per 1,000 minutes, one-time purchase, valid up to 12 months or until consumed (see compute-minutes FAQ).
  • Self-hosted / project / group runners: do not burn the namespace compute quota; you pay your own cloud/on-prem cost only.
  • Cost factors: a 10-minute job on a large Linux runner (3×) costs 30 compute minutes. Matrix jobs multiply fast — plan quotas accordingly.
  • Quota scope: minutes are per top-level namespace/group, not multiplied by seat count.
  • Self-Managed / Dedicated: no GitLab.com shared-minute product; admin can enable instance-runner quotas if desired.

Related add-ons (not CI minutes)

  • Storage packs: extra Git/LFS storage (e.g. listed around $5/month per 10 GiB on public pricing — verify live).
  • GitLab Credits / Duo Agent Platform: usage-priced AI agents/flows ($1 per credit on-demand list); separate from CI compute.
  • GitLab Flex: annual commit that can rebalance seats and credits — sales-assisted.

Gotcha: Free’s 400 shared minutes is enough for light personal projects. Active teams on SaaS without private runners burn through Free in days. Premium’s 10k minutes still evaporates under large parallel matrices or macOS/GPU cost factors — measure before you assume “Premium = unlimited CI.”

Limits & gotchas

  • Free shared minutes are tight — 400/month is the long-standing Free cap; crypto-mining abuse led to card verification for shared runners.
  • Minutes ≠ wall-clock — Concurrent jobs each consume minutes; cost factors scale larger machine types.
  • YAML complexity debt — Anchors, extends, nested includes, and rules interact poorly without discipline; many teams push logic into scripts/Makefiles and keep YAML thin.
  • Shared runner queue/performance variance — Hosted capacity can queue under load; latency-sensitive deploys often move to dedicated runners.
  • Docker-in-Docker & privileged mode — Common for builds but a security footgun on multi-tenant runners; prefer Kaniko/Buildah or Kubernetes executor patterns where possible.
  • Security feature tiering — Basic scanners may run on lower tiers as artifacts; full vulnerability management, policies, and MR security UX are Ultimate-centric.
  • Storage vs registry — Purchased repo storage does not magically expand container registry economics the same way; watch both.
  • Self-Managed ops cost — You own upgrades, Runner fleets, HA, and backup. CI “free minutes” trade for platform engineering time.
  • Debugging loops — Job logs are good; interactive debug is weaker than some competitors unless you invest in local pipeline tools and thin YAML.
  • Lock-in via platform depth — Environments, registry, security reports, and MR integrations make “just the CI YAML” migrations incomplete.

Community sentiment

On Hacker News and Reddit (r/gitlab, r/devops), GitLab CI is repeatedly called one of the stronger pipeline models — especially Docker image-per-job, Kubernetes executor, and monorepo parent-child patterns — while GitHub Actions wins mindshare for marketplace actions, OSS defaults, and “already on GitHub.” Common praise: Runner is portable; config lives with the repo; self-hosted minutes are truly free of the SaaS meter.

Common complaints: Free 400 minutes feel punitive; Premium seat price ($29/user/mo annual list) makes CI-only buyers look at Actions or Buildkite; large .gitlab-ci.yml files become unmaintainable; occasional surprising YAML/rules behavior; SaaS UI performance debates that spill onto CI UX. 2025–2026 discussion also contrasts GitLab’s free self-hosted runners with GitHub’s announced platform fees for self-hosted Actions usage — many threads treat that as a migration talking point, not a pure feature comparison.

Community rule of thumb: if the team already lives in GitLab (MRs, issues, registry), CI is a strength. If the team only wants a CI sidecar for GitHub repos, Actions or a specialist CI usually wins on ecosystem and seat cost.

Who should use it

  • Teams already on GitLab for source control, MRs, and package/container registry — CI is the path of least resistance.
  • Orgs that must self-host or air-gap the control plane and runners (regulated industries, public sector, strict data residency).
  • Platform teams standardizing CI via components/catalog across many groups with shared templates and policy.
  • Monorepos needing parent-child pipelines and fine-grained rules:changes fan-out.
  • Heavy Docker/Kubernetes CI where custom executors and private fleets dominate cost math.
  • Not ideal as a pure “CI for GitHub only” buy if you do not want GitLab as the system of record — seat cost and dual-tool friction add up.
  • Not ideal on Free SaaS shared runners for busy commercial products without private runners or minute packs.

Alternatives

  • GitHub / GitHub Actions — Default when code already lives on GitHub; large Actions marketplace; compare minutes and self-hosted runner policy carefully.
  • GitLab (full platform) — Same company; evaluate seats, Duo, and AppSec tiers as a platform decision, not CI alone.
  • Jenkins — Maximum plugin flexibility and on-prem control; higher maintenance and weaker modern SaaS DX.
  • CircleCI — Strong hosted performance and insights; separate product from your forge.
  • Buildkite — Hybrid model: hosted control plane, agents in your cloud; popular for scale and compliance.
  • Bitbucket Pipelines — Natural fit inside Atlassian; smaller ecosystem than GitLab/GitHub CI.
  • Azure DevOps Pipelines — Enterprise Microsoft shops; boards + repos + pipelines bundle.
  • Tekton / Argo-centric stacks — Kubernetes-native CD; more assembly required, less “batteries included” forge.

Verdict

GitLab CI/CD remains a first-class, forge-integrated CI with a mature YAML model, excellent self-hosted Runner story, and real monorepo/downstream pipeline depth. Pricing pain on GitLab.com is almost always shared compute minutes + seats, not the Runner binary. If you can run private runners (or Self-Managed), CI cost collapses to infrastructure you already understand; if you rely only on Free/Premium shared minutes with large machine cost factors, bills and quota anxiety rise fast.

Choose GitLab CI when GitLab is (or must be) your DevOps system of record — especially self-hosted or regulated environments. Choose something else when you only need CI next to GitHub and will never use GitLab’s broader platform. Re-verify seat prices, included minutes, and Duo credit promotions on the official pricing page before budgeting; this profile reflects public list terms observed in 2026 research, not a sales quote.

Head-to-Head

Compare GitLab CI Side-by-Side