GitLab Hosting auf EU-Servern gibt Teams die volle Kontrolle über Code, Pipelines und Daten, ohne Abhängigkeit von US-Anbietern. Für den Betrieb eignet sich eine containerisierte Umgebung auf einem leistungsfähigen EU-Server oder einer Cloud-Infrastruktur. Die benötigten Ressourcen lassen sich dabei flexibel an Teamgröße und Nutzung anpassen. CI/CD läuft über selbst verwaltete GitLab Runner, die sich ebenfalls in separaten Containern oder einer eigenen Container-Umgebung betreiben lassen.

Wer sensible Repositories verwaltet oder unter DSGVO arbeitet, kommt an einer selbst gehosteten Instanz auf europäischen Servern schwer vorbei.

GitLab auf EU-Server

GitLab.com ist bequem, aber nicht unbedingt die richtige Antwort für europäische Teams, die Code als regulierte Ressource behandeln müssen. 

Sobald Compliance-Anforderungen ins Spiel kommen, oder sobald das Team eine bestimmte Größe erreicht, dreht sich die Kostenrechnung. Self-hosted GitLab auf einem europäischen Server ist dann fast immer die bessere Wahl.

Dieser Guide erklärt, wie GitLab Hosting technisch funktioniert, welche Ressourcen Sie brauchen, wie Sie CI/CD-Pipelines mit selbst verwalteten Runnern aufsetzen, und worauf es bei einem EU-Server-Anbieter wirklich ankommt.

Was GitLab Hosting eigentlich bedeutet

GitLab Hosting bezeichnet den Betrieb einer eigenen GitLab-Instanz auf eigener oder gemieteter Infrastruktur, statt der SaaS-Variante GitLab.com zu nutzen. Der Fachbegriff dafür ist „self-managed" oder „self-hosted GitLab".

Der Kern ist immer derselbe: Sie betreiben die komplette Plattform, inklusive Git-Repositories, CI/CD-Pipelines, Container Registry, Issue-Tracker und Wiki, auf Ihren Servern. Damit haben Sie die volle Kontrolle über Speicherort, Zugriffsrechte und Ressourcen.

Zwei Editionen stehen zur Wahl:

1. GitLab Community Edition (CE). Open Source, kostenlos, deckt Git, CI/CD, Container Registry und die Kern-Funktionen ab.
2. GitLab Enterprise Edition (EE). Kostenpflichtig, mit erweiterten Features wie Merge-Request-Approvals, Compliance-Frameworks und Advanced Security.

Für die meisten Teams, die täglich Code ausliefern, reicht die CE. Fehlende Features sind meist Komfort, nicht Notwendigkeit.

Warum EU-Server für GitLab die richtige Wahl sind

Der Grund ist einfach: Ihr Quellcode ist ein Vermögenswert. Wo er physisch liegt und welchem Recht der Anbieter untersteht, ist keine Nebensächlichkeit.

GitLab.com und Datenstandort

US-basierte Cloud-Anbieter und der CLOUD Act

US-basierte Cloud-Anbieter können unter bestimmten Voraussetzungen dem US CLOUD Act unterliegen. Dabei kann es – abhängig von Anbieter, Datenzugriff und rechtlicher Konstellation – zu Herausgabeanforderungen gegenüber Daten kommen, auch wenn diese in einem europäischen Rechenzentrum gespeichert sind. Für Unternehmen mit hohen Anforderungen an Datenhoheit und Compliance kann die Wahl eines europäischen bzw. selbst kontrollierten Infrastrukturbetreibers daher relevant sein.

Für Enterprise-Kunden, Behörden, Gesundheitsunternehmen und Finanzdienstleister sollte insbesondere geprüft werden, welcher Anbieter Zugriff auf die Daten hat, wo die Daten verarbeitet werden und welche rechtlichen Verpflichtungen für den Anbieter gelten.

Bei GitLab.com zahlen Sie pro Nutzer

Bei GitLab.com können die Kosten bereits bei wenigen kostenpflichtigen Nutzern schnell in den dreistelligen Bereich steigen, insbesondere wenn zusätzlich CI/CD-Minuten und Speicher benötigt werden. Self-hosted GitLab CE/Core verursacht dagegen keine nutzerabhängigen Lizenzkosten. Wenn der Server ohnehin betrieben wird, bleiben die zusätzlichen Kosten unabhängig davon, ob 10 oder 50 Entwickler darauf arbeiten, weitgehend konstant.

Sie behalten die volle Datenhoheit

Backup-Strategie, Retention, Verschlüsselung, Zugriffskontrolle. Alles unter Ihrer Kontrolle, nicht unter der eines US-Anbieters.

Ein europäischer Anbieter mit Rechenzentren in Deutschland, Österreich oder der Schweiz löst diese Punkte strukturell. Bei peaknetworks läuft die komplette Infrastruktur auf HPE-Server in DACH-Rechenzentren, ohne US-Eigentum und ohne US-Subunternehmer in der Verarbeitungskette. 

Was für DSGVO-kritische DevOps-Setups genau das ist, was der CLOUD Act nicht angreifen kann.

Systemanforderungen für self-hosted GitLab

GitLab ist ressourcenhungrig. Wer die Anforderungen unterschätzt, erlebt eine langsame UI, brechende Pipelines und frustrierte Entwickler. Die realistischen Mindestwerte für den Produktivbetrieb:

1. CPU-Leistung

Mindestens 8 vCPUs für kleine bis mittlere Teams. Bei aktiver CI/CD-Nutzung mit parallelen Pipelines eher 12 vCPUs. GitLab selbst nutzt mehrere Worker-Prozesse (Puma, Sidekiq, Gitaly), die von zusätzlichen Kernen deutlich profitieren.

2. Arbeitsspeicher (RAM)

Für eine GitLab-Installation empfiehlt GitLab als Single-Node-Baseline 16 GB RAM. In speicherbeschränkten Umgebungen kann GitLab zwar mit mindestens 8 GB RAM betrieben werden, für einen produktiven Betrieb mit aktiven CI/CD-Pipelines empfiehlt sich jedoch mehr Arbeitsspeicher. Die GitLab Runner sollten dabei möglichst getrennt von der GitLab-Instanz betrieben werden, da CI/CD-Jobs zusätzliche CPU- und RAM-Ressourcen benötigen. Bei größeren Teams, vielen parallelen Pipelines oder umfangreichen Repositories sollte die Ausstattung entsprechend höher dimensioniert werden.

3. Storage

NVMe-SSDs sind hier Pflicht, nicht Empfehlung. Git-Repositories und CI/CD-Jobs erzeugen sehr viele Read- und Write-Operationen. Rechnen Sie mit mindestens 100 GB für den Start, plus extra Speicher für Container Registry und Artefakte. Bei aktiver Nutzung wachsen diese Volumes schnell.

4. Datenbank

GitLab nutzt PostgreSQL. Für kleine Setups reicht die integrierte Instanz, für größere Teams lohnt sich eine separate Datenbank-Instanz, entweder auf einem eigenen Server oder als Managed PostgreSQL. 

Das entlastet den GitLab-Server und verbessert die Antwortzeiten spürbar.

5. Netzwerk

Solide Anbindung mit stabiler Bandbreite. CI/CD-Jobs übertragen oft mehrere GB an Artefakten und Container-Images. Ein Server mit gedrosseltem Uplink wird zum Bottleneck.

6. Betriebssystem

Ubuntu 22.04 LTS ist eine naheliegende Wahl für eine klassische Installation. Debian, RHEL und openSUSE werden ebenfalls offiziell unterstützt. Alternativ lässt sich GitLab auch containerisiert betreiben, beispielsweise mit Docker oder Podman, wodurch die zugrunde liegende Linux-Distribution flexibler gewählt werden kann.

Installation: Docker Compose oder native Package

Für GitLab-Installationen haben sich zwei Wege etabliert. Welche Variante sinnvoller ist, hängt von der vorhandenen Infrastruktur und den Anforderungen an Betrieb und Verwaltung ab.

Docker Compose

Eine containerisierte Installation eignet sich für GitLab-Installationen jeder Größe. GitLab läuft dabei in einer isolierten Umgebung mit getrennten persistenten Volumes für Konfiguration, Daten und Logs. Vorteile sind einfache Updates, eine klare Trennung der Komponenten und eine flexible Infrastruktur.

Ein typisches Setup umfasst drei Container:

• Der GitLab-Server selbst (gitlab/gitlab-ce)
• Ein GitLab Runner für CI/CD (gitlab/gitlab-runner)
  
• Optional eine eigene Container Registry für Docker- und OCI-Images
• Optional ein Reverse-Proxy wie Nginx oder Traefik für SSL-Termination

Eine Container-Umgebung eignet sich besonders dann, wenn bereits Docker oder Podman eingesetzt wird. Auch Persistent Volumes, Backups, Monitoring und eine separate Container Registry lassen sich damit sauber integrieren.

Omnibus Package

Die offizielle Omnibus-Distribution ist eine bewährte Option für klassische Installationen. Der Installer bringt die benötigten Komponenten wie GitLab, PostgreSQL, Redis und Nginx vorkonfiguriert mit. Updates und Wartung erfolgen zentral über die GitLab-Installation.

Der Vorteil liegt in der geringeren Komplexität bei einer klassischen Serverinstallation. Wer GitLab ohne eigene Container-Infrastruktur betreiben möchte, erhält damit eine unkomplizierte und gut dokumentierte Lösung. Die GitLab Container Registry kann bei Bedarf ebenfalls ergänzt und separat betrieben werden.

GitLab Runner einrichten für CI/CD

Ohne Runner keine CI/CD-Pipelines. Ein Runner ist der Prozess, der Ihre Jobs tatsächlich ausführt: docker build, npm test, terraform apply, was immer im .gitlab-ci.yml steht.

Shared oder dedicated Runner?

Kleine Teams starten oft mit einem Runner auf demselben Server wie GitLab selbst. Das funktioniert, ist aber nicht ideal, weil CI-Jobs die GitLab-UI verlangsamen können.

Sobald Pipelines wichtiger werden, empfiehlt sich ein separater Server oder eine Cluster-basierte Runner-Umgebung. In einem Managed Kubernetes lassen sich Runner automatisch skalieren: mehr Traffic bedeutet mehr Runner-Pods, weniger Traffic bedeutet automatische Reduktion. Für Teams mit schwankenden Build-Zeiten die günstigste Option auf lange Sicht.

Executor-Wahl

GitLab Runner unterstützt mehrere Executor-Typen. Die drei wichtigsten:

• Docker Executor. Standard für die meisten Setups. Jeder Job läuft in einem sauberen Container. Reproduzierbar, sicher, gut isoliert.
• Shell Executor. Läuft direkt auf dem Host. Einfach, aber weniger sicher, weil Jobs ohne Isolation den Runner-Server berühren.
• Kubernetes Executor. Für skalierbare Setups. Jeder Job wird als eigenes Pod ausgeführt. Ideal für größere Teams mit variabler Last.

Registrierung des Runners

Seit GitLab 17.0 laufen Runner-Registrierungen über Authentication Tokens, die mit glrt- beginnen. Die alten Registration Tokens sind deprecated. Der Ablauf ist einfach:

1. Runner in GitLab anlegen (Instance-, Group- oder Project-Level)
2. Auth-Token kopieren
3. Runner auf dem Zielserver installieren und mit Token registrieren
4. Executor und Konfiguration in config.toml festlegen

Die offizielle GitLab-Dokumentation zu Runner-Requirements listet unterstützte Betriebssysteme und Architekturen im Detail.

Sicherheit und DSGVO in der Praxis

Self-hosted GitLab bringt Verantwortung mit sich. Diese Punkte gehören bei jedem Setup zum Pflichtprogramm.

SSL überall. Let's Encrypt reicht für die meisten Setups, mit automatischer Erneuerung. Bei Enterprise-Setups oft Zertifikate über eigene CA.

Two-Factor Authentication (2FA). Idealerweise für alle Nutzer erzwingen, mindestens für Admins. In den GitLab-Einstellungen aktivierbar.

Firewall-Regeln. SSH-Zugriff nur über VPN oder von definierten IPs. HTTP-Zugang nur über Reverse Proxy mit TLS-Termination. Alles andere geschlossen.

Audit-Logs. GitLab protokolliert Logins, Konfigurationsänderungen und sicherheitsrelevante Events. Diese Logs sollten zentral gesammelt und regelmäßig überprüft werden.

Backups. Repository-Daten, PostgreSQL, Uploads, Container Registry und Konfiguration gehören in eine zentrale Backup-Strategie. Georedundante Backups auf einem separaten Standort sind für kritische Setups Pflicht.

Auftragsverarbeitungsvertrag (AVV). Bei Hosting und Cloud-Diensten ist ein AVV wichtig, wenn der Anbieter personenbezogene Daten im Auftrag des Kunden verarbeitet. Art. 28 DSGVO schreibt hierfür einen entsprechenden Vertrag oder ein anderes verbindliches Rechtsinstrument vor. Für Unternehmen in regulierten Branchen können zusätzlich Zertifizierungen wie ISO 27001 oder Nachweise nach BSI IT-Grundschutz eine wichtige Rolle spielen.

Bei uns läuft die GitLab-Instanz standardmäßig in DACH-Rechenzentren, mit täglichen Backups, HPE-Enterprise-Hardware und Support von denselben Entwicklern, die die Plattform gebaut haben. 

Für Teams, die keine eigene Infrastruktur betreiben wollen, aber trotzdem volle Datensouveränität brauchen, ist das oft der pragmatischste Weg.

Kosten: Was self-hosted GitLab realistisch kostet

Die Rechnung fällt fast immer zugunsten von self-hosted aus, sobald das Team über die kostenlose GitLab.com-Grenze wächst.

Kleines bis Mittleres Team (5-30 Entwickler)

Für Teams dieser Größe bietet sich eine GitLab-Installation mit 8 vCPUs und mindestens 16 GB RAM als solide Ausgangsbasis an. Je nach Anzahl der Repositories, parallelen Zugriffen und CI/CD-Workloads können zusätzliche Ressourcen oder separate GitLab Runner erforderlich sein. 100 GB NVMe-Speicher können für den Einstieg ausreichen, sollten aber bei größeren Repositories, vielen Container-Images oder umfangreichen Artefakten entsprechend erweitert werden. Realistisch: 100 bis 200 Euro pro Monat.

Großes Team (30+ Entwickler mit aktiver CI/CD-Last)

Für größere Teams bieten sich container- oder Kubernetes-basierte Setups mit getrennt betriebenen und bei Bedarf skalierbaren GitLab Runnern an. Je nach Anforderungen kommen zusätzlich Managed-Support, Backups, Monitoring und eine eigene Container Registry hinzu. Die tatsächlichen Kosten hängen daher stark von Ressourcen, CI/CD-Auslastung und Storage ab.

Zum Vergleich: GitLab.com Premium kostet aktuell 29 USD pro Nutzer und Monat. Ein 20-Personen-Team kommt damit auf rund 580 USD monatlich. Premium beinhaltet bereits 10.000 Compute-Minuten und 500 GB Speicher; zusätzlicher Verbrauch kann weitere Kosten verursachen.

Bei einer selbst gehosteten GitLab-Instanz entfallen die nutzerabhängigen Lizenzkosten von GitLab. Dadurch kann sich Self-Hosting – abhängig von Infrastruktur, Support und Auslastung – bereits bei mittleren Teamgrößen wirtschaftlich lohnen.

Worauf Sie bei der Anbieterwahl achten sollten

Der EU-Server-Markt ist voll, aber nicht jeder Anbieter passt zu GitLab. Diese Punkte trennen ernsthafte Optionen von den anderen.

Standort und Jurisdiktion

Rechenzentren in Deutschland, Österreich oder der Schweiz, kombiniert mit einem europäischen Firmensitz, bieten klare Vorteile bei Datenschutz, Datenhoheit und Compliance. Entscheidend sind auch Datenflüsse, Zugriffsrechte und eingesetzte Dienstleister.

Ressourcen-Skalierung

GitLab-Instanzen wachsen mit den Anforderungen. Ein Anbieter, der CPU, RAM und Storage flexibel anpassen kann, erspart spätere Migrationen. Containerisierte Umgebungen bieten dabei zusätzliche Flexibilität bei der Ressourcenverwaltung.

Snapshot- und Backup-Strategie

Automatische Snapshots vor Updates, regelmäßige Backups und eine einfache Wiederherstellung sind wichtige Grundlagen. Bei geschäftskritischen Installationen können zusätzlich redundante oder geografisch getrennte Backups sinnvoll sein.

SLAs und Support-Tiefe

GitLab ist geschäftskritisch, sobald Teams damit arbeiten. Ein Anbieter mit klaren SLAs und einem Support-Team, das Server-Probleme wirklich versteht, macht den Unterschied bei Ausfällen. Worauf es bei der Anbieterwahl insgesamt ankommt, geht über GitLab hinaus, aber die Kriterien sind identisch.

Migration

Wer bereits GitLab.com nutzt oder von einem anderen Provider wechseln möchte, kann die Migration ohne zusätzlichen Aufwand durchführen lassen. Bei uns ist die Migration standardmäßig inklusive – von der Übernahme der Projektdaten und Repositories bis zur Übertragung der Container Registry. Vor der Live-Schaltung wird die Umgebung getestet, damit der Wechsel möglichst reibungslos erfolgt.

Häufige Stolperfallen und wie Sie sie vermeiden

Aus der Praxis: Diese Fehler tauchen bei GitLab-Setups immer wieder auf.

Zu wenig RAM zugewiesen. GitLab läuft auf 8 GB, aber schlecht. Sidekiq-Jobs stauen sich, die UI wird träge. Von Anfang an mit 16 GB starten spart Nerven.

Runner auf dem GitLab-Server. Funktioniert, bis der erste große Build läuft. Dann fällt die UI aus, und alle Nutzer sehen 502er. Runner auf separatem Server oder in einer Container-Umgebung ist die stabile Lösung.

Fehlende Backup-Tests. Backups zu haben ist eine Sache. Sie regelmäßig zu testen ist eine andere. Ein regelmäßiger Restore-Test auf einer Staging-Instanz zeigt, ob sich die Backups tatsächlich wiederherstellen lassen. GitLab empfiehlt ausdrücklich, den vollständigen Restore-Prozess vor dem Einsatz in Produktion zu testen.

Vergessene TLS-Erneuerung. Let's-Encrypt-Zertifikate haben eine begrenzte Gültigkeit und müssen automatisch erneuert werden. Je nach Setup übernimmt das beispielsweise GitLab selbst, ein Reverse-Proxy wie Traefik oder ein separates Zertifikatsmanagement. Entscheidend ist, die automatische Erneuerung einzurichten und ihre Funktion regelmäßig zu überwachen.

Kein Monitoring. GitLab stellt Prometheus-Metriken für die Überwachung der Instanz bereit. Mit Prometheus und Grafana lassen sich unter anderem CPU-, RAM-, Storage- und anwendungsspezifische Metriken überwachen und Alarme konfigurieren, bevor Ressourcenengpässe zu Problemen führen.

Upgrades ohne Vorbereitung. GitLab-Upgrades sollten nicht einfach auf einer produktiven Instanz durchgeführt werden. Je nach Ausgangs- und Zielversion können bestimmte Upgrade-Schritte und Zwischenversionen erforderlich sein. Vor größeren Upgrades empfiehlt sich ein Test auf einer Staging-Instanz sowie ein aktuelles, getestetes Backup.

Fazit

GitLab Hosting auf EU-Server ist die richtige Wahl, wenn Sie Code als geschäftskritische Ressource behandeln und wenn Ihr Team groß genug ist, um von GitLab.com wegzuziehen. Sie bekommen volle Datensouveränität, kalkulierbare Kosten und die Freiheit, Ihre CI/CD-Umgebung genau nach Ihren Anforderungen zu bauen.

Für kleinere Teams kann ein einzelnes Container-Setup ausreichen. Bei intensiver CI/CD-Nutzung bieten sich getrennte GitLab Runner oder skalierbare Container- bzw. Kubernetes-Setups an. Bei datenschutz- und compliance-relevanten Projekten sollten zusätzlich Datenstandort, Zugriffsrechte und die Jurisdiktion des Anbieters berücksichtigt werden.

Wenn Sie überlegen, GitLab bei uns zu betreiben oder von GitLab.com zu migrieren, sprechen Sie mit unserem Team. Wir schauen uns Ihr Setup an, sagen Ihnen ehrlich, was Sie brauchen, und übernehmen die Migration kostenlos.

FAQs

Kann ich GitLab kostenlos self-hosten?
Ja. GitLab Community Edition (CE) ist Open Source und MIT-lizenziert. Für den Betrieb fallen lediglich die Kosten für die benötigte Infrastruktur an. Alternativ gibt es GitLab Enterprise Edition (EE), die ebenfalls kostenlose Funktionen bietet und bei Bedarf durch kostenpflichtige Abonnements um zusätzliche Features erweitert werden kann.

Wie viele CPU-Kerne braucht GitLab wirklich?
GitLab nennt 8 vCPUs als Baseline für eine Single-Node-Installation. Der tatsächliche Bedarf hängt jedoch von Teamgröße, Zugriffen, Repositories und insbesondere der Auslastung durch CI/CD ab. Bei größeren Teams oder intensiven Workloads können zusätzliche CPU-Ressourcen sinnvoll sein.

Ist GitLab.com nicht DSGVO-konform?
GitLab.com kann grundsätzlich DSGVO-konform eingesetzt werden, allerdings müssen je nach Einsatzszenario insbesondere Auftragsverarbeitung, Datenstandorte und internationale Datentransfers berücksichtigt werden. Für Unternehmen mit strengen Anforderungen an Datenhoheit und Datenstandort kann eine selbst gehostete GitLab-Instanz auf EU-Infrastruktur eine einfachere Lösung sein, da Speicherort und Infrastruktur selbst bestimmt werden können.

Wie migriere ich von GitLab.com zu einer self-hosted Instanz?
GitLab bietet verschiedene Export- und Importmöglichkeiten für die Migration von Projekten. Je nach verwendeter Methode lassen sich unter anderem Repositories, Issues, Merge Requests und weitere Projektdaten übertragen. CI/CD-Konfigurationen und Inhalte der Container Registry müssen je nach Setup gegebenenfalls separat übernommen werden. Eine vollständige Migration sollte daher vorab anhand der tatsächlich verwendeten GitLab-Funktionen geplant und getestet werden.

Brauche ich Kubernetes für GitLab CI/CD?
Nein. GitLab Runner kann beispielsweise mit Docker- oder Shell-Executors betrieben werden. Kubernetes wird interessant, wenn CI/CD-Workloads dynamisch skaliert werden sollen oder Jobs isoliert als eigene Pods ausgeführt werden sollen. Für kleinere Teams reicht häufig ein einzelner Runner.

Wie oft muss ich GitLab updaten?
GitLab veröffentlicht monatlich eine neue Minor-Version und in der Regel zweimal monatlich Patch-Releases mit Fehler- und Sicherheitskorrekturen. Major-Releases erscheinen jährlich. Sicherheitsupdates sollten zeitnah eingespielt werden. Bei größeren Versionssprüngen müssen die von GitLab vorgegebenen Upgrade-Pfade und gegebenenfalls erforderlichen Zwischenversionen berücksichtigt werden. Vor produktiven Upgrades empfiehlt sich ein aktuelles Backup und – bei größeren Versionssprüngen – ein Test in einer Staging-Umgebung.