GitLab 17.0 enthielt 80 Breaking Changes – also inkompatible Änderungen, die beim Upgrade manuellen Anpassungsbedarf erzeugen. GitLab 18.0 hatte 27. Das bevorstehende Release GitLab 19.0 wird voraussichtlich 15 enthalten.
Wir wissen, dass die Verwaltung von Breaking Changes bei einem Major-Upgrade aufwändig ist: Es erfordert Analyse und Koordination im gesamten Unternehmen. Als Reaktion darauf haben wir eine Genehmigungspflicht für Breaking Changes eingeführt, die eine Folgenabschätzung und die Freigabe durch die Führungsebene vorschreibt, bevor ein Breaking Change umgesetzt werden kann. Dieser Prozess zeigt Wirkung, und wir sind entschlossen, die Zahl weiter zu senken.
Im Folgenden sind alle Breaking Changes in GitLab 19.0 aufgeführt, geordnet nach Deployment-Typ und Auswirkung, zusammen mit den Migrationsschritten für ein reibungsloses Upgrade.
Deployment-Fenster
Folgende Deployment-Fenster sind relevant.
GitLab.com
Inkompatible Änderungen für GitLab.com sind auf diese zwei Fenster begrenzt:
- 4.–6. Mai 2026 (09:00–22:00 UTC) — primäres Fenster
- 11.–13. Mai 2026 (09:00–22:00 UTC) — Ausweichfenster
Viele weitere Änderungen werden im Laufe des Monats ausgerollt. Mehr zu den Breaking Changes innerhalb dieser Fenster in der Dokumentation zu Breaking-Change-Fenstern.
Hinweis: In Ausnahmefällen können Breaking Changes geringfügig außerhalb dieser Fenster fallen.
GitLab Self-Managed
GitLab 19.0 wird ab dem 21. Mai 2026 verfügbar sein.
Mehr zum Release-Zeitplan.
GitLab Dedicated
Das Upgrade auf GitLab 19.0 findet im zugewiesenen Wartungsfenster statt. Das Wartungsfenster ist im Switchboard-Portal einsehbar. GitLab Dedicated-Instanzen werden auf Release N-1 gehalten, das Upgrade auf GitLab 19.0 erfolgt daher im Wartungsfenster in der Woche ab dem 22. Juni 2026.
Auf der Deprecations-Seite ist die vollständige Liste der für GitLab 19.0 geplanten Entfernungen zu finden. Im Folgenden wird erläutert, was kommt und wie man sich je nach Deployment darauf vorbereitet.
Breaking Changes
Folgende Breaking Changes haben hohe Auswirkungen.
Hohe Auswirkung
1. NGINX Ingress-Unterstützung durch Gateway API mit Envoy Gateway ersetzt
GitLab Self-Managed (Helm chart)
Der GitLab Helm chart hat NGINX Ingress als Standard-Netzwerkkomponente gebündelt. NGINX Ingress hat im März 2026 das End-of-Life erreicht. GitLab wechselt nun zu Gateway API mit Envoy Gateway als neuem Standard.
Ab GitLab 19.0 werden Gateway API und das gebündelte Envoy Gateway zur Standard-Netzwerkkonfiguration. Falls eine Migration zu Envoy Gateway für das eigene Deployment nicht sofort möglich ist, kann das gebündelte NGINX Ingress explizit wieder aktiviert werden — es bleibt bis zur geplanten Entfernung in GitLab 20.0 verfügbar.
Diese Änderung betrifft nicht:
- Das im Linux-Paket enthaltene NGINX
- GitLab Helm chart- und GitLab Operator-Instanzen, die einen extern verwalteten Ingress- oder Gateway-API-Controller verwenden
GitLab stellt bis zur vollständigen Entfernung Best-Effort-Sicherheitswartung für den geforkten NGINX Ingress chart und die zugehörigen Builds bereit. Für einen reibungslosen Übergang empfiehlt sich eine frühzeitige Migration zur bereitgestellten Gateway-API-Lösung oder zu einem extern verwalteten Ingress-Controller.
2. Gebündelte PostgreSQL-, Redis- und MinIO-Komponenten aus dem GitLab Helm chart entfernt
GitLab Self-Managed (Helm chart)
Der GitLab Helm chart hat Bitnami PostgreSQL, Bitnami Redis und einen Fork des offiziellen MinIO-Charts gebündelt, um die Einrichtung von GitLab in Proof-of-Concept- und Testumgebungen zu erleichtern. Aufgrund von Änderungen bei Lizenzierung, Projektpflege und Verfügbarkeit öffentlicher Images werden diese Komponenten ohne Ersatz aus dem GitLab Helm chart und dem GitLab Operator entfernt.
Diese Charts sind ausdrücklich als nicht für den Produktionseinsatz geeignet dokumentiert. Ihr einziger Zweck war die Bereitstellung schneller Testumgebungen.
Wer eine Instanz mit gebündeltem PostgreSQL, Redis oder MinIO betreibt, muss vor dem Upgrade auf GitLab 19.0 der Migrationsanleitung folgen, um externe Dienste zu konfigurieren. Redis und PostgreSQL aus dem Linux-Paket sind von dieser Änderung nicht betroffen.
3. Resource Owner Password Credentials (ROPC) OAuth Grant entfernt
GitLab.com | Self-Managed | Dedicated
Die Unterstützung für den Resource Owner Password Credentials (ROPC) Grant als OAuth-Flow wird in GitLab 19.0 vollständig entfernt. Dies entspricht dem OAuth RFC Version 2.1-Standard, der ROPC aufgrund seiner inhärenten Sicherheitsschwächen entfernt.
GitLab hat seit dem 8. April 2025 bereits eine Client-Authentifizierung für ROPC auf GitLab.com vorgeschrieben. In Version 18.0 wurde eine Administrator-Einstellung hinzugefügt, die einen kontrollierten Opt-out vor der Entfernung ermöglicht.
Nach dem Upgrade auf 19.0 kann ROPC unter keinen Umständen mehr verwendet werden, auch nicht mit Client-Credentials. Alle Anwendungen oder Integrationen, die diesen Grant-Typ verwenden, müssen vor dem Upgrade auf einen unterstützten OAuth-Flow migrieren — beispielsweise den Authorization Code Flow.
4. PostgreSQL 16 nicht mehr unterstützt — PostgreSQL 17 ist das neue Minimum
GitLab Self-Managed
GitLab folgt einem jährlichen Upgrade-Rhythmus für PostgreSQL. In GitLab 19.0 wird PostgreSQL 17 zur Mindestanforderung, die Unterstützung für PostgreSQL 16 wird eingestellt.
PostgreSQL 17 ist ab GitLab 18.9 verfügbar und kann jederzeit vor dem 19.0-Release upgradet werden.
Bei Instanzen mit einer einzelnen, über das Linux-Paket installierten PostgreSQL-Instanz wird beim Upgrade auf 18.11 möglicherweise ein automatisches Upgrade auf PostgreSQL 17 durchgeführt. Für das Upgrade ist ausreichend freier Speicherplatz einzuplanen.
Bei Instanzen mit PostgreSQL Cluster oder solchen, die das automatische Upgrade deaktivieren, ist vor dem Upgrade auf GitLab 19.0 ein manuelles Upgrade auf PostgreSQL 17 erforderlich.
Deprecation notice | Upgrade-Anleitung
Mittlere Auswirkung
Folgende Breaking Changes haben mittlere Auswirkungen.
1. Linux-Paket-Unterstützung für Ubuntu 20.04 eingestellt
GitLab Self-Managed
Der Standard-Support für Ubuntu 20.04 endete im Mai 2025. Gemäß der Richtlinie für unterstützte Plattformen im Linux-Paket werden Pakete eingestellt, sobald ein Anbieter den Support für das Betriebssystem beendet.
Ab GitLab 19.0 werden keine Pakete mehr für Ubuntu 20.04 bereitgestellt. GitLab 18.11 ist das letzte Release mit Linux-Paketen für diese Distribution.
Wer GitLab derzeit auf Ubuntu 20.04 betreibt, muss vor dem Upgrade auf GitLab 19.0 auf Ubuntu 22.04 oder ein anderes unterstütztes Betriebssystem wechseln. Canonical stellt eine Upgrade-Anleitung für die Migration bereit.
2. Unterstützung für Redis 6 entfernt
GitLab Self-Managed
In GitLab 19.0 wird die Unterstützung für Redis 6 entfernt. Instanzen mit einem externen Redis-6-Deployment müssen vor dem Upgrade auf Redis 7.2 oder Valkey 7.2 migrieren; Valkey 7.2 ist ab GitLab 18.9 in der Beta verfügbar, die allgemeine Verfügbarkeit ist für GitLab 19.0 geplant.
Das im Linux-Paket enthaltene Redis verwendet seit GitLab 16.2 Redis 7 und ist nicht betroffen. Handlungsbedarf besteht nur bei Instanzen mit einem externen Redis-6-Deployment.
Migrationsressourcen für gängige Plattformen:
- AWS ElastiCache: Upgrade auf Redis 7.2 oder Valkey 7.2
- GCP Memorystore: Upgrade auf Redis 7.2 oder Valkey 7.2
- Azure Cache for Redis: Managed Redis 7.2 oder Valkey 7.2 ist auf Azure noch nicht verfügbar. Als Alternative kann ein selbstgehostetes Deployment auf Azure VMs oder AKS genutzt werden, oder die Linux-Paket-Installation, die Valkey 7.2 mit GitLab 19.0 GA unterstützen wird.
- Self-hosted: Upgrade der Redis-6-Instanz auf Redis 7.2 oder Valkey 7.2.
Deprecation notice | Anforderungsdokumentation
3. heroku/builder:22-Image durch heroku/builder:24 ersetzt
GitLab.com | Self-Managed | Dedicated
Das Cloud-Native-Buildpack (CNB) Builder-Image in Auto DevOps wurde auf heroku/builder:24 aktualisiert. Betroffen sind Pipelines, die das auto-build-image der Auto Build-Stage von Auto DevOps verwenden.
Die meisten Workloads sind nicht betroffen. Für einige Nutzende kann dies jedoch ein Breaking Change sein. Vor dem Upgrade sollten die Heroku-24-Stack-Release-Notes und Upgrade-Hinweise geprüft werden.
Wer nach GitLab 19.0 weiterhin heroku/builder:22 verwenden möchte, setzt die CI/CD-Variable AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER auf heroku/builder:22.
4. Mattermost aus dem Linux-Paket entfernt
GitLab Self-Managed
In GitLab 19.0 wird das gebündelte Mattermost aus dem Linux-Paket entfernt. Mattermost wurde seit 2015 mit GitLab gebündelt, verfügt inzwischen aber über ausgereifte eigenständige Deployment-Optionen. Mit Mattermost v11 wurde zudem GitLab SSO aus dem kostenlosen Angebot entfernt, was den Mehrwert der gebündelten Integration verringert.
Wer das gebündelte Mattermost nicht verwendet, ist nicht betroffen. Bei Bedarf steht in der Mattermost-Dokumentation eine Anleitung zur Migration von GitLab Omnibus zu Mattermost Standalone zur Verfügung.
5. Linux-Paket-Unterstützung für SUSE-Distributionen eingestellt
GitLab Self-Managed
In GitLab 19.0 wird die Linux-Paket-Unterstützung für SUSE-Distributionen eingestellt. Betroffen sind:
- openSUSE Leap 15.6
- SUSE Linux Enterprise Server 12.5
- SUSE Linux Enterprise Server 15.6
GitLab 18.11 ist das letzte Release mit Linux-Paketen für diese Distributionen. Der empfohlene Weg ist eine Migration zu einem Docker-Deployment von GitLab auf der bestehenden Distribution — so ist kein Wechsel des Betriebssystems nötig, um weiterhin Upgrades zu erhalten.
Geringe Auswirkung
Folgende Breaking Changes haben geringe Auswirkungen.
1. Spamcheck aus Linux-Paket und GitLab Helm chart entfernt
GitLab Self-Managed
In GitLab 19.0 wird Spamcheck aus dem Linux-Paket und dem GitLab Helm chart entfernt. Es ist in erster Linie für große öffentliche Instanzen relevant — ein Sonderfall in der GitLab-Kundenbasis. Die Entfernung reduziert die Paketgröße und den Abhängigkeits-Footprint für die Mehrheit der Nutzenden.
Wer Spamcheck nicht verwendet, ist nicht betroffen. Wer das gebündelte Spamcheck nutzt, kann es separat über Docker bereitstellen. Eine Datenmigration ist nicht erforderlich.
2. Slack-Slash-Commands-Integration entfernt
GitLab Self-Managed | Dedicated
Die Slack-Slash-Commands-Integration wird zugunsten der GitLab for Slack-App eingestellt, die eine sicherere Integration mit denselben Funktionen bietet.
Ab GitLab 19.0 können Slack Slash Commands nicht mehr konfiguriert oder verwendet werden. Diese Integration existiert nur in GitLab Self-Managed und GitLab Dedicated — GitLab.com-Nutzende sind nicht betroffen.
Ob die eigene Instanz betroffen ist, lässt sich mit der Betroffenheitsprüfung feststellen.
3. Bitbucket-Cloud-Import über API unterstützt keine App-Passwörter mehr
GitLab.com | Self-Managed | Dedicated
Atlassian hat App-Passwörter (Benutzername-Passwort-Authentifizierung) für Bitbucket Cloud eingestellt und angekündigt, dass diese Authentifizierungsmethode ab dem 9. Juni 2026 nicht mehr funktioniert.
Ab GitLab 19.0 erfordert der Import von Repositories aus Bitbucket Cloud über die GitLab API User-API-Tokens anstelle von App-Passwörtern. Nutzende, die aus Bitbucket Server oder über die GitLab-Benutzeroberfläche aus Bitbucket Cloud importieren, sind nicht betroffen.
Deprecation notice | Betroffenheitsprüfung
4. Trending-Tab auf der Seite „Projekte erkunden" entfernt
GitLab.com | Self-Managed | Dedicated
Der Tab Trending unter Erkunden > Projekte und die zugehörigen GraphQL-Argumente werden in GitLab 19.0 entfernt. Der Trending-Algorithmus berücksichtigt nur öffentliche Projekte und ist daher für Self-Managed-Instanzen, die hauptsächlich interne oder private Projektsichtbarkeit verwenden, nicht zielführend.
Im Monat vor dem GitLab-19.0-Release wird der Tab Trending auf GitLab.com auf den Tab Aktiv, sortiert nach Sternen in absteigender Reihenfolge, weitergeleitet.
Ebenfalls entfernt: das trending-Argument in den GraphQL-Typen Query.adminProjects, Query.projects und Organization.projects.
5. Container-Registry-Speichertreiber-Updates
GitLab Self-Managed
Zwei ältere Container-Registry-Speichertreiber werden in GitLab 19.0 ersetzt:
- Azure-Speichertreiber: Der ältere
azure-Treiber wird zu einem Alias für den neuenazure_v2-Treiber. Es ist keine manuelle Aktion erforderlich, eine proaktive Migration wird jedoch für verbesserte Zuverlässigkeit und Leistung empfohlen. Migrationsschritte sind in der Object-Storage-Dokumentation beschrieben. Deprecation notice - S3-Speichertreiber (AWS SDK v1): Der ältere
s3-Treiber wird zu einem Alias für den neuens3_v2-Treiber. Ders3_v2-Treiber unterstützt Signature Version 2 nicht — eine vorhandenev4auth: false-Konfiguration wird transparent ignoriert. Vor dem Upgrade ist eine Migration auf Signature Version 4 erforderlich. Deprecation notice
6. ciJobTokenScopeAddProject-GraphQL-Mutation entfernt
GitLab.com | Self-Managed | Dedicated
Die ciJobTokenScopeAddProject-GraphQL-Mutation wird zugunsten von ciJobTokenScopeAddGroupOrProject eingestellt, das zusammen mit den CI/CD-Job-Token-Scope-Änderungen in GitLab 18.0 eingeführt wurde. Automatisierungen oder Tools, die die veraltete Mutation verwenden, müssen vor dem Upgrade aktualisiert werden.
7. ci_job_token_scope_enabled-Attribut der Projects API entfernt
GitLab.com | Self-Managed | Dedicated
Das Attribut ci_job_token_scope_enabled in der Projects REST API wird in GitLab 19.0 entfernt. Das Attribut wurde in GitLab 18.0 eingestellt, als die zugrundeliegende Einstellung entfernt wurde, und hat seitdem stets false zurückgegeben.
Zur Steuerung des CI/CD-Job-Token-Zugriffs werden die CI/CD-Job-Token-Projekteinstellungen verwendet.
8. Paginierungslimit für nicht authentifizierte Projects-API auf GitLab.com eingeführt
GitLab.com
Zur Sicherstellung der Plattformstabilität und konsistenten Leistung wird für alle nicht authentifizierten Anfragen an die Projects-List-REST-API auf GitLab.com ein maximales Offset-Limit von 50.000 eingeführt. Beispielsweise ist der page-Parameter bei 20 Ergebnissen pro Seite auf 2.500 Seiten begrenzt.
Workflows, die Zugriff auf mehr Daten benötigen, müssen keyset-basierte Paginierungsparameter verwenden. Dieses Limit gilt nur für GitLab.com. In GitLab Self-Managed und GitLab Dedicated ist das Offset-Limit standardmäßig deaktiviert und hinter einem Feature-Flag verfügbar.
Ressourcen zur Folgenabschätzung
GitLab stellt spezifische Tools bereit, mit denen sich die Auswirkungen der geplanten Änderungen auf die eigene GitLab-Instanz analysieren lassen. Nach der Folgenabschätzung empfiehlt sich die Prüfung der Migrationsschritte in der jeweiligen Dokumentation für einen reibungslosen Übergang zu GitLab 19.0.
GitLab Detective (nur Self-Managed): Dieses experimentelle Tool prüft eine GitLab-Installation automatisch auf bekannte Probleme, indem es Konfigurationsdateien und Datenbankwerte analysiert. Hinweis: Es muss direkt auf den GitLab-Nodes ausgeführt werden.
Nutzende mit einem kostenpflichtigen Plan, die Fragen haben oder Unterstützung bei diesen Änderungen benötigen, können ein Support-Ticket im GitLab Support-Portal eröffnen.
Kostenlose GitLab.com-Nutzende können zusätzlichen Support über Community-Ressourcen wie die GitLab-Dokumentation, das GitLab Community Forum und Stack Overflow erhalten.
