Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Self-hosted Git ist mehr als Repository-Hosting. Web UI, Git über SSH/HTTP, Actions/CI Runner, Registry, Backup und Rechte müssen gemeinsam geplant werden. Build-Last auf demselben Host kann Performance- und Sicherheitsrisiken erzeugen.
Gitea wird meist als schlankere Git-Plattform gewählt, GitLab bietet breitere integrierte DevOps-Funktionen. Auswahl nach Teamgröße, CI/CD, Registry und Betrieb; Runner möglichst separat dimensionieren.
Repository-Server liefert Git und Web UI, Runner führen CPU-/RAM-/Disk-intensive Builds aus. Separate Runner-Nodes schaffen Isolation.
Es gibt keinen universellen Sieger. Betriebsaufwand und benötigte integrierte Funktionen entscheiden.
GitLab Docker Executor kann docker.sock nutzen; Runner daher auf vertrauenswürdige Projekte begrenzen und möglichst vom Repository-Host trennen.
Service-Status, Disk und Listening Ports regelmäßig überwachen.
Türkei (Türkisch)
Germany (German)
Worldwide (English)
df -hfree -hss -lntpsystemctl --faileddocker ps --format 'table {{.Names}}\t{{.Status}}' 2>/dev/null || trueIssues, Wiki, LFS, Registry, CI-Secrets, Nutzer und Plattform-DB sind nicht in Developer-Clones vollständig enthalten. Plattform-native Backups erforderlich.
Für containerisierte Jobs ja; direkte Host-Ausführung ist ebenfalls möglich.
Möglich, aber separater Runner-Node ist für Isolation und Sicherheit meist sauberer.
Ja, besonders für schlankes Self-Hosted Git mit Actions.
Teilen Sie Teamgröße, Repo-Volumen, tägliche Pipelines und Registry-Bedarf; Gitea/GitLab + Runner planen.