Wie Man GitLab CE Auf Einem VPS Selbst Hosten Kann

Es ist Freitagnachmittag, der Pull-Request deines Teams wartet auf Überprüfung, und dein Laptop meldet sich mit einer vertrauten Nachricht: GitHub hat mal wieder Probleme.

Vielleicht sind Aktionen steckengeblieben.

Vielleicht gibt `git push` zum dritten Mal in diesem Monat einen 500-Fehler zurück.

Der Thread in deinem Team-Chat enthält bereits acht Nachrichten.

Das erste Mal, wenn das passiert, lachst Du darüber. Das zweite Mal verlinkt jemand die GitHub-Statusseite, und Ihr geht alle Kaffee trinken. Das dritte Mal, meist kurz vor einem Veröffentlichungstermin, tippt schließlich jemand die Frage laut: „Sollten wir einfach unsere eigenen betreiben?“

Für die meisten Teams lautet die ehrliche Antwort nein. GitLab.com Free deckt kleine Teams bequem ab, und die Betriebskosten für das Betreiben eines eigenen Versionskontroll-Servers sind nicht null.

Es ist die Art von Handel, die man nur aus einem wirklichen Grund macht.

Wenn dein Team aus einem dieser Gründe, wie einem Kundenvertrag, der SaaS von Drittanbietern verbietet, einer Compliance-Grenze oder einer Sitzlizenzrechnung, die langsam lächerlich aussieht, selbst GitLab CE hosten möchte, ist das die sauberste Lösung, die du treffen kannst. Es ist Open Source, läuft auf einem einzelnen VPS und nach der Feinabstimmung dauert die Wartung etwa eine Stunde pro Monat.

Bei DreamHost haben wir unzählige selbstverwaltete Server gehostet und ein Muster festgestellt: Entwickler, die mit selbstgehosteten GitLab erfolgreich sind, wählen von Anfang an den richtigen Plan, setzen das Secure Shell Protocol (SSH) und Domain Name System (DNS) richtig um und widerstehen dann dem Drang, ständig weiter daran zu basteln, sobald es stabil läuft.

Warum Solltest Du GitLab Selbst Hosten Statt GitLab.com Zu Nutzen?

Du hostest GitLab selbst, wenn GitLab.com oder GitHub.com deine Anforderungen an Datenschutz, Compliance oder Kostenkontrolle nicht erfüllen können. Für die meisten anderen Teams ist die gehostete Option ein besserer Handel.

Drei echte Gründe halten einer Überprüfung stand:

1. Datenschutz Und Datensouveränität: Dein Quellcode befindet sich auf einer Infrastruktur, die Du verwaltest und nach eigenem Zeitplan aktualisierst. Kein Zugriff Dritter, keine gemeinsam genutzte Plattform, kein Breach-Blast-Radius über deinen eigenen Server hinaus.
2. Compliance: Regulierte Branchen wie das Gesundheitswesen, die Finanzbranche und die Regierung benötigen oft eine Kontrolle der Datenresidenz. Selbstgehostetes GitLab CE ist der einfachste Weg, den Code innerhalb einer kontrollierten Grenze zu halten. 
3. Kostenkontrolle Im Großen Maßstab: GitLab.com berechnet Gebühren pro aktiven Benutzer. Laut GitLab-Preisseite kostet Premium 29 $ pro Benutzer pro Monat, während Ultimate-Preise nur auf Anfrage verfügbar sind. Ein 50-Personen-Team bei Premium kostet vor Add-ons 17.400 $ pro Jahr. Ein selbstverwaltetes VPS plus eine Stunde monatliche Wartung kostet oft weniger.

Wenn ihr ein Zwei-Personen-Team seid und keine Datenschutz- oder Compliance-Gründe habt, ist die richtige Antwort die kostenlose Stufe von GitLab. (Ja, wir wissen, dass das komisch klingt, von einem Hosting-Unternehmen zu kommen).

Mit dem Eigenhosting tauschst Du eine monatliche SaaS-Rechnung gegen laufenden Betriebsaufwand. Das ist nur dann ein lohnender Tausch, wenn Du einen guten Grund für den Wechsel hast.

Hier ist, wo diese Option Sinn macht und wo nicht:

Szenario	Beste Wahl
Datenschutz- oder Compliance-Anforderungen	Self-hosted GitLab CE
Team größer als ~30 aktive Benutzer	Self-hosted ist oft günstiger
Code ist Ihr geistiges Eigentum und Sie möchten ihn lokal haben	Self-hosted GitLab CE
2-5 Personen Team, keine Compliance-Anforderungen	GitLab.com (kostenlos)
Sie möchten keinen Server patchen	GitLab.com

Die GitLab Community Edition ist kostenlos unter einer MIT-artigen Open-Source-Lizenz verfügbar. Es gibt kein Benutzerlimit, keine grundlegenden Funktionseinschränkungen und keine Aufforderungen zum Upgrade. Die gesamte Plattform steht Dir zur Verfügung.

Welche Hardware-Anforderungen Gibt Es Für GitLab CE?

GitLab CE hat klare Hardware-Schwellenwerte, und sie richtig einzustellen, macht den Unterschied zwischen einer flotten Installation und einer, die durch den Swap-Speicher (Festplattenspeicher, den dein Betriebssystem nutzt, wenn der RAM voll ist) hindurchrattert.

Laut den offiziellen Installationsanforderungen von GitLab wird die Größe in Anfragen pro Sekunde anstelle von festen Benutzerstufen ausgedrückt. Der veröffentlichte Standardwert beträgt 8 vCPU und 16 GB RAM für bis zu 1.000 Benutzer (etwa 20 Anfragen pro Sekunde). Kleinere Teams können mit weniger auskommen, bis hin zu einem dokumentierten Minimum von 2 GB RAM plus 1 GB Swap zur Bewertung, obwohl die Leistung unter 4 GB leidet.

Eine frische GitLab-Installation verbraucht im Leerlauf etwa 4-6 GB. Sobald CI/CD-Jobs ausgeführt werden, steigt der Speicherverbrauch schnell an. Plane also Spielraum ein — oder rechne mit Langsamkeit.

Was den Speicher betrifft, ist der offizielle Ausgangspunkt von GitLab 40 GB plus Repositorygröße, aber 50 GB sind in der Praxis ein sicherer Startpunkt. Repositories wachsen und Build-Artefakte häufen sich an. NVMe, eine schnellere Art von Solid-State-Speicher, macht einen spürbaren Unterschied bei Git-Operationen und CI-Cache-Lesevorgängen.

Hier siehst Du, wie diese Schwellenwerte den DreamHost VPS-Hosting-Stufen zugeordnet sind:

Anwendungsfall	Empfohlener RAM	DreamHost VPS-Stufe
Bewertung / persönlich	4 GB RAM	Stack 4
Kleines Team, geringe Nutzung	8 GB RAM	Stack 8
Bis zu ~1.000 Benutzer (Veröffentlichte Basislinie von GitLab)	16 GB RAM	Stack 16
CI/CD-Runner auf demselben Server betreiben	+ 2-8 GB RAM zusätzlich zu deiner Stufe	Größe anpassen (z. B. Stack 16 → Stack 32)

Der richtige Ausgangspunkt für die meisten Teams, die echte CI/CD-Pipelines betreiben, ist Stack 16. Das klingt nach Übermaß, bis Du den ersten Build startest und gleichzeitig Sidekiq, Postgres und ein Runner hochfahren.

16 GB RAM bieten genügend Spielraum für den Stapel von Diensten von GitLab (ungefähr 4 bis 6 GB im Leerlauf bei einer Standardinstallation) und ein paar CI-Worker (jeweils 1-2 GB), die gleichzeitig aktiv sein können, ohne dass es jemand im Team-Chat bemerkt.

Wie Bereitest Du Dein VPS Vor, Bevor Du GitLab Installierst?

Wende 10 Minuten für die Vorbereitung auf — es zahlt sich aus, beim ersten Neustart. Folge einfach diesen Schritten:

1. VPS Bereitstellen: Wähle Ubuntu 22.04 LTS oder 24.04 LTS. Beide werden von den offiziellen Omnibus-Paketen von GitLab unterstützt (das gebündelte All-in-One-Installationspaket, das GitLab liefert) und bieten noch Jahre kostenlose Sicherheitsupdates.
   
2. Eine Domain auf die IP des Servers Zeigen: Erstelle einen A-Eintrag (die Art von DNS-Eintrag, der eine Domain einer IP-Adresse zuordnet) und lass ihn mindestens 15-30 Minuten verbreiten, bevor du die Installation startest. Ohne diesen Eintrag wird die automatische SSL-Einrichtung fehlschlagen, da die Zertifizierungsstelle keinen Ort zur Validierung hat.
   
3. Pakete Aktualisieren: Verbinde dich mit dem VPS über `ssh root@deine-server-ip` 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, der ausgehende E-Mails verwaltet, sodass GitLab Merge-Request-Benachrichtigungen und Passwort-Resets senden kann.
   Wenn der Installer nach der Mail-Konfiguration fragt, wähle Internet Site und verwende deine Domain. Dies ermöglicht es GitLab, sofort Mails zu senden.
   Für den Produktionseinsatz: überspringe das lokale Postfix und konfiguriere stattdessen ein SMTP-Relay in gitlab.rb. IPs von VPS sind häufig auf Spam-Blocklisten, und über lokales Postfix geroutete Passwort-Reset-E-Mails landen oft im Spam. SendGrid, Mailgun und DreamHosts ausgehendes Relay funktionieren alle — siehe GitLabs SMTP-Konfigurationsdokumente.
   
5. Die Richtigen Ports Öffnen: Konfiguriere eine Firewall mithilfe von UFW (Ubuntus eingebautem Firewall-Tool) und erlaube die Ports 80, 443 und 22.

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

Wie Installierst Du GitLab CE Auf Ubuntu Mit Dem Omnibus-Paket?

Füge das GitLab CE-Repository hinzu:

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

Dann installiere GitLab CE mit deinem Domainnamen als externe URL:

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

Die Einstellung von `https://` hier weist GitLab an, während der Installation automatisch ein Let’s Encrypt-Zertifikat anzufordern, solange die Ports 80 und 443 offen sind und DNS korrekt gerichtet ist. Wenn einer von diesen nicht bereit ist, wird die Installation abgeschlossen, aber SSL schlägt fehl – und Du verbringst die nächsten dreißig Minuten mit der Fehlersuche bei etwas, das eigentlich nicht defekt ist.

Als Nächstes warte auf den Schritt zur Neukonfiguration.

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

Hole das anfängliche Root-Passwort:

sudo cat /etc/gitlab/initial_root_password

Diese Datei wird automatisch erstellt und in 24 Stunden gelöscht, also notiere das Passwort und melde Dich an. Besuche Deine Domain in einem Browser, melde Dich als `root` an und ändere das Passwort sofort.

Überprüfe schließlich die Installation.

Auf dem Willkommensbildschirm von GitLab erstelle ein Testprojekt. Führe einen Commit von Deinem lokalen Rechner aus und pushe diesen. Wenn der Push erfolgreich ist und die Datei in der Web-Benutzeroberfläche erscheint, funktioniert die Installation einwandfrei.

Wenn der Schritt zur Neukonfiguration hängen bleibt, überprüfe `tail -f /var/log/gitlab/reconfigure/*.log`. Dort befindet sich der eigentliche Fehler.

Wie Sperrst Du Eine Selbstgehostete GitLab-Instanz?

GitLab wird mit vernünftigen Standardeinstellungen geliefert, die jedoch für einen offenen Community-Server und nicht für deine private Teaminstanz optimiert sind. Verbringe hier eine Stunde.

1. Deaktiviere Die Offene Anmeldung. Die offene Anmeldung ist standardmäßig aktiviert. Im Admin-Bereich navigiere zu Einstellungen > Allgemein > Anmeldebeschränkungen und deaktiviere das Kontrollkästchen „Anmeldung aktiviert“. Andernfalls kann jeder mit der URL ein Konto erstellen.
2. Aktiviere Die Zweifaktor-Authentifizierung. Gehe zu Admin-Bereich > Einstellungen > Allgemein > Anmeldebeschränkungen und erzwingen 2FA für alle Benutzer. Verkürze die Gnadenfrist von den standardmäßigen 48 Stunden auf 8 Stunden.
3. Beschränke Die Projekterstellung. Setze Standardprojekterstellung auf Maintainers oder Niemand, je nachdem, wie sehr du es einschränken möchtest.
4. Überprüfe Die SSL-Erneuerung. GitLab erneuert standardmäßig Let’s Encrypt-Zertifikate automatisch. Zur Bestätigung führe einmal `sudo gitlab-ctl renew-le-certs` aus und prüfe die Ausgabe.
5. Sperre SSH Auf Dem VPS Selbst Ab. Deaktiviere das Anmelden per Root-Passwort, erlaube nur die Authentifizierung per SSH-Schlüssel und (wenn möglich) verschiebe SSH von Port 22. Ein selbst gehosteter Git-Server ist nur so sicher wie die Box darunter.

Für eine ausführliche Version hat GitLab einen Hardening-Leitfaden veröffentlicht, der Authentifizierung, Verschlüsselung und Instanzeinstellungen abdeckt. Lies ihn einmal, wende an, was zu deinem Bedrohungsmodell passt, und mache weiter.

Wie Sicherst Und Stellst Du Eine Selbstgehostete GitLab-Instanz Wieder Her?

GitLab enthält ein integriertes Backup-Tool. Das erste Mal, wenn Du es benötigst, wirst Du froh sein, dass Du es eingerichtet hast.

Erstelle ein Backup:

sudo gitlab-backup create

Dies legt ein Tarball in `/var/opt/gitlab/backups` ab. Plane dies täglich über einen Cron Job mit einem Siebentage-Aufbewahrungsfenster. Führe sudo crontab -e aus und füge diese zwei Zeilen hinzu:

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

Der CRON=1-Flag unterdrückt die Fortschrittsausgabe, damit sie die Cron-Protokolle nicht mit Spam überflutet.

Profi-Tipp: Das Daten-Backup schließt nicht `/etc/gitlab/gitlab-secrets.json` oder `/etc/gitlab/gitlab.rb` ein.

Diese Dateien enthalten den Datenbank-Verschlüsselungsschlüssel, Zwei-Faktor-Seeds und CI/CD-Variablen. Die Konfigurationsgeheimnisse sind nicht Teil der regulären Sicherung und müssen separat gespeichert werden. Stelle Daten ohne die Geheimnisse-Datei wieder her, und Zwei-Faktor-Konten scheitern, verschlüsselte Variablen werden zu unleserlichem Datenmüll, und Du verbringst einen langen Abend damit herauszufinden, warum.

Füge dies demselben Cron Job hinzu:

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

Ein Backup kann nur auf derselben Version und Edition (CE-zu-CE, nicht CE-zu-EE) von GitLab wiederhergestellt werden, auf der es erstellt wurde.

Upgrade vorsichtig: stelle kein altes Backup auf einem frisch installierten GitLab wieder her, ohne zuvor die Installation herabzustufen, damit sie übereinstimmt.

Teste den Wiederherstellungsprozess mindestens einmal. Ein Backup, das Du nie getestet hast, ist nur eine Datei.

Lohnt Es Sich Eigentlich, GitLab Selbst Zu Hosten?

GitLab selbst zu hosten, ist eine Kontrollentscheidung für die meisten Teams. Die Kostenrechnung geht manchmal auf, aber der Grund, warum die Leute beim Selbsthosting bleiben, ist selten der Posten.

Hier sind die ehrlichen monatlichen Zeitkosten für eine Installation eines kleinen Teams:

• ~30 Minuten Patching – apt Upgrades, GitLab-Minor-Releases
• ~15 Minuten Backup-Überprüfung – vertraue keinem Backup, das Du nicht wiederhergestellt hast
• ~15 Minuten Kapazitätskontrolle – Festplattennutzung, RAM-Freiraum
• ~2x wenn CI/CD auf dem Server läuft – Ein beschäftigter Runner kann die Last verdoppeln

Das sind ungefähr eine Stunde pro Monat in einer ruhigen Woche oder zwei in einer beschäftigten Woche.

Bei etwa 150 $ pro Stunde belaufen sich 12 Stunden Betriebszeit auf etwa 1.800 $ — ungefähr fünf GitLab.com Premium-Sitze.

Eine Fallstudie von Mad Devs beschreibt, wie ihr Team mehr als 10.000 Dollar pro Jahr spart, indem es selbstgehostetes GitLab CE verwendet statt für Premium-Sitze zu bezahlen. Die Einsparungen machen sich erst bemerkbar, wenn das Team groß genug ist und die Lizenzgebühren für Sitze das Budget dominieren.

Das gesagt, Selbsthosting ist die falsche Wahl für:

• Zwei- bis Dreipersonen-Teams ohne Compliance-Gründe. GitLab.com Free deckt Dich ab. Die Betriebszeit ist höher als die eingesparten Kosten.
• Teams, bei denen niemand sich an der Kommandozeile wohl fühlt. „Wohl fühlen“ bedeutet nicht sysadmin-niveau. Es bedeutet, dass Du Fehler in `/var/log/gitlab` lesen kannst, ohne in Panik zu geraten.
• Teams, deren größtes Hindernis die Einstellung neuer Mitarbeiter ist, nicht die Werkzeuge. Selbsthosting lenkt von dem Produkt ab. Wenn die Produktgeschwindigkeit die Einschränkung ist, ist gehostet die richtige Wahl.

Wann macht es also Sinn, selbst zu hosten? Hier sind einige Szenarien:

• Regulierte Branchen mit expliziten Anforderungen an Datenresidenz oder Verantwortungsketten
• EU/UK-Teams mit Souveränitätsbedenken bezüglich in den USA gehostetem Code
• Teams mit 30+ Mitgliedern, bei denen Lizenzgebühren das Budget dominieren
• Kundenverträge, die die Nutzung von Drittanbieter-SaaS für Quellcode verbieten

Wenn dein Grund „GitHub berechnet pro Platz,“ ist, wirst du wahrscheinlich besser abschneiden. Wenn dein Grund „Ich möchte die Kontrolle haben,“ ist, könntest du die betriebliche Realität weniger romantisch finden, als erwartet.

Solltest Du GitLab CI/CD Runner Auf Demselben VPS Ausführen?

Zur Auswertung ja. Für die Produktion nein.

Ein CI-Runner auf demselben Server entzieht dem GitLab-UI Speicher und CPU. Das klassische Symptom ist „GitLab fühlt sich um 9 Uhr morgens langsam an“, was normalerweise darauf zurückzuführen ist, dass ein Build am Morgen die erste Pipeline startet und das Web-Frontend an Ressourcen verhungern lässt. Die sauberere Einrichtung ist ein separater kleiner VPS (oder eine DreamCompute-Instanz) für den Runner, der über das Netzwerk bei der GitLab-Instanz registriert ist.

Wenn Du die Runner auf demselben Server behalten musst, erhöhe den VPS auf 16 GB.

Laut den Systemanforderungen des GitLab-Runners ist der Runner-Prozess selbst leicht. Die Arbeitslasten, die er ausführt, sind es nicht, und sie teilen sich die CPU und die Festplatte des Rechners mit allem anderen, was GitLab macht.

Bereit Zum Wechseln?

Zurück zum Team-Chat am Freitagnachmittag.

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

Aber was, wenn es ernst wird, dass GitHub ausfällt?

Droht es vielleicht einem Kundenvertrag? Kommt es bei einer Compliance-Prüfung zur Sprache? Oder hat die Lizenzgebührenrechnung endlich die Grenze überschritten?

GitLab CE selbst zu hosten wird zu einer völlig vernünftigen Option. Alles, was Du brauchst, ist ein VPS, eine Domain, eine Omnibus-Installation und eine Stunde zur Absicherung.

Bis zum nächsten Mal, wenn die GitHub-Statusseite aufleuchtet, wird dein Code weiterhin problemlos funktionieren.

Häufig Gestellte Fragen Zum Selbst-Hosting Von GitLab

Möchtest Du noch etwas über das Selbst-Hosting von GitLab auf einem VPS wissen? Unten findest Du die Antworten auf einige häufig gestellte Fragen.

Ist GitLab CE kostenlos für Selbsthosting?

Ja, GitLab CE ist zur Selbsthostung unter einer Open-Source-Lizenz im MIT-Stil kostenlos. Es gibt keine Benutzerbegrenzung und keine Preisgestaltung pro Platz. Die einzigen Kosten sind der VPS selbst und die Betriebszeit für die Wartung.

DreamHosts VPS Stack 4 ist ein vernünftiger Ausgangspunkt zur Bewertung. Produktionsteams arbeiten typischerweise mit Stack 8 oder Stack 16.

Wie viel RAM benötigt GitLab CE tatsächlich?

Plane 16 GB RAM für bis zu 1.000 Benutzer ein, was die veröffentlichte Basislinie von GitLab ist (etwa 20 Anfragen pro Sekunde). Kleinere Teams können mit weniger auskommen, bis hin zu einer dokumentierten Untergrenze von 2 GB plus 1 GB Swap zur Bewertung. In jedem Fall, wenn Du CI/CD-Pipelines auf demselben Server ausführst, plane mit 16 GB.

Kann ich GitLab auf einem 4 GB VPS selbst hosten?

Ja, du kannst GitLab CE auf 4 GB betreiben, aber es wird sich unter jeder echten Belastung träge anfühlen. GitLab dokumentiert einen 2 GB + 1 GB Swap-Fallback für speicherbeschränkte Umgebungen — dieser Weg ist zur Bewertung, nicht für den Produktiveinsatz. Für ein Team, das aktiv Code pusht und Pipelines betreibt, sind 8 GB das praktische Minimum.

Wie lange dauert die Installation von GitLab CE auf einem VPS?

Etwa 10 bis 15 Minuten für die Paketinstallation, plus ungefähr eine Stunde für Vorbereitung und Absicherung, also insgesamt etwa 90 Minuten von Anfang bis Ende. Die Installation selbst besteht größtenteils aus Wartezeit beim Konfigurationsschritt.

Der Absicherungsdurchgang, der das Deaktivieren der offenen Anmeldung, das Erzwingen der Zwei-Faktor-Authentifizierung und das Einschränken der Projekterstellung erfordert, nimmt die verbleibende Stunde in Anspruch und ist für jede Produktionsinstanz obligatorisch.

Lohnt sich das Selbst-Hosting von GitLab für ein Fünf-Personen-Team?

Wahrscheinlich nicht, es sei denn, du hast einen Datenschutz- oder Compliance-Grund. GitLab.com Free deckt bis zu fünf Benutzer mit unbegrenzten privaten Projekten und 400 CI/CD-Minuten pro Monat ab. Die Betriebszeit des Selbsthostings wiegt schwerer als die eingesparten Kosten pro Platz bei dieser Teamgröße.

Selbst-Hosting fängt an, sich ab etwa 30+ aktiven Nutzern rein kostenmäßig zu lohnen.

Was ist der Unterschied zwischen GitLab CE und GitLab Community Edition?

GitLab CE und GitLab Community Edition sind dasselbe Produkt. CE ist die Standardabkürzung. Die Bezeichnung „Self-Managed“ bezieht sich darauf, wo Du es betreibst (Deine Infrastruktur), nicht auf die Edition.

GitLab Community Edition ist Open-Source. GitLab Enterprise Edition (EE) fügt kostenpflichtige Funktionen zur gleichen Codebasis hinzu.

Wo unterscheidet sich GitLab CE von GitLab EE?

GitLab CE ist die kostenlose, Open-Source-Edition. GitLab EE verwendet dieselbe Codebasis, zuzüglich kostenpflichtiger Funktionen, die aktiviert werden, wenn Du eine Lizenzdatei hochlädst.

Der praktische Unterschied besteht in Folgendem:

• CE ist MIT-lizenziert und voll funktionsfähig. Versionskontrolle, Zusammenführungsanforderungen, Probleme, einfaches CI/CD, Container-Registry, alles dabei.
• EE fügt hinter einer Lizenz Unternehmensfunktionen hinzu. Denke an Epics, erweiterte Compliance-Frameworks, Wertstromanalysen, mehrere Genehmigungsregeln und erweitertes Sicherheitsscannen. Gemäß GitLab’s Vergleich von Eigenverwaltungsfunktionen ist die Diskrepanz hauptsächlich für Organisationen mit formellen Änderungsmanagementprozessen relevant.
• Du kannst EE ohne Lizenz installieren, und es funktioniert als CE, bis es lizenziert wird. So sichern sich die meisten Teams gegen einen zukünftigen Bedarf zum Upgrade ab.
• Du kannst EE nicht sauber auf CE herabstufen. Plane entsprechend.

Für die meisten selbsthostenden Teams ist CE ausreichend. Wenn Dein Grund Privatsphäre oder Kosten sind, ändern EE-Funktionen selten die Rechnung.

Wie halte ich meine selbstgehostete GitLab-Instanz aktuell?

Führe `sudo apt update && sudo apt upgrade gitlab-ce` aus, um Sicherheitspatches anzuwenden. Ein monatlicher Rhythmus ist die praktische Untergrenze für eine Produktionsinstanz. Erstelle immer ein Backup, bevor du ein Upgrade durchführst.

Hauptversions-Upgrades müssen sequenziell durchgeführt werden — Du kannst keine Hauptversionen überspringen. Der Wechsel von 16.x zu 18.x erfordert zuerst ein Upgrade auf 17.x, dann auf 18.x. Das Überspringen einer Hauptversion wird die Datenbankmigrationen unterbrechen. Überprüfe immer das GitLab-Upgrade-Tool vor dem Upgrade und erstelle unmittelbar vor jedem Schritt ein Backup.

Wo passt DreamHost in selbstgehostetes GitLab?

DreamHosts VPS-Hosting bietet den Root-Zugriff Linux-Server, auf den GitLab CE installiert wird. Der Stack 16-Tarif (16 GB RAM) entspricht den offiziellen Anforderungen von GitLab für bis zu 1.000 Benutzer, mit Spielraum für aktive CI/CD-Pipelines.