GitLab CI pricing 2026
./gitlab-ci --free --premium --ultimate
GitLab bundles source control, CI/CD, security scanning, and project management in one product. The CI/CD pricing reflects that: seat fees are higher than competitors, but every plan ships with generous included CI minutes and unlimited self-hosted runners. For mid-to-large teams that want a single tool, GitLab CI is often the cheapest hosted option in real-world bills.
Plan structure / 2026
| Plan | Seat | CI mins / user / month | Self-hosted runners | Highlights |
|---|---|---|---|---|
| Free | $0 | 400 | unlimited | 5 users / namespace |
| Premium | $29 / user | 10,000 | unlimited | Approvals, protected envs |
| Ultimate | ~$99 / user | 50,000 | unlimited | Security scanning, compliance |
# additional minutes: $10 per 1,000 (=$0.01/min) on any paid plan
Cost at typical team sizes
Examples assume Premium plan, Linux shared runners, 21 working days, and that your team's compute usage stays at the listed throughput.
| Team size | Builds / day | Build mins | Mins / month | Included | Total / month |
|---|---|---|---|---|---|
| 5 devs | 30 | 6 | 3,780 | 50,000 | $145 |
| 20 devs | 120 | 8 | 20,160 | 200,000 | $580 |
| 50 devs | 350 | 10 | 73,500 | 500,000 | $1,450 |
| 200 devs | 1,500 | 12 | 378,000 | 2,000,000 | $5,800 |
# All examples stay within Premium included minutes at this throughput. Cost is just seat fees.
Shared vs dedicated runners
GitLab supports three runner types. Shared runners are GitLab-hosted, on by default, billed per CI minute. They're elastic but you don't control the fleet. Group runners live on your infrastructure but are scoped to a GitLab group, useful for teams that want their own pool without per-project setup. Project runners are dedicated to a single project, the simplest self-hosted setup.
Self-hosted runners (group or project) consume zero CI minutes from your allowance. The trade-off is that you own scaling, OS updates, security patches, and runner registration tokens. For predictable workloads this trade is worth it. For bursty PR check traffic, shared runners win.
Tips to keep the bill down
- > Use needs: between jobs to drop unnecessary stages and parallelise the DAG.
- > Set rules: with changes: filters so backend jobs don't run on frontend-only commits.
- > Use cache:fallback_keys to keep partial cache hits when a key changes.
- > Self-host the long tail: nightly integration runs, big monorepo builds, anything that exceeds 30 minutes.
- > Check Compute usage on the namespace settings page weekly. Catch runaway loops before they cost real money.
Compare with other platforms
Frequently Asked Questions
# click any question to expand