GitLab is not a light app. Its own documentation sets a 4 GB RAM floor, and that floor is for standing, not for running fast. Here are the numbers the docs demand, and what a small team actually feels day to day.
Most disappointing GitLab installs fail before the first login, at the sizing screen. Someone gives the VM 2 GB of RAM because it is just a website with Git, and then the team concludes that self-hosted GitLab is slow. It is not just a website. It is repositories, a PostgreSQL database, background job workers, search indexing and, if you use it, CI machinery, all sharing one box. Size it before you install it and the same software feels like a different product.
👆 The bar that decides whether GitLab feels fast or frustrating. Everything else in this guide matters, but this one matters first.
GitLab's official installation requirements state that 4 GB RAM is the required minimum, and pair it with up to 500 users on paper. Read that pairing carefully: it describes a machine that stays within its limits when the workload is gentle, with at least 2 GB of swap space recommended as a safety buffer. In real life, a freshly booted GitLab already occupies most of 4 GB before your team does anything. The moment CI builds or several developers push at once, the box starts swapping and every page feels sticky. For a team that will actually work on it daily, 8 GB is the honest default, not a luxury.
The same requirements page makes 4 cores the recommended minimum, with 8 cores listed for up to 1000 users. CPU is more forgiving than RAM at small-team scale. Two virtual CPUs will serve five developers pushing code, but page loads queue up behind background jobs and pipeline runs, and everything slows at the same busy moments - usually the hour before a release. If your VM host can spare 4 cores, give them. If it cannot, know that you have chosen the trade, and do not blame GitLab for it later.
The GitLab software package itself needs roughly 2.5 GB just to install. After that, your repositories decide everything, and the official guidance is to keep at least as much free space as all your repositories combined. Start with 60 to 100 GB for a small team and put it on an SSD: GitLab reads and writes constantly, and a slow spinning disk makes the whole interface feel tired. Remember that Git history only grows, and one developer committing a folder of large binary files can eat a year of planned space in an afternoon. Watch the disk monthly, the way you watch a fuel gauge.
Trap one: the VM lives on a host that also runs other virtual machines, and its 8 GB exists only on paper because the host has already promised that memory elsewhere. GitLab needs its RAM to be actually free, not over-committed hope. Trap two: your CI runners execute on the same machine, so every build competes with the web interface for the same memory and CPU. Either separate the runner onto another box, or add resources for both jobs. A GitLab squeezed into a leftover corner of a busy server is the single most common reason teams wrongly conclude that self-hosting is slow.
Watch the full install in the video, then come back to these numbers before you create the VM.
▶️ Watch Full VideoThat is below GitLab's documented 4 GB minimum. Memory-constrained tricks exist, but pages time out and background jobs fail under real use. Treat 2 GB as a look-around demo at best, never as a team server.
GitLab's requirements page pairs 8 GB RAM with up to 1000 users on paper, but real life depends on activity and CI load. For a typical small team, 8 GB is comfortable headroom - not a limit you are likely to meet.
On a LAN, no. The team reaches the server locally at full network speed. Internet speed matters only for remote users, and for downloading the appliance and updates.