Europäische Alternativen zu GitLab.

GitLab gilt oft als die europafreundliche Antwort auf GitHub, doch der gehostete Dienst GitLab.com wird von GitLab Inc. betrieben, einem US-eingetragenen börsennotierten Unternehmen (Delaware, an der NASDAQ als GTLB gelistet). Das stellt GitLab.com genauso in die Reichweite des US CLOUD Act wie das Microsoft-eigene GitHub und umfasst Repository-Inhalte, CI-Logs, Tokens und Issue-Historie. Diese Seite ordnet die europäischen Alternativen GitLab.com gegenüber ein und prüft, wem jeder Dienst rechtlich gehört, wo die Daten liegen und welches Compliance-Profil jeder für eine Schrems-II-Übermittlungsfolgenabschätzung nachweisen kann.

Es gibt zwei Wege zu einer europäischen Aufstellung. Der erste ist der Wechsel zu einer europäischen Forge: beide Optionen hier bauen auf Forgejo, der von Codeberg e.V. in Deutschland verwalteten Open-Source-Engine. Codeberg (Deutschland, Berlin, Non-Profit, EU-gehostet, kostenlos, CLOUD-Act-Risiko: Keines) ist die community-geführte Heimat für Open-Source-Projekte, und Codebahn (schwedischer Betreiber, Hosting in Frankreich, kostenpflichtig und betreut, CLOUD-Act-Risiko: Keines) ist die kommerzielle, verwaltete Option mit öffentlichem AVV und rein europäischer Unterauftragsverarbeiter-Kette. Der zweite, GitLab-spezifische Weg ist, die Software zu behalten, aber die GitLab Community Edition selbst auf EU-Infrastruktur zu hosten, was das direkte US-Risiko entfernt und den exakten Funktionsumfang bewahrt.

Was wird also tatsächlich aus einem GitLab.com-Konto übernommen?

• Git-Repositories mit vollständiger Branch- und Tag-Historie (von Natur aus portabel).
• Issues, Merge-Requests (als Pull-Requests importiert), Labels, Meilensteine und Releases.
• Code-Review mit Inline-Kommentaren und Branch-Schutzregeln.
• Gehostete CI/CD (Codeberg CI auf Woodpecker oder Codebahns EU-Runner).
• Paket-Registry und Container-Registry.
• Webhooks und eine REST-API für eigene Integrationen.

Nicht alles macht die Reise jedoch mit:

• GitLabs vollständige DevOps-Plattform. Integriertes Security-Scanning (SAST, DAST, Abhängigkeits- und Container-Scanning), die Value-Stream-Analytics und die eng verzahnten Compliance-Funktionen gehen über das hinaus, was die Forgejo-basierten Forges abdecken. Das ist der Hauptgrund, warum manche Teams stattdessen GitLab CE selbst hosten.
• GitLab-CI/CD-Syntax. Die CI-Konzepte werden übernommen, aber .gitlab-ci.yml-Pipelines müssen nach Woodpecker oder in das Codebahn-CI-Format übersetzt werden.
• GitLab-spezifische Integrationen. Für GitLab gebaute Marketplace- und Ein-Klick-Integrationen brauchen auf einer kleineren Forge möglicherweise Webhooks oder API-Anbindung.
• Gruppen- und Untergruppen-Hierarchie. GitLabs tief verschachteltes Gruppenmodell bildet sich auf Organisationen und Teams der Alternativen ab, aber sehr große, tief verschachtelte Strukturen müssen eventuell abgeflacht werden.

Der Umzug von GitLab.com läuft auf wenige Schritte hinaus, egal welches Ziel Sie wählen.

1. Entscheiden Sie zuerst zwischen europäischer Forge und selbst gehostetem GitLab CE. Hängt Ihr Team von GitLabs Security-Scanning und DevOps-Breite ab, bewahrt Selbst-Hosting von GitLab CE auf EU-Infrastruktur den Funktionsumfang; nutzen Sie hauptsächlich den Kern-Forge-Workflow, ist ein Forgejo-basierter Dienst leichter zu betreiben.
2. Nutzen Sie den Forgejo-Migrationsimporter. Für Codeberg oder Codebahn akzeptiert die "Neue Migration" eine GitLab-Quell-URL und ein Zugriffstoken und holt Code plus Issues, Merge-Requests, Labels, Meilensteine und Releases in einem Durchgang. Ein einfaches git push --mirror deckt einen reinen Code-Umzug ab.
3. Übersetzen Sie Ihre CI-Pipeline. Wandeln Sie .gitlab-ci.yml in eine Woodpecker-Pipeline (Codeberg) oder das Codebahn-CI-Format um und ersetzen Sie GitLab-spezifische Job-Templates durch gleichwertige Schritte.
4. Verweisen Sie Klone, Runner und Integrationen neu. Aktualisieren Sie bei jedem Entwickler git remote set-url, registrieren Sie bei Bedarf neue CI-Runner und verweisen Sie Deployment-Webhooks und Bots auf die API der neuen Forge.
5. Erneuern Sie Tokens und CI/CD-Variablen. Secrets und Deploy-Keys werden nicht migriert; erstellen Sie sie am Ziel neu und rotieren Sie alles, was offengelegt war.
6. Behalten Sie das GitLab-Projekt 60 Tage als schreibgeschützten Spiegel. Archivieren statt löschen, damit CI-Jobs anderswo, Paketabrufe und Dokumentationslinks während der Umstellung nicht still brechen.