Skip to content
DevOps Platform

GitLab Releases

Track GitLab releases, CE vs EE feature comparison, major version upgrade paths, Runner compatibility, and breaking changes per release.

Total Versions

Supported

Latest

Version Timeline

All tracked releases with lifecycle status and EOL dates.

Loading version data…

Lifecycle Timeline

Visual overview of active support and maintenance windows.

16.0
16.6
16.11
17.0
17.6
17.9
17.11
18.0
2023 2024 2025 2026 2027 2028
Active
Maint
Active
Maint
Active
Maint
Active
Maint
Active
Maint
Active
Maint
Active
Maint
Active
Maint
Active / LTS
Maintenance
Today

Upgrade Paths

Migration guidance between major versions — breaking changes, effort estimates, and tips.

16.x 17.0 High Difficulty
Est. 4-8 hours for self-managed (with stops)

Breaking Changes

  • Required stop versions: must hit 16.3, 16.7, 16.11 first
  • All background migrations from 16.x must complete
  • Deprecated API endpoints removed
  • CI/CD component syntax changes
  • Elasticsearch 8 / OpenSearch 2 required (was ES 7)
  • Removed legacy project integrations
  • Database schema changes (irreversible)

Migration Notes

Major version upgrades are the riskiest GitLab operation. Follow the documented upgrade path exactly. Check background migrations at /admin/background_migrations before each stop. Plan for 2-4 hours of downtime for large instances (100K+ projects). Take a database backup before starting. Test on a staging instance first.

17.x (minor to minor) 17.x+1 Low Difficulty
Est. 30-60 minutes

Breaking Changes

  • Minor feature deprecations
  • Possible CI/CD keyword additions
  • Runner compatibility within 1 minor version

Migration Notes

Monthly minor upgrades are designed to be safe. Update, run database migrations, restart. Check /admin/background_migrations and let them complete before the next upgrade. Upgrade Runners after the instance.

Version Risk Assessment

Evaluate risk factors before choosing a version for production.

Version EOL Risk CVE Risk Ecosystem Cloud Support Overall Recommended Action
GitLab 15.x and older Critical Critical Dead None Critical Severely outdated — multiple required stop upgrades needed
GitLab 16.x Critical High Unsupported None Critical Past EOL — upgrade through 17.0
GitLab 17.0-17.6 High High Unsupported Degrading High Past support window — upgrade to latest
GitLab 17.9-17.10 Medium Low Supported Full Medium Within support — upgrade when possible
GitLab 17.11 / 18.0 None Low Active Full Low Current — recommended

GitLab supports only the latest 3 minor versions with patches. Older versions get no security fixes. Monthly release cadence means you can fall behind quickly. Assessed March 2026.

GitLab Version Feature Comparison

Side-by-side feature differences across major versions.

Feature 16.0 16.11 17.0 17.6 17.11
CI/CD Components Beta Stable Stable Enhanced Enhanced
GitLab Duo (AI) No Beta Beta GA Enhanced
VS Code Web IDE Beta Stable Stable Stable Stable
Container scanning Trivy Trivy Trivy Enhanced Enhanced
Dependency scanning Gemnasium Gemnasium Enhanced Enhanced Enhanced
Required stop for upgrade N/A Yes Yes No Yes (for 18.0)
Runner min version 15.x 16.9+ 16.11+ 17.4+ 17.9+
PostgreSQL minimum 13 14 14 14 16
Elasticsearch/OpenSearch ES 7/OS 1 ES 7/OS 2 ES 8/OS 2 ES 8/OS 2 ES 8/OS 2

Embed Badges

Add live GitLab status badges to your README, docs, or dashboard.

Health Status

Overall support health

GitLab Health Status
![GitLab Health Status](https://img.releaserun.com/badge/health/gitlab.svg)

EOL Countdown

Next end-of-life date

GitLab EOL Countdown
![GitLab EOL Countdown](https://img.releaserun.com/badge/eol/gitlab.svg)

Latest Version

Current stable release

GitLab Latest Version
![GitLab Latest Version](https://img.releaserun.com/badge/v/gitlab.svg)

CVE Status

Known vulnerabilities

GitLab CVE Status
![GitLab CVE Status](https://img.releaserun.com/badge/cve/gitlab.svg)

Frequently Asked Questions

Common questions about GitLab releases and lifecycle.

How does GitLab versioning work?
GitLab releases monthly on the 3rd Thursday. Each release gets a minor version bump (17.0, 17.1, 17.2). Patch releases come out as needed for security and bug fixes. Each minor release is supported for the current month plus 2 additional months (3 months total). Only the latest 3 minor versions receive patches.
What is the difference between GitLab CE and EE?
CE (Community Edition) is open-source and free. EE (Enterprise Edition) includes all CE features plus premium features (advanced CI, security scanning, compliance, project management). EE is what gitlab.com runs and what self-managed premium/ultimate tiers use. Since 2019, CE and EE share the same codebase; EE features are simply gated behind license checks.
How do I upgrade GitLab safely?
GitLab requires sequential upgrades through specific "required stop" versions. You cannot skip major versions. For example, to go from 15.x to 17.x, you must stop at 15.11.13 → 16.0.x → 16.3.x → 16.7.x → 16.11.x → 17.0.x → 17.3.x → latest. Skipping required stops causes database migration failures. Always check the upgrade path tool at docs.gitlab.com/ee/update/upgrade_paths.html.
How do GitLab Runners version compatibility work?
Runners should be the same minor version as the GitLab instance, or one minor version behind. Runners more than one minor version ahead or behind may have compatibility issues. When upgrading GitLab, upgrade the instance first, then upgrade Runners. GitLab.com Runners are always up-to-date.
Should I self-host GitLab or use gitlab.com?
Self-hosting gives you data sovereignty, network isolation, and custom configuration. gitlab.com gives you zero maintenance, automatic updates, and included CI minutes. For teams under 100 developers without strict compliance requirements, gitlab.com Free or Premium is simpler. For regulated industries, air-gapped environments, or large enterprises, self-hosted EE is the standard choice.
What are GitLab's major version upgrade risks?
Major versions (15→16, 16→17) remove deprecated features and make database schema changes that cannot be rolled back. The biggest risks are: background migrations that must complete before upgrading, Elasticsearch/OpenSearch reindexing requirements, and breaking changes to CI/CD syntax or API endpoints. Always read the breaking changes list and complete all background migrations before each required stop.

Related Tools

Browse All Version History