GitLab 17.0 shipped with 80 breaking changes. GitLab 18.0 had 27. The upcoming GitLab 19.0 release is projected to include 15.
We know that managing breaking changes across a major upgrade is time-consuming: It requires investigation and coordination across your organization. In response, we introduced a breaking change approval requirement that mandates impact mitigation and leadership sign-off before any breaking change can proceed. That process is working, and we're committed to continuing to drive that number down.
Below you'll find every breaking change in GitLab 19.0, organized by deployment type and impact, alongside the mitigation steps you need to upgrade with confidence.
Deployment windows
Here are the deployment windows you need to know.
GitLab.com
Breaking changes for GitLab.com will be limited to these two windows:
- May 4–6, 2026 (09:00–22:00 UTC) — primary window
- May 11–13, 2026 (09:00–22:00 UTC) — contingency fallback
Many other changes will continue to roll out throughout the month. You can learn more about the breaking changes occurring within each of these windows in the breaking changes documentation.
Note: Breaking changes may fall slightly outside of these windows in exceptional circumstances.
GitLab Self-Managed
GitLab 19.0 will be available starting on May 21, 2026.
Learn more about the release schedule.
GitLab Dedicated
The upgrade to GitLab 19.0 will take place during your assigned maintenance window. You can learn more and find your assigned maintenance window in your Switchboard portal. GitLab Dedicated instances are kept on release N-1, so the upgrade to GitLab 19.0 will take place in the maintenance window during the week of June 22, 2026.
Visit the Deprecations page to see a full list of items scheduled for removal in GitLab 19.0. Read on to learn what's coming and how to prepare for this year's release based on your specific deployment.
Breaking changes
Here are the breaking changes that are high impact.
High impact
1. Support for NGINX Ingress replaced by Gateway API with Envoy Gateway
GitLab Self-Managed (Helm chart)
The GitLab Helm chart has bundled NGINX Ingress as the default networking component. NGINX Ingress reached end-of-life in March 2026, and GitLab is now transitioning to Gateway API with Envoy Gateway as the new default.
Starting with GitLab 19.0, Gateway API and the bundled Envoy Gateway become the default networking configuration. If migration to Envoy Gateway is not immediately feasible for your deployment, you can explicitly re-enable the bundled NGINX Ingress, which remains available until its planned removal in GitLab 20.0.
This change does not impact:
- The NGINX used in the Linux package
- GitLab Helm chart and GitLab Operator instances that use an externally managed Ingress or Gateway API controller
GitLab will provide best-effort security maintenance for the forked NGINX Ingress chart and builds until full removal. To ensure a smooth transition, plan your migration to the provided Gateway API solution or an externally managed Ingress controller ahead of the 19.0 upgrade.
2. Removal of bundled PostgreSQL, Redis, and MinIO from the GitLab Helm chart
GitLab Self-Managed (Helm chart)
The GitLab Helm chart has long bundled Bitnami PostgreSQL, Bitnami Redis, and a fork of the official MinIO chart to make setting up GitLab easier in proof-of-concept and test environments. Due to changes in licensing, project maintenance, and public image availability, these components will be removed from the GitLab Helm chart and GitLab Operator with no replacement.
These charts are explicitly documented as not recommended for production usage. Their sole purpose was to enable quick-start test environments.
If you are running an instance with the bundled PostgreSQL, Redis, or MinIO, follow the migration guide to configure external services before upgrading to GitLab 19.0. The Redis and PostgreSQL provided by the Linux package are not impacted by this change.
3. Resource Owner Password Credentials (ROPC) OAuth grant removed
GitLab.com | Self-Managed | Dedicated
Support for the Resource Owner Password Credentials (ROPC) grant as an OAuth flow will be fully removed in GitLab 19.0. This aligns with the OAuth RFC Version 2.1 standard, which removes ROPC due to its inherent security limitations.
GitLab has already required client authentication for ROPC on GitLab.com since April 8, 2025. An administrator setting was added in 18.0 to allow controlled opt-out ahead of the removal.
After the 19.0 upgrade, ROPC cannot be used under any circumstances, even with client credentials. Any applications or integrations using this grant type must migrate to a supported OAuth flow — such as the Authorization Code flow — before upgrading.
4. PostgreSQL 16 no longer supported — PostgreSQL 17 is the new minimum
GitLab Self-Managed
GitLab follows an annual upgrade cadence for PostgreSQL. In GitLab 19.0, PostgreSQL 17 becomes the minimum required version, and support for PostgreSQL 16 is removed.
PostgreSQL 17 is available as of GitLab 18.9, so you can upgrade at any time before the 19.0 release.
For instances running a single PostgreSQL instance installed via the Linux package, an automatic upgrade to PostgreSQL 17 may be attempted during the 18.11 upgrade. Ensure you have sufficient disk space to accommodate the upgrade.
For instances using PostgreSQL Cluster, or those that opt out of the automated upgrade, a manual upgrade to PostgreSQL 17 is required before upgrading to GitLab 19.0.
Deprecation notice | Upgrade guide
Medium impact
Here are the breaking changes that are medium impact.
1. Linux package support for Ubuntu 20.04 discontinued
GitLab Self-Managed
Ubuntu standard support for Ubuntu 20.04 ended in May 2025. In accordance with GitLab's Linux package supported platforms policy, packages are dropped once a vendor stops supporting the operating system.
From GitLab 19.0, packages will no longer be provided for Ubuntu 20.04. GitLab 18.11 will be the last release with Linux packages for this distribution.
If you currently run GitLab on Ubuntu 20.04, you must upgrade to Ubuntu 22.04 or another supported operating system before upgrading to GitLab 19.0. Canonical provides an upgrade guide to help with the migration.
2. Support for Redis 6 removed
GitLab Self-Managed
In GitLab 19.0, support for Redis 6 is removed. Before upgrading, instances using an external Redis 6 deployment must migrate to either Redis 7.2 or Valkey 7.2, which is available in beta from GitLab 18.9 with general availability planned for GitLab 19.0.
The bundled Redis included with the Linux package has used Redis 7 since GitLab 16.2 and is not affected. Only instances using an external Redis 6 deployment must act.
Migration resources are available for common platforms:
- AWS ElastiCache: Upgrade to Redis 7.2 or Valkey 7.2
- GCP Memorystore: Upgrade to Redis 7.2 or Valkey 7.2
- Azure Cache for Redis: Managed Redis 7.2 or Valkey 7.2 is not yet available on Azure. You can self-host on Azure VMs or AKS, or use the Linux package installation, which will support Valkey 7.2 with GitLab 19.0 GA.
- Self-hosted: Upgrade your Redis 6 instance to Redis 7.2 or Valkey 7.2.
Deprecation notice | Requirements documentation
3. heroku/builder:22 image replaced by heroku/builder:24
GitLab.com | Self-Managed | Dedicated
The cloud-native buildpack (CNB) builder image used in Auto DevOps has been updated to heroku/builder:24. This affects pipelines that use the auto-build-image provided by the Auto Build stage of Auto DevOps.
While most workloads will be unaffected, this may be a breaking change for some users. Before upgrading, review the Heroku-24 stack release notes and upgrade notes to assess your impact.
If you need to continue using heroku/builder:22 after GitLab 19.0, set the CI/CD variable AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER to heroku/builder:22.
4. Mattermost removed from the Linux package
GitLab Self-Managed
In GitLab 19.0, bundled Mattermost is removed from the Linux package. Mattermost was first bundled with GitLab in 2015, but has since matured its own standalone deployment options. Additionally, with Mattermost v11, GitLab SSO was deprecated from their free offering, reducing the value of the bundled integration.
Customers not using the bundled Mattermost will not be impacted. If you currently use it, refer to Migrating from GitLab Omnibus to Mattermost Standalone in the Mattermost documentation for migration instructions.
5. Linux package support for SUSE distributions discontinued
GitLab Self-Managed
In GitLab 19.0, Linux package support for SUSE distributions ends. This affects:
- openSUSE Leap 15.6
- SUSE Linux Enterprise Server 12.5
- SUSE Linux Enterprise Server 15.6
GitLab 18.11 will be the last version with Linux packages for these distributions. The recommended path forward is to migrate to a Docker deployment of GitLab on your existing distribution, avoiding the need to change your underlying operating system to continue receiving upgrades.
Low impact
Here are the breaking changes that are low impact.
1. Spamcheck removed from Linux package and GitLab Helm chart
GitLab Self-Managed
In GitLab 19.0, Spamcheck is removed from the Linux package and GitLab Helm chart. It is primarily relevant to large public instances, which is an edge case in GitLab's customer base. The removal reduces package size and dependency footprint for the majority of customers.
Customers not currently using Spamcheck will not be impacted. If you currently use the bundled Spamcheck, you can deploy it separately using Docker. No data migration is required.
2. Slack slash commands integration removed
GitLab Self-Managed | Dedicated
The Slack slash commands integration is deprecated in favor of the GitLab for Slack app, which provides a more secure integration with the same capabilities.
From GitLab 19.0, users will no longer be able to configure or use Slack slash commands. This integration only exists on GitLab Self-Managed and GitLab Dedicated — GitLab.com users are not affected.
To check if your instance is impacted, see the impact check guidance.
3. Bitbucket Cloud import via API no longer supports app passwords
GitLab.com | Self-Managed | Dedicated
Atlassian has deprecated app passwords (username and password authentication) for Bitbucket Cloud and has announced that this authentication method will stop working on June 9, 2026.
From GitLab 19.0, importing repositories from Bitbucket Cloud through the GitLab API requires user API tokens instead of app passwords. Users importing from Bitbucket Server, or from Bitbucket Cloud through the GitLab UI, are not affected.
Deprecation notice | Impact check
4. Trending tab removed from Explore projects page
GitLab.com | Self-Managed | Dedicated
The Trending tab in Explore > Projects and its associated GraphQL arguments are removed in GitLab 19.0. The trending algorithm only considers public projects, making it ineffective for Self-Managed instances that primarily use internal or private project visibility.
In the month before the GitLab 19.0 release, the Trending tab on GitLab.com will redirect to the Active tab sorted by stars in descending order.
Also removed: the trending argument in the Query.adminProjects, Query.projects, and Organization.projects GraphQL types.
5. Container registry storage driver updates
GitLab Self-Managed
Two legacy container registry storage drivers are being replaced in GitLab 19.0:
- Azure storage driver: The legacy
azuredriver becomes an alias for the newazure_v2driver. No manual action is required, but proactive migration is recommended for improved reliability and performance. See the object storage documentation for migration steps. Deprecation notice - S3 storage driver (AWS SDK v1): The legacy
s3driver becomes an alias for the news3_v2driver. Thes3_v2driver does not support Signature Version 2 — anyv4auth: falseconfiguration will be transparently ignored. Migrate to Signature Version 4 before upgrading. Deprecation notice
6. ciJobTokenScopeAddProject GraphQL mutation removed
GitLab.com | Self-Managed | Dedicated
The ciJobTokenScopeAddProject GraphQL mutation is deprecated in favor of ciJobTokenScopeAddGroupOrProject, introduced alongside the CI/CD job token scope changes in GitLab 18.0. Update any automation or tooling using the deprecated mutation before upgrading.
7. ci_job_token_scope_enabled projects API attribute removed
GitLab.com | Self-Managed | Dedicated
The ci_job_token_scope_enabled attribute in the Projects REST API is removed in GitLab 19.0. This attribute was deprecated in GitLab 18.0 when the underlying setting was removed, and has since always returned false.
To control CI/CD job token access, use the CI/CD job token project settings.
8. Unauthenticated Projects API pagination limit enforced on GitLab.com
GitLab.com
To maintain platform stability and ensure consistent performance, a maximum offset limit of 50,000 will be enforced for all unauthenticated requests to the Projects List REST API on GitLab.com. For example, the page parameter will be limited to 2,500 pages when retrieving 20 results per page.
Workflows requiring access to more data must use keyset-based pagination parameters. This limit applies only to GitLab.com. On GitLab Self-Managed and GitLab Dedicated, the offset limit will be disabled by default behind a feature flag.
Resources to manage your impact
We've developed specific tooling to help customers understand how these planned changes impact their GitLab instance(s). Once you've assessed your impact, we recommend reviewing the mitigation steps provided in the documentation relevant to each change to ensure a smooth transition to GitLab 19.0.
GitLab Detective (Self-Managed only): This experimental tool automatically checks a GitLab installation for known issues by looking at config files and database values. Note: it must run directly on your GitLab nodes.
If you have a paid plan and have questions or require assistance with these changes, please open a support ticket on the GitLab Support Portal.
If you are a free GitLab.com user, you can access additional support through community sources such as GitLab Documentation, the GitLab Community Forum, and Stack Overflow.
