GitLab combines web requests, background jobs and a transactional database. Persistent swap, OOM events or slow Sidekiq queues indicate that a constrained setup needs more memory.
Teams moving beyond a tiny lab or adding more users and automation.GitLab 하드웨어 요구 사항: RAM, CPU, 스토리지 및 리포지터리
GitLab의 표준 및 메모리 제한 하드웨어 요구 사항을 RAM, CPU, SSD와 리포지토리 저장 공간 기준으로 비교하고, ZimaOS 사용자 지정 설치에 적합한 실용적인 용량을 제시합니다.
GitLab requirements at a glance
GitLab publishes two very different sizing contexts. The standard single-node baseline is 8 vCPU and 16 GB RAM. A separate memory-constrained guide says very small installations can run with 1 AMD64 CPU core, 2 GB RAM plus 1 GB swap and 20 GB storage, but with swap and reduced performance. Do not treat the constrained profile as the normal production recommendation.
- CPU
- Standard single-node baseline: 8 vCPU. Memory-constrained AMD64 minimum: 1 CPU core for a very small installation.
- RAM
- Standard single-node baseline: 16 GB. Memory-constrained minimum: 2 GB RAM + 1 GB swap, with 2.5 GB + 1 GB swap described as optimal for that constrained profile.
- Storage
- Standard guidance: 40 GB for application-node needs, plus repository capacity and roughly 5–12 GB PostgreSQL storage. Constrained guide: 20 GB available storage.
- Storage type
- GitLab recommends SSD-backed storage for best performance, especially for Gitaly repository I/O. Network filesystems such as NFS are discouraged for critical GitLab storage.
- GPU
- No GPU is required for core GitLab source-control, issue, web or CI coordination workloads. Runners and optional AI/search components have separate requirements.
- Best Zima starting point
- ZimaCube 2 Pro is the cleanest current Zima match for GitLab's 16 GB/8 vCPU-class baseline. ZimaBoard 2 1664 is better framed as a small memory-constrained lab with added SSD storage.
From official requirements to the right setup
Size GitLab by separating the normal single-node baseline from the explicitly memory-constrained path, then add repository growth, CI artifacts, registry data, backups and runners as separate workloads.
-
Official requirements
Choose the sizing tier first. For a normal single-node installation, GitLab lists 8 vCPU and 16 GB RAM as the baseline. Only use the 2 GB RAM + 1 GB swap constrained profile for very small installations where reduced performance and swapping are acceptable.
-
Confirm your needs
Estimate repository and binary-data growth independently. Git repositories, LFS objects, CI artifacts, uploads, container-registry images and backups can dominate capacity long before the application package itself does.
-
Leave room to grow
Keep GitLab application services separate from GitLab Runner workloads when sizing. Build/test jobs can consume far more CPU, RAM and storage than the GitLab server and should not be silently counted as part of the server baseline.
-
Run it on ZimaOS
On ZimaOS, deploy GitLab through Install Custom App using the official Docker image/Compose pattern. Persist config, logs and data, choose a non-conflicting host SSH port if needed, and monitor Puma, Sidekiq, PostgreSQL, Gitaly and storage growth.
Check every playback client
- Standard baseline or memory-constrained deployment
- Number and size of Git repositories
- Git LFS, artifacts and package/registry usage
- CI/CD runners hosted locally or elsewhere
- Expected active users and background jobs
- SSD-backed GitLab data path
- SSH/HTTP/HTTPS port and hostname plan
- Backup, restore and object-storage strategy
Official minimum requirements
GitLab's main requirements page now gives an 8 vCPU/16 GB single-node baseline, while a separate official guide documents a much smaller resource-constrained configuration. Both are valid, but they describe different operating expectations.
For a serious all-in-one self-managed GitLab server, use the 8 vCPU/16 GB baseline as the primary target. The 2 GB + swap configuration is a special low-resource path for small installations and should be labeled as such.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Single-node CPU baseline | 8 vCPU | GitLab lists this as the baseline for a single-node installation. |
| Single-node memory baseline | 16 GB RAM | GitLab says memory-constrained installations can run with less, but the main requirements page uses 16 GB as the normal single-node baseline. |
| Memory-constrained RAM | 2 GB RAM + 1 GB swap minimum | GitLab describes 2.5 GB RAM + 1 GB swap as optimal for the constrained profile and expects regular swap use. |
| Memory-constrained CPU | 1 AMD64 core or 4 ARM cores | This belongs to the constrained-environment guide, not the normal 8 vCPU baseline. |
| Application storage | 40 GB minimum | GitLab's main requirements page lists 40 GB for application-node needs, before repository storage. |
| PostgreSQL storage | About 5–10 GB for most instances; at least 12 GB for Ultimate | Repository storage is additional and must be at least large enough for all repositories combined. |
| Constrained storage | 20 GB available storage | This is the separate low-resource profile; GitLab still prefers storage with strong random I/O, with SSD first in the stated preference order. |
When to upgrade your hardware
GitLab outgrows a host when application memory, repository I/O or background/CI data becomes the bottleneck. User count alone misses much of the load.
Puma, Sidekiq or PostgreSQL push memory pressure
Repository and artifact I/O saturate storage
CI runners compete with the GitLab server
Gitaly is I/O-sensitive, and repositories, LFS, artifacts, packages and registry images can create sustained random and sequential disk activity.
Code-heavy teams, monorepos and projects with large CI/artifact volumes.Local build and test jobs can consume CPU and memory unpredictably. Keeping runners on the same small host can make the server appear undersized even when GitLab itself is within its budget.
Teams running Docker builds, test suites or multiple concurrent pipelines.Plan hardware growth with confidence
Scale GitLab by protecting its persistent repository/database storage and separating optional heavy workloads before moving to a larger all-in-one host.
Use SSD-backed GitLab data volumes
GitLab explicitly recommends SSD storage for best performance, particularly for Gitaly repository I/O.
Use SSD/NVMe storage with ZimaBoard 2 or ZimaCube 2; do not rely on small eMMC as the primary repository and database volume.Keep runners off the GitLab server when possible
Separating CI/CD executors prevents build workloads from consuming the CPU, RAM and disk bandwidth reserved for GitLab's web, database and repository services.
Use another Zima node or external runner host for heavier builds; size the GitLab server independently.Move from constrained mode to the 16 GB baseline
The official low-resource profile accepts swap and reduced headroom. A 16 GB host removes much of that compromise and matches GitLab's current single-node memory baseline.
ZimaCube 2 Pro is the closest current Zima fit; ZimaBoard 2 1664 remains below the published 8 vCPU baseline.Expand repository/object capacity separately
Repositories, LFS, artifacts, registry data and backups can grow much faster than the application package or PostgreSQL database.
Use ZimaCube 2's SSD/HDD expansion or external S3-compatible object storage according to the workload.Can it run on ZimaOS?
GitLab is not currently presented in the public ZimaOS hardware catalog as a one-click ZimaOS App Store app. You can deploy GitLab through Install Custom App with the official Docker image, but its memory footprint, SSH port and persistent storage need deliberate configuration.
Custom install GitLab in ZimaOS
Use Install Custom App with an adapted version-pinned GitLab Docker Compose configuration. Persist /etc/gitlab, /var/log/gitlab and /var/opt/gitlab. If ZimaOS already uses host port 22 for SSH, map GitLab's SSH service to another host port and set the advertised GitLab Shell SSH port accordingly.
Custom install GitLab in the ZimaOS app ↗Use the official GitLab Docker image and persistent volumes
GitLab supports Docker Compose, Docker Engine and Swarm. The official image expects persistent config, logs and data paths and a valid externally accessible hostname.
Review GitLab Docker installation ↗Treat GitLab Runner as a separate workload
The GitLab server coordinates CI, but runner build/test jobs have their own CPU, memory and storage demand. Running heavy runners on the same ZimaOS box can invalidate otherwise reasonable server sizing.
Review GitLab Runner installation ↗Choose Zima hardware for GitLab
GitLab is heavier than many home-server apps. The key distinction is whether you accept the official memory-constrained mode for a tiny lab or want a system that matches the current 16 GB/8 vCPU-class single-node baseline.
Is this a tiny memory-constrained lab or a normal single-node GitLab server?
Tiny lab or low-traffic personal GitLab
A 16 GB ZimaBoard 2 can run GitLab with substantial memory headroom over the constrained profile, but its 4-core N150 does not match GitLab's current 8 vCPU normal baseline.
- Constrained/lab optionZimaBoard 2 1664
Normal single-node team deployment
Use a platform that reaches the 16 GB memory baseline and offers at least an 8-thread CPU class, plus SSD-backed repository/database storage.
- Best current Zima fitZimaCube 2 Pro
- More RAM for broader consolidationZimaCube 2 Creator Pack
These recommendations do not guarantee a user count, repository size or CI throughput. Git history, monorepos, LFS, artifacts, packages, registry images, Sidekiq load, PostgreSQL, backups and local runners can radically change requirements.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 1664 | Personal labs and very small GitLab deployments using the constrained-resource approach. | Low-traffic GitLab with a limited repository set, no heavy local runners and SSD-backed data storage. |
|
This does not meet GitLab's current 8 vCPU normal single-node baseline. Add SSD storage; do not put the repository/database workload only on the 64 GB eMMC. | Get Now |
| ZimaCube 2 Pro | A normal single-node GitLab team server with expandable SSD storage. | GitLab web, Sidekiq, PostgreSQL and Gitaly with moderate repositories, artifacts and external/separate CI runners. |
|
Sixteen gigabytes matches the current memory baseline but leaves limited room for heavy local runners, large optional services or broad multi-app consolidation. Repository capacity must be sized separately. | Get Now |
| ZimaCube 2 Creator Pack | GitLab plus many companion services or memory-heavy development infrastructure. | Larger GitLab service stack, monitoring, registry/object workflows, more containers and substantial local storage growth. |
|
The dedicated GPU is unnecessary for normal GitLab. Choose this configuration for memory/storage consolidation or other workloads, not because source control needs graphics acceleration. | Get Now |
What the Press Says
Highlights from trusted reviewers worldwide.
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”Read full review
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”Read full review
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”Read full review
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”Read full review
Loved by the Community
Stories and reviews from people who build with Zima every day.
★★★★★
Zima Blade Little yet Powerful
Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.
★★★★★
Very good!!
I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.
★★★★★
Great innovation for mini server!
It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.
★★★★★
Avaliação ZimaBoard 2
Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.
Frequently asked questions
These answers separate GitLab's current normal single-node baseline from its special memory-constrained profile and cover RAM, CPU, storage, SSD, runners and Zima hardware.
How much RAM does GitLab need?
GitLab's current single-node baseline is 16 GB RAM. A separate official memory-constrained guide says very small installations can run with 2 GB RAM plus 1 GB swap, with 2.5 GB plus 1 GB swap described as optimal for that constrained profile.
Can GitLab run on 4 GB or 8 GB RAM?
Yes, small installations can run below the normal 16 GB baseline when tuned as a constrained environment. GitLab explicitly documents operation with at least 2 GB RAM plus swap, but this trades away headroom and can involve regular swapping under normal operation.
How many CPU cores does GitLab need?
The normal single-node baseline is 8 vCPU. GitLab's constrained guide lists 1 AMD64 CPU core or 4 ARM cores for a very small installation. These are different sizing tiers and should not be presented as equivalent.
How much storage does GitLab need?
GitLab's main requirements page lists 40 GB for application-node needs, plus enough storage for all repositories and roughly 5–10 GB for PostgreSQL on most instances or at least 12 GB for Ultimate. LFS, artifacts, packages, registry images and backups add more.
Does GitLab need an SSD?
GitLab recommends SSD-backed storage for best performance and specifically notes that Gitaly repository storage is I/O intensive. The constrained guide also ranks SSD ahead of eMMC and HDD for random I/O.
Does GitLab need a GPU?
No GPU is required for core GitLab source control, issues, web UI and CI coordination. Optional AI/search services and CI jobs may have separate acceleration requirements and should be sized independently.
Can ZimaBoard 2 run GitLab?
A 16 GB ZimaBoard 2 can run a small GitLab deployment and is well above the official constrained-memory floor, but its 4-core N150 does not match GitLab's current 8 vCPU normal single-node baseline. Treat it as a lab/small-instance option with added SSD storage.
Should GitLab Runner run on the same ZimaOS server?
Light jobs can technically share a host, but runner workloads should be sized separately. Builds, tests and Docker image creation can consume far more CPU, RAM and disk bandwidth than GitLab itself, so external or separate runners are safer for predictable server performance.
What sources informed this GitLab hardware guide?
The guide uses current GitLab installation, memory-constrained and Docker documentation for all upstream requirements. Current Zima product pages are used only for Zima specifications and workload matching.
