GitLab bietet drei fundamentale Deployment-Optionen, jede mit unterschiedlichen Trade-offs zwischen Kontrolle, Convenience und Kosten. Die Wahl ist nicht nur technisch, sondern auch organisatorisch und strategisch – sie beeinflusst, wie das Team arbeitet, welche Features verfügbar sind, und wie viel Overhead das DevOps-Team hat.
Dieses Kapitel analysiert die drei Optionen technisch und praktisch, gibt Entscheidungshilfen anhand konkreter Szenarien, und erklärt, was bei Migration zwischen Modi zu beachten ist.
GitLab-managed, Multi-Tenant, Cloud-hosted
GitLab.com ist die vollständig von GitLab Inc. gehostete und verwaltete SaaS-Plattform. Nutzer registrieren sich, erstellen Projekte, und nutzen die Plattform ohne jegliche Installation oder Infrastruktur-Management.
Architektur: Multi-Tenant – tausende Organisationen teilen sich dieselbe GitLab-Infrastruktur (aber mit strikter Datenisolation).
URL:
https://gitlab.com/your-namespace/your-project
Runner: - Shared Runners: Von GitLab bereitgestellt, kostenlos (mit Limits) oder kostenpflichtig - Specific Runners: Eigene Runner können registriert werden
Datenlocation: GitLab-Datacenter (primär USA, aber global verteilt)
Self-hosted, Single-Tenant, volle Kontrolle
GitLab wird auf eigener Infrastruktur installiert – eigene Server, eigenes Datacenter, oder eigene Cloud-Instanzen (AWS, Azure, GCP).
Architektur: Single-Tenant – jede Organisation hat eigene GitLab-Instanz.
URL: https://gitlab.your-company.com/
(eigene Domain)
Runner: Vollständig selbst verwaltet, unbegrenzte Kapazität (nur durch Hardware limitiert)
Datenlocation: Wo auch immer die Instanz deployed ist (on-premise, AWS eu-central-1, etc.)
GitLab-managed, Single-Tenant, isolierte Infrastruktur
GitLab Dedicated ist ein Hybrid-Modell: GitLab managed die Instanz, aber sie läuft in isolierter Infrastruktur (nicht multi-tenant wie GitLab.com). Jede Organisation hat eigene dedizierte GitLab-Server.
Architektur: Single-Tenant, aber GitLab-operated.
URL:
https://your-company.gitlab-dedicated.com/
Runner: Eigene Runner (wie Self-Managed), aber mit Option für GitLab-managed Runner
Datenlocation: Wählbar (z.B. “EU only”, “US only”)
Verfügbarkeit: Nur für Enterprise-Kunden (Ultimate Tier)
| Aspekt | GitLab.com (SaaS) | Self-Managed | GitLab Dedicated |
|---|---|---|---|
| Installation | Keine | Komplex (Omnibus/K8s/Docker) | Keine |
| Upgrades | Automatisch | Manuell (monatlich empfohlen) | Automatisch |
| Maintenance | GitLab | Eigenes Team | GitLab |
| Backups | GitLab | Eigene Verantwortung | GitLab |
| Monitoring | GitLab | Eigenes Setup (Prometheus) | GitLab |
| SSL/TLS | GitLab (Let’s Encrypt) | Eigene Zertifikate | GitLab |
| Datenisolation | Multi-Tenant (isoliert) | Single-Tenant | Single-Tenant |
| Compliance | GitLab-Compliance | Eigene Kontrolle | Hybride Kontrolle |
| Anpassbarkeit | Begrenzt | Vollständig | Mittel |
| API Rate Limits | Ja (10 req/s/user) | Keine (konfigurierbar) | Konfigurierbar |
| Aspekt | GitLab.com | Self-Managed | GitLab Dedicated |
|---|---|---|---|
| Shared Runners | Ja (GitLab-hosted) | Nein | Optional |
| Runner-Limits | 400 Minuten/Monat (Free) | Unbegrenzt | Unbegrenzt |
| Runner-Control | Begrenzt | Vollständig | Vollständig |
| Executor-Types | Docker (Linux, Windows) | Alle (Shell, Docker, K8s, etc.) | Alle |
| Pipeline-Caching | Shared S3 (begrenzt) | Eigenes Storage | Eigenes Storage |
| Artifact-Storage | GitLab-managed (Limits) | Unbegrenzt (eigenes Storage) | Unbegrenzt |
| Container Registry | Ja (5 GB Free) | Ja (unbegrenzt) | Ja (unbegrenzt) |
| Concurrent Jobs | Runner-abhängig | Hardware-abhängig | Hardware-abhängig |
| Kostenfaktor | GitLab.com | Self-Managed | GitLab Dedicated |
|---|---|---|---|
| Lizenz | $0-$99/user/Jahr | $0-$99/user/Jahr | ~$150-200/user/Jahr |
| Infrastruktur | $0 | $$$ (Server, Storage, Network) | $0 |
| Personal | Minimal | $$$ (DevOps Team) | Minimal |
| Runner | Free (Limits) oder $10/job-minute | Server-Kosten | Server-Kosten |
| Support | Standard | Standard (+ eigenes Team) | Premium |
| Skalierung | Automatisch, nutzungsbasiert | Capex (Hardware kaufen) | Verhandelbar |
GitLab.com: Alle Features verfügbar (Tier-abhängig: Free, Premium, Ultimate)
Self-Managed: Alle Features verfügbar (Tier-abhängig), plus: - Advanced LDAP/SAML-Konfiguration - Custom Integrations - Compliance-Features (Audit Events on-premise) - Geo-Replication (Ultimate)
GitLab Dedicated: Wie Self-Managed, aber mit GitLab-Management
1. Omnibus Package (Empfohlen)
Single-Package Installation, alle Komponenten inkludiert:
# Ubuntu/Debian
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
sudo apt-get install gitlab-ee
# CentOS/RHEL
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash
sudo yum install gitlab-ee
# Konfiguration
sudo gitlab-ctl reconfigureVorteil: Einfach, integriert, gut dokumentiert Nachteil: Weniger flexibel, monolithisch
2. Docker
GitLab als Docker-Container:
docker run --detach \
--hostname gitlab.example.com \
--publish 443:443 --publish 80:80 --publish 22:22 \
--name gitlab \
--restart always \
--volume $GITLAB_HOME/config:/etc/gitlab \
--volume $GITLAB_HOME/logs:/var/log/gitlab \
--volume $GITLAB_HOME/data:/var/opt/gitlab \
gitlab/gitlab-ee:latestVorteil: Container-basiert, einfach zu updaten Nachteil: Volumes-Management, Backup-Komplexität
3. Kubernetes (Helm Charts)
Cloud-native Deployment:
helm repo add gitlab https://charts.gitlab.io/
helm install gitlab gitlab/gitlab \
--set global.hosts.domain=example.com \
--set certmanager-issuer.email=admin@example.comVorteil: Hochskalierbar, Cloud-native, HA out-of-the-box Nachteil: Kubernetes-Expertise nötig, komplex
4. Source Installation
Manuelle Installation aus Source-Code:
Vorteil: Maximale Kontrolle, custom Patches möglich Nachteil: Sehr komplex, nicht empfohlen
Minimum (< 100 User): - 4 CPU cores - 8 GB RAM - 50 GB Storage
Recommended (100-500 User): - 8 CPU cores - 16 GB RAM - 200 GB Storage (+ separate Storage für Repositories)
Enterprise (500-1000 User): - Multi-Node Setup (siehe Architektur-Kapitel) - Load Balancer - Dedicated PostgreSQL, Redis, Gitaly - Object Storage (S3/Azure/GCS) für Artifacts
# Backup erstellen
gitlab-backup create
# Backup-Location (default)
/var/opt/gitlab/backups/
# Backup umfasst:
# - Database (PostgreSQL)
# - Repositories (Gitaly)
# - Uploads, LFS, CI Artifacts, Registry
# - Configuration (separates Backup nötig!)
# Configuration-Backup
tar -czf gitlab-config-$(date +%Y%m%d).tar.gz /etc/gitlab
# Automated Backups (Cron)
0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1Retention: gitlab.rb konfiguriert
Auto-Deletion alter Backups:
gitlab_rails['backup_keep_time'] = 604800 # 7 TageOffsite-Storage: Backups auf S3/Azure/GCS pushen:
gitlab_rails['backup_upload_connection'] = {
'provider' => 'AWS',
'region' => 'eu-central-1',
'aws_access_key_id' => 'AKIAKIAKI',
'aws_secret_access_key' => 'secret'
}
gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups'GitLab exportiert Prometheus-Metriken:
# Prometheus scrape config
scrape_configs:
- job_name: 'gitlab'
metrics_path: '/-/metrics'
static_configs:
- targets: ['gitlab.example.com']Key Metrics: -
gitlab_transaction_duration_seconds: Request Latency -
sidekiq_jobs_processed_total: Job-Throughput -
gitaly_service_client_requests_total: Git-Operations -
gitlab_database_connection_pool_size: DB-Connections
Alerting: Prometheus Alertmanager für kritische Events (DB-Down, Disk-Full, etc.)
GitLab.com bietet Shared Runners kostenlos (mit Limits):
Free Tier: - 400 CI/CD Minuten pro Monat (über alle Projekte) - Linux Runner (Docker Executor) - Shared Infrastructure (kann langsamer sein bei hoher Last)
Premium/Ultimate: - 10,000 CI/CD Minuten pro Monat - + $10 per 1,000 zusätzliche Minuten - Dedizierte Runner-Kapazität (schneller)
Eigene Runner: Können jederzeit registriert werden (unbegrenzte Kapazität)
Repository Size: 10 GB (Free), Soft-Limit (kann erhöht werden auf Anfrage)
Artifacts: 1 GB pro Projekt (Default), Retention 30 Tage
Container Registry: 5 GB (Free), mehr kostenpflichtig
LFS: 10 GB (Free)
API: - Authenticated: 2,000 req/min - Unauthenticated: 10 req/min
Git Operations: - 600 req/min per user
Webhook: 1,000 deliveries/day per Hook
Empfehlung: GitLab.com (Free oder Premium)
Begründung: - Kein Overhead für Infrastruktur-Management - Team kann sich auf Produktentwicklung fokussieren - 400 CI/CD Minuten oft ausreichend (oder eigene Runner registrieren) - Kosteneffizient ($0-$19/user/Monat)
Trade-off: Begrenzte Anpassbarkeit, aber irrelevant bei Standard-Workflows
Empfehlung: GitLab.com (Premium) oder Self-Managed (wenn DevOps-Team vorhanden)
Begründung: - GitLab.com noch manageable, 10,000 CI/CD Minuten + eigene Runner - Self-Managed wenn: spezifische Compliance-Anforderungen, viel CI/CD (tausende Jobs/Tag), custom Integrations
Entscheidungsfaktor: Haben wir dediziertes DevOps-Team für Self-Managed-Maintenance?
Empfehlung: Self-Managed (Ultimate) oder GitLab Dedicated
Begründung: - Volle Kontrolle über Infrastruktur, unbegrenzte CI/CD-Kapazität - Compliance (GDPR, HIPAA, SOC2) – Daten bleiben on-premise - High-Availability, Geo-Replication (für global verteilte Teams) - TCO oft günstiger bei dieser Größe (keine per-Minute CI/CD-Kosten)
Self-Managed vs. Dedicated: Dedicated wenn GitLab-Management bevorzugt, aber Single-Tenant nötig
Empfehlung: Self-Managed (On-Premise)
Begründung: - Regulatorische Anforderungen: Daten dürfen Cloud nicht verlassen - Air-Gapped Environments möglich - Full Audit-Trail, eigene Security-Policies - Compliance-Zertifizierungen einfacher (eigene Kontrolle)
Dedicated: Wenn Daten in Cloud OK, aber Multi-Tenant nicht akzeptabel
Empfehlung: GitLab.com (Free)
Begründung: - Kostenlos für Public Repositories - Unbegrenzte Collaborators - Community-Sichtbarkeit - Shared Runners ausreichend für OSS-Projekte
| Kostenfaktor | Jährliche Kosten |
|---|---|
| Lizenz (100 User × $29/Monat) | $34,800 |
| CI/CD Minuten (angenommen 50,000 zusätzlich) | $6,000 |
| Storage (angenommen 100 GB extra) | $1,200 |
| Total | ~$42,000/Jahr |
Keine Infrastruktur- oder Personal-Kosten.
| Kostenfaktor | Jährliche Kosten |
|---|---|
| Lizenz (100 User × $19/Monat) | $22,800 |
| Infrastruktur (Server, Storage, Network) | $15,000-30,000 |
| DevOps Personal (0.5 FTE × $100k) | $50,000 |
| Total | ~$87,800-102,800/Jahr |
Höher, aber unbegrenzte CI/CD, volle Kontrolle.
Bei ~150-200 Usern oder sehr intensiver CI/CD-Nutzung (tausende Job-Stunden/Monat) wird Self-Managed TCO-effizienter.
Wichtig: TCO ist nicht nur $$$. Auch: Kontrolle, Compliance, Vendor-Lock-in, Flexibility.
Prozess: 1. Self-Managed-Instanz aufsetzen 2. Export
von GitLab.com:
bash # Via UI: Settings → General → Export Project # Oder: API curl --header "PRIVATE-TOKEN: $TOKEN" \ "https://gitlab.com/api/v4/projects/:id/export" \ --request POST
3. Import in Self-Managed:
bash # Via UI: New Project → Import Project → GitLab Export
Was wird migriert: - Repository (Git-Historie) -
Issues, Merge Requests - Wiki, Snippets - CI/CD Configuration
(.gitlab-ci.yml)
Was NICHT migriert wird: - CI/CD Job-Historie (Logs, Artifacts) - Runner-Registrations (müssen neu registriert werden) - User-Accounts (müssen neu erstellt oder LDAP/SAML-Sync)
Downtime: Minimal (nur während Export/Import, Entwicklung kann weiter auf GitLab.com)
Selber Prozess, umgekehrte Richtung. Beachte GitLab.com Storage-Limits.
GitLab Inc. managed Migration, weniger Self-Service.
Für global verteilte Teams: GitLab Geo (Ultimate-Feature)
Architektur: - Primary Site: Schreibbar (z.B. USA) - Secondary Sites: Read-only Replicas (z.B. EU, APAC)
Vorteile: - Entwickler clonen von nächstem Geo-Node (schneller) - Disaster Recovery (Failover zu Secondary bei Primary-Ausfall) - Compliance (Daten-Replikation in spezifische Regionen)
Kosten: Ultimate Tier, höhere Infrastruktur-Kosten (multiple Regions)
Die Deployment-Entscheidung ist kontextabhängig:
GitLab.com (SaaS): ✓ Schneller Start, kein Maintenance ✓ Kosteneffizient für kleine bis mittlere Teams ✓ Automatische Updates, High-Availability ✗ Begrenzte Anpassbarkeit ✗ Multi-Tenant, Daten bei GitLab Inc. ✗ CI/CD-Limits (oder kostenpflichtige Minuten)
Self-Managed: ✓ Volle Kontrolle, unbegrenzte CI/CD ✓ Compliance, Datensouveränität ✓ Vollständige Anpassbarkeit ✗ Hoher Maintenance-Aufwand ✗ Infrastruktur- und Personal-Kosten ✗ Eigene Verantwortung für Backups, Security, HA
GitLab Dedicated: ✓ GitLab-managed, aber Single-Tenant ✓ Compliance ohne Self-Management ✓ Wählbare Data-Location ✗ Nur Enterprise (teuer) ✗ Weniger Kontrolle als Self-Managed
Empfehlung: - Start klein: GitLab.com Free/Premium - Wachse iterativ: Evaluiere Self-Managed wenn Limits erreicht oder Compliance nötig - Enterprise: Self-Managed oder Dedicated, basierend auf DevOps-Kapazität
Die Migration ist möglich, aber nicht trivial. Es ist einfacher, früh die richtige Wahl zu treffen basierend auf Projektions der Teamgröße, CI/CD-Intensity, und Compliance-Anforderungen.
Am Ende: Die beste GitLab-Variante ist die, die das Team produktiv macht ohne Overhead. Ob das SaaS-Convenience, Self-Managed-Control, oder Dedicated-Hybrid ist, hängt von Organisation, Anforderungen, und Ressourcen ab.