So hostest du GitLab CE selbst auf einem VPS

Es ist Freitagnachmittag, der Pull Request deines Teams wartet auf das Review, und dein Laptop meldet sich mit einer altbekannten Nachricht: GitHub hat schon wieder Probleme.

Vielleicht hängen die Actions.

Vielleicht liefert git push diesen Monat schon zum dritten Mal einen 500-Fehler.

Der Thread im Team-Chat hat bereits acht Nachrichten.

Beim ersten Mal lachst du darüber. Beim zweiten Mal postet jemand einen Link zur Statusseite von GitHub, und ihr holt euch alle einen Kaffee. Beim dritten Mal, meistens kurz vor einem Release, spricht endlich jemand die Frage laut aus: Sollten wir das nicht einfach selbst hosten?

Für die meisten Teams lautet die ehrliche Antwort: nein. GitLab.com Free deckt kleine Teams problemlos ab. Ein eigener Server für die Versionsverwaltung kostet dich außerdem laufend Zeit und Aufwand.

Diesen Tausch gehst du nur ein, wenn du einen guten Grund dafür hast.

Vielleicht hat dein Team genau so einen Grund: einen Kundenvertrag, der SaaS-Angebote von Drittanbietern verbietet, Compliance-Vorgaben oder eine Rechnung für Nutzerlizenzen, die langsam absurd aussieht. Dann ist ein selbstgehostetes GitLab CE die sauberste Lösung. Es ist Open Source und läuft auf einem einzigen VPS. Ist es einmal eingerichtet, kostet dich die Wartung etwa eine Stunde im Monat.

Wir bei DreamHost haben unzählige selbstverwaltete Server gehostet und dabei immer wieder ein Muster beobachtet: Entwickler, die mit selbstgehostetem GitLab erfolgreich sind, wählen von Anfang an den richtigen Tarif und bereiten Secure Shell Protocol (SSH) und Domain Name System (DNS) sauber vor. Sobald alles stabil läuft, widerstehen sie dem Drang, weiter daran herumzubasteln.

Warum solltest du GitLab selbst hosten, statt GitLab.com zu nutzen?

GitLab selbst zu hosten lohnt sich, wenn GitLab.com oder GitHub.com deine Anforderungen an Datenschutz, Compliance oder Kostenkontrolle nicht erfüllen. Für die meisten anderen Teams ist die gehostete Variante die bessere Wahl.

Drei Gründe halten einer genauen Prüfung stand:

1. Datenschutz und Datenhoheit: Dein Quellcode liegt auf einer Infrastruktur, die du selbst verwaltest und nach deinem eigenen Zeitplan patchst. Kein Zugriff durch Dritte, keine geteilte Plattform, und ein Sicherheitsvorfall bleibt auf deinen eigenen Server beschränkt.
2. Compliance: Regulierte Branchen wie Gesundheitswesen, Finanzwesen und öffentliche Verwaltung müssen oft genau kontrollieren, wo ihre Daten gespeichert werden. Mit selbstgehostetem GitLab CE hältst du deinen Code am einfachsten innerhalb einer kontrollierten Umgebung.
3. Kostenkontrolle bei wachsenden Teams: GitLab.com berechnet pro aktivem Nutzer. Laut der Preisseite von GitLab kostet Premium 29 US-Dollar pro Nutzer und Monat, die Preise für Ultimate gibt es nur auf Anfrage. Ein Team mit 50 Personen zahlt für Premium also 17.400 US-Dollar pro Jahr, Add-ons noch nicht eingerechnet. Ein selbstverwalteter VPS plus eine Stunde Wartung im Monat ist oft günstiger.

Seid ihr ein Zwei-Personen-Team ohne besondere Anforderungen an Datenschutz oder Compliance, ist der kostenlose Tarif von GitLab die richtige Wahl. (Ja, wir wissen, dass das aus dem Mund eines Hosting-Anbieters seltsam klingt.)

Beim Selbsthosten tauschst du eine monatliche SaaS-Rechnung gegen laufenden Betriebsaufwand. Dieser Tausch lohnt sich nur, wenn du einen guten Grund für den Wechsel hast.

Hier siehst du, wann diese Option sinnvoll ist und wann nicht:

GitLab Community Edition ist unter einer MIT-ähnlichen Open-Source-Lizenz kostenlos. Es gibt keine Nutzerbegrenzung, keine gesperrten Grundfunktionen und keine Upgrade-Hinweise. Die gesamte Plattform gehört dir.

Welche Hardware-Anforderungen hat GitLab CE?

GitLab CE hat klare Hardwareanforderungen. Ob du sie triffst, entscheidet darüber, ob deine Installation flott läuft oder ständig auf den Swap-Speicher ausweicht. Das ist Festplattenspeicher, den dein Betriebssystem nutzt, wenn der RAM voll ist.

Laut den offiziellen Installationsanforderungen von GitLab wird die Dimensionierung in Anfragen pro Sekunde angegeben und nicht in festen Stufen pro Nutzer. Die veröffentlichte Basis liegt bei 8 vCPU und 16 GB RAM für bis zu 1.000 Nutzer (etwa 20 Anfragen pro Sekunde). Kleinere Teams kommen mit weniger aus. Die dokumentierte Untergrenze für Testzwecke liegt bei 2 GB RAM plus 1 GB Swap, unter 4 GB leidet die Performance allerdings spürbar.

Eine frische GitLab-Installation belegt im Leerlauf etwa 4–6 GB. Sobald CI/CD-Jobs laufen, steigt der Speicherverbrauch schnell an. Plane also Reserven ein, sonst wird es langsam.

Beim Speicherplatz liegt die offizielle Basis von GitLab bei 40 GB plus Größe der Repositories. In der Praxis sind 50 GB ein sichererer Startpunkt, denn Repositories wachsen und Build-Artefakte häufen sich an. NVMe, eine schnellere Art von SSD-Speicher, macht bei Git-Operationen und beim Lesen des CI-Caches einen spürbaren Unterschied.

So passen diese Anforderungen zu den VPS-Hosting-Tarifen von DreamHost:

Für die meisten Teams mit echten CI/CD-Pipelines ist Stack 32 der richtige Tarif. Er ist der einzige Stack, der die Basis von GitLab mit 8 vCPU erfüllt. Stack 16 hat genug Speicher, aber nur die Hälfte der Kerne, eignet sich also eher zum Testen. Das klingt übertrieben, bis du siehst, wie beim ersten Build Sidekiq, Postgres und ein Runner gleichzeitig hochschießen*.*

Mit 16 GB RAM hast du genug Reserven für die Dienste von GitLab (bei einer Standardinstallation etwa 4 bis 6 GB im Leerlauf) und ein paar CI-Worker (je 1–2 GB). Alles kann gleichzeitig unter Last laufen, ohne dass es im Team-Chat jemand merkt.

Wie bereitest du dein VPS auf die Installation von GitLab vor?

Nimm dir 10 Minuten für die Vorbereitung. Das zahlt sich spätestens beim ersten Neustart aus. Folge einfach diesen Schritten:

1. VPS bereitstellen: Wähle Ubuntu 24.04 LTS. Diese Version wird von den offiziellen Omnibus-Paketen von GitLab unterstützt (dem All-in-one-Installer, den GitLab mitliefert) und bekommt noch jahrelang kostenlose Sicherheitsupdates.
   
2. Domain auf die IP des Servers verweisen: Lege einen A-Record an (den DNS-Eintrag, der eine Domain einer IP-Adresse zuordnet) und warte vor der Installation mindestens 15–30 Minuten, bis er sich verbreitet hat. Ohne diesen Eintrag schlägt die automatische SSL-Einrichtung fehl, weil die Zertifizierungsstelle nichts validieren kann.
   
3. Pakete aktualisieren: Verbinde dich mit ssh root@your-server-ip mit dem VPS und führe sudo apt update && sudo apt upgrade -y aus.
   
4. Abhängigkeiten installieren: Führe sudo apt install -y curl openssh-server ca-certificates perl postfix aus. Das Paket postfix ist ein Mailserver für ausgehende E-Mails, damit GitLab Benachrichtigungen zu Merge Requests und E-Mails zum Zurücksetzen des Passworts verschicken kann.
   Wenn der Installer nach der Mail-Konfiguration fragt, wähle Internet Site und gib deine Domain an. So kann GitLab sofort E-Mails versenden.
   Für den Produktivbetrieb: Verzichte auf das lokale Postfix und richte stattdessen in gitlab.rb ein SMTP-Relay ein. IPs von VPS-Servern stehen häufig auf Spam-Blocklisten, und E-Mails zum Zurücksetzen des Passworts landen über lokales Postfix oft im Spam. SendGrid, Mailgun und ähnliche SMTP-Relays funktionieren alle. Mehr dazu findest du in der Dokumentation zur SMTP-Konfiguration von GitLab.
   
5. Die richtigen Ports öffnen: Richte mit UFW (dem integrierten Firewall-Tool von Ubuntu) eine Firewall ein und gib die Ports 80, 443 und 22 frei.

sudo ufw allow http
sudo ufw allow https
sudo ufw allow ssh
sudo ufw enable

Wie installierst du GitLab CE mit dem Omnibus-Paket unter Ubuntu?

GitLab-CE-Repository hinzufügen:

curl -sSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Installiere dann GitLab CE und setze deine Domain als externe URL:

sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

Mit https:// weist du GitLab an, während der Installation automatisch ein Let’s Encrypt-Zertifikat anzufordern. Voraussetzung ist, dass die Ports 80 und 443 offen sind und DNS korrekt eingerichtet ist. Fehlt eines davon, läuft die Installation zwar durch, aber SSL schlägt fehl. Dann verbringst du die nächste halbe Stunde damit, etwas zu reparieren, das gar nicht kaputt ist.

Warte als Nächstes den Rekonfigurationsschritt ab.

GitLab führt am Ende der Installation automatisch gitlab-ctl reconfigure aus (den Befehl, der alle Änderungen an der Konfiguration von GitLab anwendet). Das dauert fünf bis 10 Minuten. Und ja, der Rekonfigurationsschritt dauert wirklich so lange.

Initiales Root-Passwort abrufen:

sudo cat /etc/gitlab/initial_root_password

Diese Datei wird automatisch erstellt und nach 24 Stunden gelöscht. Kopiere dir also das Passwort und melde dich an. Öffne deine Domain im Browser, melde dich als root an und ändere das Passwort sofort.

Überprüfe zum Schluss die Installation.

Lege über den Startbildschirm von GitLab ein Testprojekt an und pushe von deinem lokalen Rechner aus einen Commit dorthin. Klappt der Push und erscheint die Datei in der Weboberfläche, läuft die Installation einwandfrei.

Hängt der Rekonfigurationsschritt, schau in tail -f /var/log/gitlab/reconfigure/*.log. Dort findest du den eigentlichen Fehler.

Wie sicherst du eine selbstgehostete GitLab-Instanz ab?

GitLab bringt vernünftige Standardeinstellungen mit, die aber auf einen offenen Community-Server ausgelegt sind und nicht auf die private Instanz deines Teams. Nimm dir hier eine Stunde Zeit.

1. Offene Registrierung deaktivieren. Die offene Registrierung ist standardmäßig aktiviert. Gehe im Admin Area zu Settings > General > Sign-up restrictions und entferne den Haken bei Sign-up enabled. Sonst kann jeder mit der URL ein Konto anlegen.
2. Zwei-Faktor-Authentifizierung aktivieren. Gehe zu Admin Area > Settings > General > Sign-in restrictions und erzwinge 2FA für alle Nutzer. Verkürze die Übergangsfrist von standardmäßig 48 Stunden auf 8 Stunden.
3. Projekterstellung einschränken. Setze Default Project Creation auf Maintainers oder No one, je nachdem, wie streng du es haben willst.
4. SSL-Verlängerung prüfen. GitLab verlängert Let’s Encrypt-Zertifikate standardmäßig automatisch. Führe zur Kontrolle einmal sudo gitlab-ctl renew-le-certs aus und prüfe die Ausgabe.
5. SSH auf dem VPS selbst absichern. Deaktiviere die Root-Anmeldung per Passwort, erlaube nur die Authentifizierung per SSH-Schlüssel und verlege SSH (wenn es sich einrichten lässt) weg von Port 22. Ein selbstgehosteter Git-Server ist nur so sicher wie der Server, auf dem er läuft.

Wenn du tiefer einsteigen willst: GitLab hat einen Hardening Guide zu Authentifizierung, Verschlüsselung und Instanzeinstellungen veröffentlicht. Lies ihn einmal durch, setze um, was zu deinem Bedrohungsmodell passt, und mach dann weiter.

Wie sicherst du eine selbstgehostete GitLab-Instanz und stellst sie wieder her?

GitLab bringt ein eigenes Backup-Tool mit. Wenn du es zum ersten Mal brauchst, wirst du froh sein, es eingerichtet zu haben.

Backup erstellen:

sudo gitlab-backup create

Damit landet ein Tarball in /var/opt/gitlab/backups. Plane das Backup per Cron täglich ein und bewahre die Sicherungen sieben Tage lang auf. Führe sudo crontab -e aus und füge diese beiden Zeilen hinzu:

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
0 3 * * * find /var/opt/gitlab/backups -name "*.tar" -mtime +7 -delete

Das Flag CRON=1 unterdrückt die Fortschrittsanzeige, damit die Cron-Logs nicht zugemüllt werden.

Profi-Tipp: Das Daten-Backup enthält weder /etc/gitlab/gitlab-secrets.json noch /etc/gitlab/gitlab.rb.

Diese Dateien enthalten den Schlüssel zur Datenbankverschlüsselung, die Zwei-Faktor-Seeds und die CI/CD-Variablen. Die Konfigurationsgeheimnisse sind nicht Teil des regulären Backups und müssen separat gesichert werden. Stellst du die Daten ohne die Secrets-Datei wieder her, funktionieren Zwei-Faktor-Konten nicht mehr, verschlüsselte Variablen werden zu Datenmüll, und du verbringst einen langen Abend mit der Fehlersuche.

Füge das zum selben Cron Job hinzu:

sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/

Ein Backup lässt sich nur in derselben Version und Edition von GitLab wiederherstellen, in der es erstellt wurde (CE zu CE, nicht CE zu EE).

Sei bei Upgrades vorsichtig: Spiele kein altes Backup auf eine frisch installierte GitLab-Instanz ein, ohne die Installation vorher auf die passende Version herunterzustufen.

Teste die Wiederherstellung mindestens einmal. Ein Backup, das du nie getestet hast, ist einfach nur eine Datei.

Lohnt es sich für dein Team wirklich, GitLab selbst zu hosten?

Für die meisten Teams ist das Selbsthosten von GitLab eine Frage der Kontrolle. Manchmal geht die Kostenrechnung auf, aber der Grund, warum Teams beim Selbsthosten bleiben, ist selten der Posten in der Rechnung.

So viel Zeit kostet dich eine Installation für ein kleines Team realistisch pro Monat:

• ~30 Minuten Patchen – apt-Upgrades, Minor-Releases von GitLab
• ~15 Minuten Backup-Prüfung – Vertraue keinem Backup, das du nicht wiederhergestellt hast
• ~15 Minuten Kapazitätscheck – Speicherplatzbelegung, RAM-Reserven
• ~2x, wenn CI/CD auf demselben Server läuft – Ein ausgelasteter Runner kann die Last verdoppeln

Das ist etwa eine Stunde im Monat, wenn wenig los ist, oder zwei, wenn viel los ist.

Bei etwa 150 US-Dollar pro Stunde kosten 12 Stunden Betriebsaufwand rund 1.800 US-Dollar. Das entspricht ungefähr fünf Premium-Lizenzen auf GitLab.com.

Eine Fallstudie aus der Praxis von Mad Devs zeigt, wie das Team mit selbstgehostetem GitLab CE statt Premium-Lizenzen mehr als 10.000 US-Dollar pro Jahr spart. Diese Ersparnis stellt sich allerdings erst ein, wenn das Team so groß ist, dass die Nutzerlizenzen den größten Teil des Budgets ausmachen.

Für folgende Teams ist das Selbsthosten dagegen die falsche Wahl:

• Teams mit zwei bis drei Personen ohne Compliance-Gründe. GitLab.com Free reicht dir völlig. Der Betriebsaufwand übersteigt die eingesparten Kosten.
• Teams, in denen sich niemand auf der Kommandozeile wohlfühlt. Wohlfühlen heißt nicht, dass du Sysadmin-Niveau brauchst. Es heißt, dass du /var/log/gitlab-Fehler lesen kannst, ohne in Panik zu geraten.
• Teams, deren größter Engpass das Recruiting ist, nicht die Tools. Self-Hosting zieht Aufmerksamkeit vom Produkt ab. Wenn die Entwicklungsgeschwindigkeit der limitierende Faktor ist, ist eine gehostete Lösung die richtige Wahl.

Wann lohnt sich Self-Hosting also? Hier ein paar Szenarien:

• Regulierte Branchen mit ausdrücklichen Anforderungen an Datenresidenz oder Nachweisketten
• Teams in der EU oder im Vereinigten Königreich mit Bedenken zur Datensouveränität bei in den USA gehostetem Code
• Teams ab 30 Personen, bei denen Lizenzkosten pro Nutzer das Budget dominieren
• Kundenverträge, die SaaS von Drittanbietern für Quellcode verbieten

Lautet dein Grund GitHub rechnet pro Nutzer ab, fährst du damit vermutlich besser. Lautet dein Grund Ich will die Kontrolle haben, wirkt der Betriebsalltag womöglich weniger romantisch als erwartet.

Solltest du GitLab-CI/CD-Runner auf demselben VPS betreiben?

Zum Testen ja. Für den Produktivbetrieb nein.

Ein CI-Runner auf demselben Server zieht Arbeitsspeicher und CPU von der Oberfläche von GitLab ab. Das klassische Symptom: GitLab ist um 9 Uhr morgens langsam. Meist steckt ein Build dahinter, der die erste Pipeline des Tages startet und dem Web-Frontend die Ressourcen entzieht. Sauberer ist ein separates VPS für den Runner (ein Stack 8 pro Runner), das du über das Netzwerk bei der GitLab-Instanz registrierst.

Wenn die Runner unbedingt auf demselben Server laufen müssen, nimm Stack 32 und lass genug Luft für die Jobs.

Laut den Systemanforderungen von GitLab für Runner ist der Runner-Prozess selbst schlank. Die Workloads, die er ausführt, sind es nicht – und sie teilen sich CPU und Festplatte mit allem anderen, was GitLab auf dem Server erledigt.

Bereit für den Wechsel?

Zurück zum Team-Chat am Freitagnachmittag.

Wenn GitHub gelb wird und dein Team wieder darüber lacht und Kaffee holen geht, ist das völlig in Ordnung.

Aber was, wenn sich ein GitHub-Ausfall plötzlich ernst anfühlt?

Vielleicht gefährdet er einen Kundenvertrag? Er wird bei einem Compliance-Audit zum Thema? Oder die Lizenzrechnung hat endlich die Schmerzgrenze überschritten?

Dann wird es zu einer absolut vernünftigen Option, GitLab CE selbst zu hosten. Du brauchst nur einen VPS, eine Domain, eine Omnibus-Installation und eine Stunde für die Absicherung.

Wenn die Statusseite von GitHub das nächste Mal aufleuchtet, lässt sich dein Code weiterhin problemlos pushen.

Häufige Fragen zum Self-Hosting von GitLab