Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
Self-hosted Git is more than repository hosting. Web UI, Git over SSH/HTTP, Actions or CI runners, container registry, backups and user permissions should be planned together. Build workloads competing with the repository service on the same host can create performance and security risk.
Gitea is generally chosen as a leaner self-hosted Git platform, while GitLab provides a broader integrated DevOps surface. Choose based on team size, CI/CD, registry and operational needs. Runner capacity should ideally be sized separately.
The repository server handles Git operations and web UI, while runners execute CPU-, memory- and disk-heavy builds/tests. Moving runners to separate nodes provides isolation.
There is no universal winner. Operational complexity and required integrated features should drive the decision.
GitLab's Docker executor can use docker.sock access, so runners should be limited to trusted projects and preferably isolated from the repository host.
Monitor service state, disk usage and listening ports regularly.
Turkey (Turkish)
Germany (German)
Worldwide (English)
df -hfree -hss -lntpsystemctl --faileddocker ps --format 'table {{.Names}}\t{{.Status}}' 2>/dev/null || trueIssues, wikis, LFS, registry, CI secrets, users and platform databases are not preserved by developer clones. Use platform-native backup and restore procedures.
Gitea docs state Docker is required for containerized jobs, while jobs can also run directly on the host.
They can, but a separate runner node is usually cleaner for build isolation and security.
It is a strong option for small/mid teams needing lightweight self-hosted Git and Actions.
Share team size, repository volume, daily pipelines and registry needs; we can plan Gitea/GitLab and runner topology.