GitLab CE selbst hosten: Mit KI zum eigenen Git-Server

Eine selbst betriebene GitLab-Instanz läuft auf deinem eigenen Server. Die Nutzergrenze für private Namespaces auf GitLab.com gilt für GitLab Self-Managed nicht (laut GitLab-Doku, Stand: 08.11.2026), und Compute-Kontingente sind dort standardmäßig deaktiviert (laut GitLab-Doku, Stand: 08.11.2026). Serverpreise findest du im GitLab-Kalkulator.

Der KI-Teil: Die Prompts helfen dir, Befehle für deinen Server vorzubereiten. Prüfe jede KI-Ausgabe gegen die GitLab-Doku, bevor du sie ausführst.

Dieser Guide zeigt dir die GitLab-CE-Installation mit Docker – inklusive copy-paste KI-Prompts für jeden Schritt.

Hardware-Anforderungen

GitLab ist ressourcenhungrig. Für eine Einzelinstanz nennt GitLab 8 vCPU und 16 GB RAM als Basis, in speicherbeschränkten Umgebungen 8 GB als Untergrenze; dazu Speicher von 40 GB für die Anwendung plus Platz für alle Repos und die Datenbank (laut GitLab-Doku, Stand: 08.11.2026).

Eine eigene Seite zum Sparbetrieb nennt 2 GB RAM plus 1 GB Swap für bis zu fünf Entwickler mit kleinen Repos (laut GitLab-Doku, Stand: 08.11.2026). Die Doku ist hier uneinheitlich; plane eher großzügig. Zum Vergleich: Gitea nennt 2 CPU-Kerne und 1 GB RAM als typischerweise ausreichend für kleine Teams (laut Gitea-Doku, Stand: 08.11.2026) und bringt ebenfalls CI/CD und eine Container-Registry mit (laut Gitea-Doku, Stand: 08.11.2026).

Tipp: GitLab rät von Burstable-Instanzen ab und empfiehlt, Swap möglichst zu deaktivieren und genug RAM vorzusehen (laut GitLab-Doku, Stand: 08.11.2026).

Schritt 1: Server vorbereiten

Hier kommt der erste KI-Prompt. Kopiere ihn, ersetze die Platzhalter, und lass dir ein Setup-Script vorschlagen:

Manuelle Basis-Vorbereitung

Falls du es selbst machen willst:

# System aktualisieren
apt update && apt upgrade -y

# Firewall konfigurieren
ufw allow 22/tcp    # SSH
ufw allow 80/tcp    # HTTP
ufw allow 443/tcp   # HTTPS
ufw allow 2222/tcp  # Git über SSH (Container)
ufw enable

Docker installierst du aus dem offiziellen apt-Repository (docker-ce, docker-compose-plugin), wie es die Docker-Doku beschreibt; das Convenience-Skript empfiehlt Docker nicht für Produktivsysteme (laut Docker-Doku, Stand: 08.11.2026).

Achtung: Ports, die Docker veröffentlicht, umgehen ufw (laut Docker-Doku, Stand: 08.11.2026). Veröffentliche nur 80, 443 und 2222 oder nutze zusätzlich die Firewall deines Hosters.

Schritt 2: GitLab mit Docker Compose

Erstelle Verzeichnis und Konfiguration:

mkdir -p /opt/gitlab && cd /opt/gitlab
nano docker-compose.yml

Docker Compose Konfiguration:

services:
  gitlab:
    image: gitlab/gitlab-ce:<version>-ce.0
    container_name: gitlab
    restart: always
    hostname: 'gitlab.deine-domain.de'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.deine-domain.de'
        gitlab_rails['gitlab_shell_ssh_port'] = 2222
    ports:
      - '80:80'
      - '443:443'
      - '2222:22'
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
    shm_size: '256m'

volumes:
  gitlab_config:
  gitlab_logs:
  gitlab_data:

Für Produktion pinnst du das Image auf eine feste Version statt latest (laut GitLab-Doku, Stand: 08.11.2026). Eine Zeile version: brauchst du nicht mehr, die Angabe ist obsolet (laut Docker-Doku, Stand: 08.11.2026).

Starten:

docker compose up -d

Hinweis: Der erste Start kann eine Weile dauern. Den Fortschritt siehst du mit docker logs -f gitlab (laut GitLab-Doku, Stand: 08.11.2026).

Wenig RAM

Für speicherbeschränkte Umgebungen nennt die GitLab-Doku u. a. puma['worker_processes'] = 0, sidekiq['concurrency'] = 10 und prometheus_monitoring['enable'] = false (laut GitLab-Doku, Stand: 08.11.2026). Der Puma-Single-Mode hat Einschränkungen, etwa keine Phased Restarts (laut GitLab-Doku, Stand: 08.11.2026).

Schritt 3: Erstes Login

Nach dem Start das initiale Root-Passwort auslesen:

docker exec -it gitlab grep 'Password:' /etc/gitlab/initial_root_password

Dann im Browser: https://gitlab.deine-domain.de

• Username: root
• Password: Aus dem obigen Befehl

Wichtig: Die Passwortdatei wird beim ersten Container-Neustart nach 24 Stunden automatisch gelöscht (laut GitLab-Doku, Stand: 08.11.2026). Ändere das Passwort sofort in deinen Benutzereinstellungen.

Troubleshooting mit KI

GitLab-Fehler können kryptisch sein. Dieser Prompt hilft bei der Einordnung:

Datenschutz: Entferne vor dem Einfügen Passwörter, Tokens sowie E-Mail- und IP-Adressen aus den Logs.

Häufige Probleme

Container startet nicht (OOM):

# RAM-Verbrauch prüfen
docker stats gitlab

Plane mehr RAM ein (Kalkulator unter /use-case/gitlab). Swap ist nur ein Notbehelf und kann die Leistung deutlich senken (laut GitLab-Doku, Stand: 08.11.2026).

502 Bad Gateway: GitLab braucht Zeit zum Starten. Verfolge docker logs -f gitlab oder prüfe:

docker exec -it gitlab gitlab-ctl status

SSL-Zertifikat funktioniert nicht: Let's Encrypt braucht erreichbare Ports 80/443. Firewall prüfen!

CI/CD Pipeline Basics

Auf GitLab Self-Managed sind Compute-Kontingente standardmäßig deaktiviert; die Grenze setzt die Leistung deiner Runner (laut GitLab-Doku, Stand: 08.11.2026).

GitLab Runner installieren

Der Runner führt deine Pipelines aus. GitLab empfiehlt, den Runner auf einer eigenen Maschine zu betreiben (laut GitLab-Doku, Stand: 08.11.2026). Für den Einstieg kann er im selben Compose-Projekt laufen:

# Zu docker-compose.yml unter services hinzufügen
  gitlab-runner:
    image: gitlab/gitlab-runner:<version>
    container_name: gitlab-runner
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - gitlab_runner_config:/etc/gitlab-runner

# und im Top-Level-Block volumes ergänzen:
#   gitlab_runner_config:

Achtung: Der eingebundene Docker-Socket hebelt die Container-Isolation aus; eine Rechteausweitung auf den Host ist möglich (laut GitLab-Doku, Stand: 08.11.2026).

Runner registrieren: Lege den Runner zuerst in der GitLab-Oberfläche an (das Token beginnt mit glrt-) und registriere ihn dann (laut GitLab-Doku, Stand: 08.11.2026):

docker exec -it gitlab-runner gitlab-runner register --url https://gitlab.deine-domain.de --token <glrt-Token>

Erste Pipeline erstellen

Lass dir eine Pipeline von der KI vorschlagen:

Beispiel für ein Node.js Projekt:

stages:
  - build
  - check
  - deploy

default:
  image: node:24
  cache:
    key: npm
    paths:
      - .npm/

build:
  stage: build
  script:
    - npm ci --cache .npm
    - npm run build

check:
  stage: check
  script:
    - npm ci --cache .npm
    - npm run lint

deploy:
  stage: deploy
  image: alpine
  before_script:
    - apk add openssh-client
    - eval $(ssh-agent -s)
    - chmod 400 "$SSH_PRIVATE_KEY"
    - ssh-add "$SSH_PRIVATE_KEY"
    - mkdir -p ~/.ssh && chmod 700 ~/.ssh
    - cp "$SSH_KNOWN_HOSTS" ~/.ssh/known_hosts
  script:
    - ssh user@server "cd /app && git pull && docker compose up -d --build"
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Jeder Job führt npm ci selbst aus, denn der Cache ist eine Optimierung ohne Zusicherung (laut GitLab-Doku, Stand: 08.11.2026). Node.js 24 ist eine LTS-Linie (laut nodejs.org, Stand: 08.11.2026). Statt only nutzt du rules (laut GitLab-Doku, Stand: 08.11.2026). Für den Deploy-Job hinterlegst du den Schlüssel als File-Variable SSH_PRIVATE_KEY mit ssh-agent und die Host-Keys als SSH_KNOWN_HOSTS (laut GitLab-Doku, Stand: 08.11.2026).

Backup einrichten

Manuelles Backup:

docker exec -t gitlab gitlab-backup create

Backup-Dateien liegen in /var/opt/gitlab/backups/ (im Container). Konfigurationsdateien sind nicht im Backup: Sichere /etc/gitlab/gitlab-secrets.json und gitlab.rb (im Volume gitlab_config) getrennt vom Anwendungs-Backup an einem sicheren Ort außerhalb des Servers (laut GitLab-Doku, Stand: 08.11.2026).

GitLab.com vs Self-Hosted

Stand der Tabelle: 08.11.2026, Quellen im Absatz darunter.

Die Nutzergrenze beschreibt die GitLab-Doku (laut GitLab-Doku, Stand: 08.11.2026), die Compute-Minuten ebenso (laut GitLab-Doku, Stand: 08.11.2026). Ab dem sechsten Nutzer in einem privaten Namespace greift auf GitLab.com die Nutzergrenze der Einstiegsstufe. Für den Umzug von GitHub gibt es einen eingebauten Importer; auf Self-Managed muss ein Admin die Importquelle aktivieren (laut GitLab-Doku, Stand: 08.11.2026).

Datenschutz: Daten auf deinem Server, Standort wählbar; wer Daten anderer verarbeitet, bleibt für die DSGVO-Einhaltung verantwortlich, in der Regel mit AV-Vertrag mit dem Hoster.

Container & Package Registry nutzen

GitLab bringt eine Container Registry und eine Package Registry mit (laut GitLab-Doku, Stand: 08.11.2026). Statt Docker Hub oder einen separaten Artifact-Server zu betreiben, schiebst du Images direkt in GitLab.

Die Registry aktivierst du über registry_external_url. Zwei Varianten: Mit der eingebauten Let's-Encrypt-Integration läuft sie auf Port 5050 der GitLab-Domain, den du im Docker-Setup veröffentlichst; oder sie bekommt eine eigene Subdomain mit gültigem Zertifikat (laut GitLab-Doku, Stand: 08.11.2026). Beispiel mit eigener Subdomain:

docker login registry.deine-domain.de
docker build -t registry.deine-domain.de/team/projekt:latest .
docker push registry.deine-domain.de/team/projekt:latest

Die Package Registry unterstützt u. a. npm, Maven, PyPI und Composer (laut GitLab-Doku, Stand: 08.11.2026) – praktisch, wenn dein Team interne Bibliotheken teilt, ohne sie öffentlich zu publizieren.

GitLab absichern

Ein selbst gehosteter GitLab-Server ist ein attraktives Ziel, weil er deinen gesamten Quellcode enthält. Die wichtigsten Maßnahmen:

• HTTPS erzwingen: Setze external_url auf https:// und nutze die eingebaute Let's-Encrypt-Integration (siehe Registry-Abschnitt) oder einen Reverse Proxy.
• 2FA für alle erzwingen: Unter Admin → Settings → General → Sign-in restrictions → Enforce two-factor authentication (laut GitLab-Doku, Stand: 08.11.2026).
• Registrierung deaktivieren: Die Registrierung ist standardmäßig an; schalte unter Admin → Settings → General → New user account restrictions „Allow new user accounts“ aus (laut GitLab-Doku, Stand: 08.11.2026). Lade Nutzer stattdessen gezielt ein.
• SSH-Keys statt Passwörter: Für Git-Operationen und den Serverzugang.
• Regelmäßige Updates: GitLab veröffentlicht zweimal im Monat Patch-Releases (laut GitLab-Doku, Stand: 08.11.2026). Vor jedem Update Backup inkl. /etc/gitlab anlegen, den Image-Tag auf die nächste Version gemäß Upgrade-Pfad setzen (laut GitLab-Doku, Stand: 08.11.2026), dann docker compose pull && docker compose up -d.
• Rate Limits: Prüfe die eingebauten Rate Limits im Admin-Bereich (laut GitLab-Doku, Stand: 08.11.2026); Fail2Ban kann ergänzend eingesetzt werden.

Fazit

Du hast jetzt einen eigenen GitLab-Server:

• ohne die Nutzergrenze der GitLab.com-Einstiegsstufe
• mit standardmäßig deaktivierten Compute-Kontingenten
• mit Daten auf deinem Server, Standort wählbar

Der KI-Workflow: Die Prompts helfen beim Einordnen von Fehlermeldungen; die GitLab-Doku ersetzen sie nicht.

Kosten: Aktuelle Serverpreise für GitLab findest du im GitLab-Kalkulator und im VPS-Vergleich.

Weitere Self-Hosting Guides

n8n Self-Hosting Guide

Docker Setup Schritt für Schritt

Lesen

VPS Vergleich 2026

Anbieter und Tarife im Überblick

Lesen