GitLab Managed Service: Die Architektur im Detail
Im ersten Teil ging es darum, was unser Managed GitLab* für Entscheider bedeutet: planbare Kosten, echter Support, Datenhoheit. Dieser Teil ist für die, die wissen wollen, was darunter passiert. Für Bastler, Tüftler und alle, die ihre Infrastruktur lieber verstehen als nur buchen.
Warum GitLab selbst hosten? Vorteile gegenüber GitLab SaaS
Es gibt diesen Reflex, der vielen von uns vertraut ist: lieber selbst betreiben. Nicht aus Geiz, sondern weil man wissen will, was auf der eigenen Maschine läuft. Weil man die Kontrolle nicht aus der Hand geben will. Weil ein System, das man selbst aufgesetzt hat, sich einfach richtiger anfühlt.
Lange war das vor allem ein Gefühl – und SaaS oft trotzdem der pragmatischere Weg. Das hat sich verschoben. Inzwischen ist „selbst betreiben“ nicht mehr nur eine Frage des Bauchgefühls, sondern in vielen Fällen die wirtschaftlich und datenschutzrechtlich klügere Entscheidung. Besonders, wenn jemand den Betrieb übernimmt, der das wirklich kann.
Genau das machen wir: GitLab CE, redundant und hochverfügbar, auf einem Kubernetes-Cluster mit Immutable Linux darunter. Schauen wir uns an, warum dieser Stack so viel mehr eröffnet als ein klassisches „wir installieren dir GitLab“.
Kubernetes und Immutable Linux: Die technische Grundlage für einen hochverfügbaren GitLab-Betrieb
Warum ein Immutable Linux die Wartung und Sicherheit verbessert
Fangen wir unten an, beim Betriebssystem. Wir setzen auf ein immutable OS – ein Linux, dessen Root-Dateisystem read-only ist und das nicht „gewachsen“ wird, sondern als Ganzes atomar aktualisiert und bei Bedarf ebenso atomar zurückgerollt werden kann.
Warum das wichtig ist, kennt jeder, der mal einen über Jahre handgepflegten Server geerbt hat: Da hat jemand 2019 mal eben ein Paket nachinstalliert, 2021 ein Config-File „temporär“ angepasst, und niemand weiß mehr genau, warum die Kiste eigentlich läuft. Configuration Drift heißt das Phänomen, und es ist der Anfang vom Ende jeder Wartbarkeit. Bei einem immutable OS gibt es diesen Drift nicht. Der Zustand des Systems ist definiert, reproduzierbar und überprüfbar. Updates sind kein Risiko mehr, sondern ein Knopfdruck mit Rückfahrkarte. Und die Angriffsfläche schrumpft, weil sich an einem read-only-System schlicht weniger manipulieren lässt.
Warum Kubernetes für GitLab die bessere Plattform ist
Darauf läuft Kubernetes, und zwar nicht als Selbstzweck, sondern weil es genau die Eigenschaften liefert, die einen produktiven GitLab-Betrieb von einer Einzelinstallation unterscheiden:
- Redundanz und Hochverfügbarkeit: GitLab läuft nicht auf einem Server, der ausfallen kann, sondern verteilt über mehrere Nodes. Fällt ein Node aus, übernehmen die anderen. Die Komponenten – Rails-Anwendung, Sidekiq, Registry, die Runner – werden vom Cluster überwacht und bei Bedarf neu eingeplant.
- Saubere Trennung der Bausteine: PostgreSQL, Redis, Object Storage für Artefakte und LFS, die Container-Registry – alles sind klar abgegrenzte, einzeln skalierbare Komponenten statt eines monolithischen Klumpens auf einer VM.
- Skalierung, wo sie gebraucht wird: Wenn morgens alle gleichzeitig pushen und die Pipelines glühen, skalieren die Runner mit. Nachts geben sie die Ressourcen wieder frei. Du zahlst Rechenleistung, keine Dauer-Reserve für den Spitzenlastfall.
Das ist der Unterschied zwischen „GitLab läuft“ und „GitLab läuft auch noch, wenn etwas kaputtgeht“.
GitLab Community Edition als Managed Service: Mehr Freiheit durch Open Source
Jetzt kommt der Teil, der für Tüftler wirklich spannend ist. Wir hosten die Community Edition – die freie, quelloffene Variante. Und wir betreiben sie nicht als anonyme Mandanten-Schublade in einer Multi-Tenant-Plattform, sondern als deine Instanz auf einer Architektur, an der wir im Rahmen eines Projektgeschäfts so gut wie alles anpassen können.
Das ist ein fundamentaler Unterschied zum SaaS-Modell. Bei GitLab.com bekommst du, was im Menü steht. Punkt. Bei einem selbst gehosteten CE-Cluster, den jemand betreibt, der ihn auch umbauen kann, sieht die Frage plötzlich anders aus. Sie lautet nicht mehr „welches Feature hat mein Tarif“, sondern „was brauchst du wirklich“:
- Eine Anbindung an euer internes LDAP/Active Directory, euer SSO, euren Identity Provider? Machbar.
- Eigene Runner mit Spezial-Hardware – GPU für ML-Builds, ARM-Nodes, besonders dicke NVMe für Monorepo-Checkouts? Bauen wir in den Cluster.
- Integrationen in eure bestehende Welt – Ticketsystem, Monitoring, Secrets-Management, ein eigener Registry-Mirror, ein Deployment-Target in eurem Netz? Genau dafür ist die offene Architektur da.
- Komponenten daneben, die mit GitLab zusammenspielen sollen – OpenSearch fürs Log-Aggregat, ein interner Paket-Proxy, ein RAG-System auf eurem Code? Läuft im selben Cluster, unter eurer Kontrolle.
Open Source heißt hier nicht „die Sparvariante“. Es heißt: keine Lizenz-Wand, die irgendwann zwischen dir und der Funktion steht, die du brauchst. Was technisch geht, geht – und ist nicht an eine Subscription-Stufe gekoppelt.
Sie möchten wissen, ob GitLab in Ihrer Infrastruktur sinnvoll ist?
Wir zeigen Ihnen unverbindlich, wie ein GitLab-Cluster in Ihrer Umgebung aussehen kann – inklusive Aufwand, Betrieb und möglicher Integrationen.
Wann lohnt sich ein selbst gehostetes GitLab wirtschaftlich?
GitLab SaaS oder Self-Hosting: Kostenvergleich
Sei ehrlich – „mehr Kontrolle“ allein überzeugt keinen, der ein Budget verantwortet. Schauen wir auf die Zahlen.
Das SaaS-Modell rechnet pro Nutzer und pro Compute-Minute ab. Bei einem kleinen Team ist das bequem und günstig. Aber die Kurve ist linear nach oben offen: Jeder neue Entwickler kostet wieder den vollen Sitzplatzpreis, jede intensive Pipeline frisst Compute-Minuten. Ab einer gewissen Größe – nach unserer Erfahrung etwa ab 50 gleichzeitigen GitLab-Usern – wird das spürbar. Bei den Premium- und Ultimate-Tarifen reden wir schnell über mittlere vier- bis fünfstellige Beträge pro Monat, nur für Sitzplätze, die viele dieser Features gar nicht ausreizen.
Ab welcher Teamgröße sich GitLab Self-Hosting rechnet
Dem steht ein selbst gehosteter CE-Cluster gegenüber, dessen Kosten sich an der Rechenleistung orientieren, nicht an der Kopfzahl. Ein Cluster, der 50 Leute trägt, trägt oft auch 80 oder 120, ohne dass sich am Grundaufbau viel ändert. Die Kostenkurve flacht ab, wo die SaaS-Kurve weiter steigt. Irgendwo dazwischen kreuzen sich die beiden Linien – und ab diesem Punkt ist die selbst gehostete Variante nicht nur flexibler, sondern schlicht günstiger.
Damit kein falscher Eindruck entsteht: Self-Hosting ist nicht umsonst. Betrieb, Updates, Backups, Know-how – das kostet weiter. Aber es kostet eben Betrieb und nicht Lizenz. Und Betrieb skaliert anders als ein Pro-Kopf-Preis.
Datenschutz und Compliance: GitLab im eigenen Rechenzentrum betreiben
Der zweite Grund, warum „selbst betreiben“ wieder rational ist, hat sich in den letzten Jahren von einer Vorliebe zu einer handfesten Anforderung entwickelt.
Dein Quellcode ist eines der wertvollsten Assets deines Unternehmens. Bei einem US-SaaS-Anbieter liegt er in einer fremden Cloud, in einem fremden Rechtsraum, mit allem, was der US Cloud Act so mit sich bringt. Für manche ist das in Ordnung. Für viele – Industrie, kritische Infrastruktur, alles mit echtem Schutzbedarf – ist es das zunehmend nicht mehr. Stichworte NIS2 und KRITIS: Datenhoheit wird vom Wunsch zur Pflicht.
Auf einem Cluster, der entweder in deiner eigenen Umgebung oder auf klar definierter, DSGVO-konformer Infrastruktur in Deutschland läuft, ist diese Frage einfach beantwortet. Deine Daten verlassen den Rahmen nicht, den du dafür gesetzt hast. Du weißt, wo sie liegen, wer Zugriff hat und wie dieser Zugriff dokumentiert wird. Das ist kein Gefühl von Kontrolle – das ist Kontrolle.
Fazit: Für wen sich GitLab als Managed Service im eigenen Rechenzentrum lohnt
Lange war Self-Hosting die Sache der Überzeugungstäter: aufwendiger, oft teurer, dafür mit dem guten Gefühl, alles selbst in der Hand zu haben. Dieses Bild stimmt nicht mehr.
Mit einem modernen Unterbau – Kubernetes auf einem immutable OS, redundant und hochverfügbar – wird aus der handgepflegten Bastelkiste eine reproduzierbare, wartbare, ausfallsichere Plattform. Mit der Community Edition als offener Basis wird aus „du bekommst, was im Tarif steht“ ein „wir bauen, was du brauchst“. Und ab einer gewissen Teamgröße ist das Ganze nicht nur flexibler und datenschutzrechtlich sauberer, sondern auch günstiger als das SaaS-Pendant.
Das Schöne daran: Du musst dich nicht zwischen „selbst machen“ und „abgeben“ entscheiden. Du behältst die Kontrolle über deine Infrastruktur – und überlässt den Betrieb trotzdem Leuten, die Kubernetes, immutable Systeme und GitLab nicht zum ersten Mal sehen. Die Kontrolle bleibt bei dir. Die Bereitschaftsdienst-Nächte übernehmen wir.
*Die Esono AG ist ein unabhängiger Managed Service Provider und spezialisiert auf den Betrieb der GitLab Community Edition (CE) auf moderner Kubernetes-Infrastruktur. GitLab ist eine eingetragene Marke der GitLab, Inc. Die Esono AG steht in keiner geschäftlichen Verbindung zu GitLab, Inc.