GitLab Self-Managed needs more planning than a normal web app. GitLab’s current installation requirements use 8 vCPU as the single-node baseline and recommend SSD-backed storage, particularly because Gitaly repository storage is I/O intensive. Larger deployments should use GitLab’s sizing guidance rather than a one-size-fits-all plan.
For a small engineering team, a larger VPS can be a reasonable single-node starting point. For heavy CI, large repositories, many users or strong availability requirements, separate runners and eventually dedicated/distributed infrastructure become more appropriate.
What runs inside a self-managed GitLab deployment?
A GitLab node is not just a web server. A typical installation includes the GitLab application, PostgreSQL, repository storage (Gitaly), Redis and background jobs. CI runners are separate execution workers and can create much heavier CPU/storage load than interactive Git usage.
CPU: start from GitLab’s baseline, then add workload evidence
GitLab’s current single-node requirements list 8 vCPU as the baseline. That does not mean 8 vCPU is enough for every organisation. Repository operations, background jobs, project count and concurrent users change demand.
Do not run large CI jobs on the same machine merely because the GitLab web UI is responsive. Compilation, Docker builds and tests can saturate CPU and storage and make Git operations slow.
RAM planning
Memory is shared across the Rails application, PostgreSQL, Redis, repository services and background jobs. Leave operating-system headroom rather than sizing exactly to the sum of nominal service allocations.
Monitor peak resident memory, swap and PostgreSQL cache behaviour during normal workdays and CI peaks.
Storage: SSD/NVMe matters for GitLab
GitLab explicitly recommends SSD-backed storage and warns that Gitaly is I/O intensive. Repositories are made of many objects and metadata operations; CI artifacts, container images, packages and logs can also grow quickly.
Plan storage as separate categories:
- Git repositories;
- database;
- CI artifacts/caches;
- container registry/packages;
- uploads;
- backups.
Retention policies for artifacts and registry images are as important as the initial disk size.
Do not put CI runners on the GitLab application node by default
CI runners execute untrusted or variable project workloads. Isolating them on separate VPS or dedicated workers prevents one build from starving the GitLab control plane.
Use smaller runner nodes for light jobs and larger/high-frequency or many-core workers for compilers, containers and parallel test suites. Runner capacity can scale independently from the GitLab server.
Network and clone performance
Git clone/fetch/push operations move repository data, while CI can move artifacts and images. Monitor monthly transfer and peak throughput. A faster port helps large bursts only when storage and upstream routing can keep up.
PostgreSQL and high availability
GitLab supports its bundled PostgreSQL or an external supported PostgreSQL service. For distributed deployments, GitLab documents component-specific requirements. Its HA guidance requires low latency between nodes for synchronous replication and recommends using availability zones appropriately.
Do not stretch one synchronous GitLab deployment across distant Indian cities. Use GitLab Geo for genuinely multi-region designs rather than creating a high-latency database cluster.
Backups
GitLab backups must cover more than the database. Repository data, uploads, registry/artifacts and configuration/secrets need a documented recovery process. Keep copies off the production node and test restoration.
VPS or dedicated server?
| Workload | Likely direction |
|---|---|
| Small team, modest repos, external runners | Larger VPS can be practical |
| Many developers / large repos | High-memory VPS or dedicated |
| Heavy local CI runners | Separate runner nodes |
| Sustained repository I/O / large storage | Dedicated/storage-focused design |
| HA / distributed deployment | Multi-node architecture using GitLab guidance |
StreamData sizing path
StreamData’s VPS catalogue scales to 128 GB RAM, while dedicated inventory is available for workloads that need stronger isolation and sustained CPU/storage behaviour. A GitLab environment can start virtual and move repository/application components to bare metal as load grows.
GitLab hosting checklist
- Count active users and repository size/growth.
- Use GitLab’s current version-specific requirements.
- Use SSD/NVMe-backed storage.
- Separate CI runners from the control plane when builds are heavy.
- Set artifact/registry retention.
- Monitor CPU, RAM, I/O and transfer.
- Keep off-server backups.
- Test upgrade and restore procedures.
Bottom line
Self-managed GitLab should be sized as a developer platform, not a single website. Start from GitLab’s current baseline, give repository storage fast SSD/NVMe, isolate heavy runners and move to dedicated/distributed architecture when sustained load or availability requirements justify it.
Next step: compare StreamData VPS and dedicated servers using your user count, repository size, runner concurrency and storage growth.
Frequently asked questions about GitLab hosting
Can GitLab run on a small 2 GB VPS?
That may be useful only for experiments or very constrained environments; it is not aligned with GitLab’s current single-node production baseline. GitLab is a multi-component application, so production sizing should use the current GitLab requirements and actual user/repository/CI load.
Should GitLab Runner live on the same server?
For light jobs it can, but separating runners is safer when builds are CPU-, memory- or I/O-heavy. The GitLab application should remain responsive even when a project launches an expensive build.