Open-Source-DevOps im großen Maßstab: GitLab selbst betreiben
Quellcode ist das eine Gut, das praktisch jedes Technologieunternehmen für kritisch hält, und zugleich dasjenige, das die meisten auf einer Infrastruktur liegen haben, die ihnen nicht gehört, in einer Rechtsordnung, die sie nicht gewählt haben, unter einem Vertrag, den sie nicht sorgfältig gelesen haben. Meistens ist das unproblematisch. Trotzdem lohnt es sich zu wissen, was die Alternative kostet, denn GitLab macht es seit über einem Jahrzehnt praktikabel, den gesamten Entwicklungszyklus selbst zu hosten.
Es ist außerdem ein Produkt, dessen kostenlose Stufe großzügiger und dessen Betriebsaufwand schwerer ist, als die meisten erwarten. Beides sollte man vor der Entscheidung verstehen. Dieser Leitfaden erklärt daher, was GitLab Self-Managed wirklich ist, was die kostenlose Stufe tatsächlich hergibt und welche drei betrieblichen Probleme den größten Teil des Schmerzes verursachen.
Was GitLab ist
Kein Git-Hoster mit angeschraubten Extras. Eine Rails-Anwendung, PostgreSQL, Redis, Gitaly für die Repository-Speicherung, Sidekiq für Hintergrundjobs und eine Container-Registry, zusammen paketiert als ein System für Versionskontrolle, Code-Review, Ticketverwaltung, CI/CD, Paket- und Container-Registries, Sicherheitsprüfungen und Deployment.
Diese Breite ist das ganze Argument. GitHub plus Actions plus Dependabot plus eine Paket-Registry plus ein Projekt-Tracker ergibt einen vergleichbaren Funktionsumfang, aus Teilen zusammengesetzt. GitLab ist eine Anwendung mit einem Berechtigungsmodell und einer Datenbank. Das ist entweder genau das, was Sie wollen, oder mehr, als Sie brauchen, und was davon zutrifft, hängt daran, wie viel des Lebenszyklus Sie tatsächlich an einem Ort betreiben wollen.
Architektonisch gilt dieselbe Tatsache wie beim Selbsthosten der Analytics mit Matomo, der Marketing-Automatisierung mit Mautic oder des Team-Chats mit Mattermost: Es läuft dort, wo Sie es hinstellen. Ihre Repositories, Ihre CI-Logs, Ihre Artefakte, Ihre Datenbank.
Die Lizenzlage, klar gesagt
Das ist wirklich verwirrend und verdient Genauigkeit, denn die Verwirrung läuft in die entgegengesetzte Richtung zu dem, was man erwartet.
Es gibt zwei Quelldistributionen. Community Edition ist MIT-lizenziert. Enterprise Edition hat ihre eigene, restriktivere Lizenz, die für das Verzeichnis ee/ des Repositorys gilt. So weit klingt das nach dem üblichen Open-Core-Modell.
Was überrascht: Das Linux-Paket, das fast alle installieren, ist der Enterprise-Edition-Build, und ohne eingespielten Lizenzschlüssel läuft er als Free-Stufe und verhält sich wie die Community Edition. Sie betreiben also nicht die MIT-lizenzierte Distribution, sofern Sie nicht bewusst das CE-Paket gewählt haben. In der Praxis spielt das selten eine Rolle, aber wenn Ihr Grund fürs Selbsthosten eine strikte Open-Source-Richtlinie ist und nicht Datenkontrolle, dann spielt es eine große Rolle, und fast niemand prüft es.
Die kommerziellen Stufen sind Free, Premium zu 29 Dollar pro Nutzer und Monat bei jährlicher Abrechnung und Ultimate zu individuellem Preis. Premium ergänzt erweiterte CI/CD, bessere Projektverwaltung und bevorzugten Support. Ultimate ergänzt das Sicherheits- und Compliance-Paket: Anwendungssicherheitstests, Lieferkettensicherheit, Dependency Scanning. Beide kostenpflichtigen Stufen enthalten inzwischen GitLab Credits für die KI-Funktionen, 12 Dollar pro Nutzer und Monat bei Premium und 24 bei Ultimate.
Und hier ist die Tatsache, die für die meisten Teams die Rechnung verändert, und die exakte Umkehrung der Lage bei Mattermost: Die Free-Stufe hat im Self-Managed-Betrieb keine Nutzerobergrenze. Die Grenze von fünf Nutzern, von der viele gehört haben, gilt nur für private Gruppen auf GitLab.com. Selbst gehostetes Free gibt Ihnen unbegrenzt Nutzer, Versionskontrolle, CI/CD und Registries, und Sie bringen Speicher und Runner selbst mit. Eine Organisation mit hundert Entwicklerinnen und Entwicklern kann vollständig darauf laufen.
Verzichten müssen Sie auf Sicherheitsprüfungen, Compliance-Berichte, erweiterte Freigaberegeln und Support. Wenn Sie unter den Cyber Resilience Act fallen und Dependency Scanning sowie SBOM-Erzeugung direkt in den Pipelines haben wollen statt aus getrennten Werkzeugen zusammengesetzt, ist das ein Ultimate-Gespräch. Für die meisten anderen Teams ist Free kein Testlauf, sondern eine tragfähige Dauerlösung.
Die Einrichtung
Eine kleine Installation
GitLab ist schwerer, als es aussieht. Die dokumentierte Basis für einen einzelnen Knoten sind 8 vCPU und 16 GB RAM, und anders als die meisten Herstellerminima ist diese Zahl ehrlich statt optimistisch. Man kann es in 8 GB quetschen, aber man merkt es, und Swap sollte aus sein, denn diese Anwendung auszulagern ist schlimmer, als den Speicher gar nicht zu haben.
PostgreSQL ist die einzige unterstützte Datenbank. Welche Version, hängt von Ihrer GitLab-Version ab: 17.x will PostgreSQL 14.14 bis 16.x, 18.x will 16.5 bis 17.x, und 19.x will 17.x. Redis 7.2 wird empfohlen, 7.0 ist das Minimum, und Valkey 7.2 funktioniert als Ersatz. Nur eigenständige Instanzen, denn Cluster- und Serverless-Varianten von Redis werden nicht unterstützt.
Installieren Sie mit dem Linux-Paket. Es gibt Helm-Charts, einen Operator, Docker-Images und einen Weg aus dem Quellcode, aber das Linux-Paket ist die ausgereifteste Variante und genau das, worauf GitLab.com selbst läuft. Es bringt PostgreSQL, Redis und Sidekiq mit, also genügen eine Maschine und eine Konfigurationsdatei für eine funktionierende Instanz.
# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'
# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']
# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9
# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
'provider' => 'AWS',
'region' => 'eu-central-1',
'aws_access_key_id' => 'REPLACE_ME',
'aws_secret_access_key' => 'REPLACE_ME'
}
Ein gitlab-ctl reconfigure später haben Sie eine Instanz. Setzen Sie external_url gleich beim ersten Mal richtig, denn der Wert landet fest in Clone-URLs, Webhooks und Registry-Adressen.
Eine produktive Installation
GitLab veröffentlicht Referenzarchitekturen von 1.000 bis 50.000 Nutzern, und es lohnt sich, sie zu lesen, selbst wenn Sie keine davon umsetzen, weil sie zeigen, welche Komponente zuerst zum Engpass wird.
Der Rat, der am meisten Geld spart, kommt von GitLab selbst und argumentiert gegen Komplexität: unterhalb von 3.000 Nutzern empfehlen sie eine solide Backup-Strategie statt Hochverfügbarkeit. Die Dokumentation ist dabei ungewöhnlich offen und hält fest, ein Backup-Ansatz habe zwar eine langsamere Wiederherstellungszeit, bedeute aber eine viel kleinere Architektur und geringere Wartungskosten. Oberhalb von 3.000 Nutzern, oder wo ein Ausfall die Firma wirklich stilllegt, wird Hochverfügbarkeit zur Empfehlung.
Nehmen Sie das ernst. Ein einzelner, gut gesicherter Knoten mit getesteter Wiederherstellung ist in der Praxis verlässlicher als ein halb verstandenes HA-Cluster, und er kostet erheblich weniger.
Verlagern Sie Artefakte, Uploads, LFS-Objekte und Registry-Images von Anfang an in Objektspeicher. Dieselbe Begründung wie überall sonst: Es hält den Knoten zustandslos, die Backups handhabbar und die Migration möglich.
Die drei Dinge, die schiefgehen
Alles Bisherige steht in der Dokumentation. Das Folgende erzeugt Störungen.
Ihr Backup enthält nicht das, was es entschlüsselt
Das ist der wichtigste Absatz dieses Artikels.
gitlab-backup create sichert eine ganze Menge: Datenbank, Repositories, LFS-Objekte, CI-Artefakte und Job-Logs, Registry-Images, Wikis, Uploads, Pages-Inhalte, Terraform-State, Snippets. Was es nicht sichert, ist das Konfigurationsverzeichnis, und namentlich /etc/gitlab/gitlab-secrets.json.
Diese Datei enthält den Verschlüsselungsschlüssel der Datenbank. Die Dokumentation benennt die Folge unmissverständlich: Wenn Sie sie verlieren, kann die GitLab-Anwendung keine verschlüsselten Werte in der Datenbank mehr entschlüsseln. Gemeint sind CI/CD-Variablen, Tokens, Zwei-Faktor-Geheimnisse und Zugangsdaten für Integrationen. Sie hätten dann ein Backup, das sich in eine Instanz zurückspielt, die ihre eigenen Geheimnisse nicht lesen kann.
Ebenfalls ausgeschlossen: /etc/gitlab/gitlab.rb, TLS-Schlüssel und Zertifikate, SSH-Host-Keys und die Inhalte des Objektspeichers, sobald Objektspeicher konfiguriert ist. Letzteres erwischt genau die Leute, die architektonisch alles richtig gemacht und dann angenommen haben, das Backup decke es ab.
Sichern Sie also /etc/gitlab separat, legen Sie es woanders ab als das Archiv, denn es ist der Schlüssel zum Archiv, und spielen Sie anschließend das Ganze auf eine Wegwerfmaschine zurück und prüfen Sie, ob Sie sich anmelden und eine CI-Variable lesen können. Ein ungetestetes Backup ist kein Backup, und bei GitLab ist ein ungetestetes Backup meistens ein kaputtes.
Sie können nicht in einem Sprung aktualisieren
GitLab hat verpflichtende Zwischenstopps beim Upgrade, und das ist keine Empfehlung. Sie können sie nicht überspringen. Seit 17.5 sind die Stopps vorhersehbar und liegen bei x.2, x.5, x.8 und x.11. Ein Upgrade von 18.0 auf 19.2 führt also über 18.2, 18.5, 18.8, 18.11 und 19.0.
Zu jedem Stopp gehören Hintergrundmigrationen, die vollständig abgeschlossen sein müssen, bevor Sie weitergehen. Das nächste Upgrade zu starten, während Migrationen noch laufen, ist der Weg zu Zuständen, die nur der Support wieder auseinandernimmt. Auf einer großen Instanz können diese Migrationen Stunden dauern.
Zwei praktische Folgerungen. Aktualisieren Sie regelmäßig, denn ein Jahr aufgeschobener Upgrades ist ein Wochenende voll sequenzieller. Und nehmen Sie immer den neuesten Patch-Release einer Ziel-Minor-Version statt des ersten, was die Dokumentation ausdrücklich so schreibt. GitLab pflegt ein Werkzeug, das den Upgrade-Pfad für Sie berechnet, und es lohnt sich, das zu benutzen, statt selbst zu rechnen.
Bei den Runnern liegen die eigentlichen Kosten
Der GitLab-Server führt Ihre CI nicht aus. GitLab Runner ist eine eigene Komponente, die Sie installieren, konfigurieren und bezahlen, auf Infrastruktur, die Sie stellen. Self-Managed Free enthält überhaupt keine CI-Minuten, weil es keine mitgelieferte Rechenleistung gibt: Sie bringen Ihre eigenen Maschinen mit.
Meistens ist das ein gutes Geschäft, denn ein eigener Runner ist bei ernsthaftem Volumen pro Minute günstiger als gehostete CI, und Sie können jedem Build genau die Hardware geben, die er braucht. Aber es ist echte Infrastrukturarbeit. Sie treffen Entscheidungen über Executors, ob Shell, Docker oder Kubernetes, über Autoscaling, damit Runner nicht um drei Uhr nachts leerlaufen, und über Caching, was den Unterschied zwischen einer Pipeline von vier und einer von vierzehn Minuten ausmacht.
Planen Sie die Runner-Flotte als eigene Kostenposition. Teams, die die Kosten des Selbsthostens nur am GitLab-Knoten festmachen, verschätzen sich deutlich und entdecken die Lücke dann als Warteschlange offener Jobs.
Der Umzug von GitHub
Der GitHub-Importer ist gut, deutlich besser als die meisten Migrationswerkzeuge von Anbietern, und er bringt Repository-Daten, Branches, LFS-Objekte, Issues und Pull Requests mitsamt Kommentaren, Reviews und Diskussionsantworten, Wiki-Seiten, Releases und Anhänge, Labels, Meilensteine, Branch-Schutzregeln sowie Mitarbeitende mit Rollenzuordnung herüber.
Die dokumentierten Lücken sollten Sie einplanen. Organisationen und Gruppen kommen nicht mit, die Gruppenstruktur entwerfen Sie also neu, statt sie zu erben, was meistens eine Verbesserung ist. GitHub-Actions-Workflows lassen sich nicht in GitLab CI überführen. Kommentare zu Pull Requests von vor 2017 landen wegen Einschränkungen der GitHub-API als separate Threads, und Repositories mit mehr als rund 30.000 Kommentaren brauchen die alternative Importmethode für Kommentare.
Da GitHub # für Issues und Pull Requests gleichermaßen verwendet und GitLab die beiden unterscheidet, werden manche Querverweise nicht auflösen. Verloren geht nichts, aber Links in alten Diskussionen zeigen unter Umständen auf das Falsche.
Planen Sie den CI-Neubau als das eigentliche Projekt, denn genau das ist er. Alles andere ist ein Importlauf, den Sie starten und prüfen können.
Der europäische Blickwinkel
Für Unternehmen in Europa kommt zur Kostenfrage eine Compliance-Dimension. Quellcode, Build-Pipelines und Artefakte gehören zum Sensibelsten, was ein Technologieunternehmen besitzt, und wo sie liegen, ist zunehmend eine Frage, die Ihnen gestellt wird, statt einer, die Sie freiwillig beantworten.
Selbsthosting legt sie in eine Grenze, die Sie kontrollieren. Das vereinfacht in einem Zug die Übermittlungsprüfung nach DSGVO und die Lieferkettenfragen aus NIS2, und es ist dasselbe Souveränitätsargument, um das herum der Cloud and AI Development Act gebaut ist.
Der schärfere Zusammenhang ist der Cyber Resilience Act. Wer Software in den EU-Markt bringt, braucht Abhängigkeitsinventare, einen Umgang mit Schwachstellen und ein koordiniertes Offenlegungsverfahren. Diese Pflichten erfüllt man in der Build-Pipeline und nicht in einem Dokument, und Pipeline, Registry und Scanning in einem System zu haben, das Sie selbst betreiben, macht das Erzeugen der Nachweise erheblich weniger mühsam, als sie aus vier Produkten zusammenzutragen.
Wann Sie es lassen sollten
Wenn Sie unter zwanzig Entwicklerinnen und Entwickler sind, kein regulatorischer Druck besteht und niemand starke Gefühle dazu hat, wo der Code liegt, nehmen Sie die SaaS. GitLab.com und GitHub sind beide ausgezeichnet, und die Betriebsarbeit kostet mehr als das Abonnement.
Wenn Ihre Organisation tief in GitHubs Ökosystem sitzt, zählen Sie ehrlich zusammen, was Sie verlieren würden. Actions, der Marktplatz und die schlichte Vertrautheit der Plattform bei jeder Kandidatin und jedem Kandidaten sind echte Vermögenswerte, und die Antwort lautet nicht automatisch, dass GitLab gewinnt.
Und wenn niemand die Instanz übernimmt, fangen Sie gar nicht erst an. GitLab belohnt jemanden, der patcht, die Runner-Flotte beobachtet und die Wiederherstellung testet. Ohne diese Person verkommt es zu einer ungepatchten Kiste, in der Ihr wertvollstes Gut liegt, und das ist schlimmer als die SaaS, die Sie verlassen wollten.
Unterstützung
Wir betreiben selbst gehostete Entwicklungsinfrastruktur für Unternehmen in Europa, einschließlich der Teile, die niemand mag: Upgrade-Sequenzen über verpflichtende Zwischenstopps, Runner-Flotten mit funktionierendem Autoscaling, Migrationen in Objektspeicher und Backup-Konzepte, die tatsächlich schon einmal zurückgespielt wurden.
Wenn Sie eine ehrlich dimensionierte GitLab-Instanz brauchen, eine GitHub-Migration, die jemand plant, der den CI-Neubau schon gemacht hat, oder eine Prüfung, ob Ihr aktuelles Backup einen echten Ausfall überstehen würde, schreiben Sie an office@c9group.dev. Mehr zu unserer Infrastrukturarbeit finden Sie auf der Seite zur AWS-Kostenoptimierung.
Wenn Sie einen vollständigen selbst gehosteten Stack zusammenstellen, gilt dieselbe Überlegung für Analytics, Marketing-Automatisierung und Teamkommunikation.
Veröffentlicht: 8. August 2026 Kategorien: DevOps, Open Source, Datenschutz