Self-Hosted GitLab Server Requirements and Hosting Cost in 2026

Teams that search for GitLab's server requirements usually want two numbers: how much memory the box needs, and what the box will cost. GitLab's own requirements page, checked on 1 November 2026, gives the first answer plainly, and this guide turns it into the second for a self-hosted GitLab CE on MassiveGRID PaaS, built on Virtuozzo Application Platform (formerly Jelastic), where the server is billed hourly by the cloudlet rather than by the month.

What GitLab says it needs

GitLab's installation requirements page is unusually direct about memory. For a single-node install, 16 GB of RAM is the baseline and 8 vCPU is the baseline; a memory-constrained install can run with at least 8 GB. The page does not tie those figures to a user count, and sends anyone sizing for load to the reference architectures, but the baseline is what the Linux package assumes when it configures Puma and Sidekiq for you. ARM processors are supported; burstable instance types are not recommended, because GitLab's background load is steady rather than bursty.

Storage is split by role. The application node wants 40 GB minimum for the package, operating system, logs and temporary files. Repository storage, which Gitaly serves, needs at least as much space as all repositories combined, on SSD-backed disk, and GitLab warns against network file systems such as NFS, Amazon EFS and Azure Files for it. PostgreSQL needs 5 to 10 GB for most instances and at least 12 GB on GitLab Ultimate.

Two more lines matter for sizing. Swap should be disabled where possible, because swapping degrades GitLab badly under load; if it cannot be disabled, provision enough memory that GitLab never touches it. And each Sidekiq process needs at least 200 MB and grows under load, rising to at least 1 GB per process above 10,000 users.

Translating the figures into cloudlets

MassiveGRID PaaS allocates memory and CPU in cloudlets of 128 MiB RAM plus 400 MHz CPU, so GitLab's figures convert directly: 8 GB is 64 cloudlets, 16 GB is 128. Because billing is hourly for the cloudlets a container actually uses, the allocation is a ceiling rather than a reservation, which changes how the baseline should be read. A 16 GB allocation on a server that idles at 6 GB overnight is billed for 6 GB overnight.

The GitLab package on the marketplace carries three configurations in its sizing table. Starter gives the GitLab CE server 64 cloudlets (8 GiB), GitLab's memory-constrained minimum, for a small team with few pipelines. Standard gives it 128 cloudlets (16 GiB), the published baseline, plus a runner at 8 cloudlets. Production keeps the 16 GiB server and adds two 16-cloudlet runners for parallel pipelines. The runners are the package's auto-scaling CI runners, which the platform adds and removes with the pipeline queue; the Docker registry runs on the same node.

The CPU side of GitLab's baseline, 8 vCPU, is covered by the cloudlet's 400 MHz share: 128 cloudlets carry 51 GHz of CPU allocation, more than the baseline asks for, and the platform's vertical scaling hands it out as Puma and Sidekiq demand it.

What each configuration costs per month

At the published rate of $0.003372 per cloudlet-hour, which is $2.46 per cloudlet for a 730-hour month, the three configurations price as follows before volume discounts. Disk is billed per gigabyte on top, which matters more for GitLab than for most applications because repositories, artifacts and the container registry grow.

The working-hours column is not hypothetical. A GitLab that serves a team in one time zone can be hibernated with the Start/Stop Scheduler add-on outside working hours, which is common for staging and review instances and uncommon for the production GitLab a distributed team pushes to at all hours. The PaaS pricing calculator prices any hour count and any topology.

Where self-hosters overspend and underspend

Underspending on memory is the classic mistake. GitLab on 4 GB, which older guides still recommend, runs until the first large merge request or the first CI burst, and then Puma workers are killed and Sidekiq queues back up. The 8 GB floor exists because GitLab measured it; treat it as a floor.

Overspending on the server to run CI is the second. Pipelines belong on runners, which on the marketplace package are separate auto-scaling nodes billed only while they run. A 16 GB GitLab with two runners costs less per month than a 32 GB GitLab that also builds, and it survives a runaway build.

Storage is where estimates drift. Repositories are small; artifacts, package registries and container images are not. Set expiry policies on artifacts and the registry from the first week, and watch the per-gigabyte disk line on the invoice rather than the cloudlet line.

Swap is a trap on a VPS and a non-issue on the platform. A container on MassiveGRID PaaS has no swap to fall back on; when GitLab needs memory, vertical scaling adds cloudlets up to the limit you set, and the dashboard's OOM statistics show when the limit was too low.

A sizing walkthrough for a 25-developer team

Take a product company with 25 developers, 60 repositories, and a CI pipeline on every merge request. GitLab's baseline applies: start the server at the Standard row's 128 cloudlets, because 25 developers with CI generate the steady background work (Sidekiq, Gitaly, the registry) that the 16 GB figure was written for. Give the runner layer two 16-cloudlet nodes and let the auto-scaling trigger add a third when the queue grows at release time.

In the dashboard after a week, the server's memory graph will show the real average, typically between 9 and 12 GB for a team of that size, and that average is what the invoice reflects. If the average sits well under the limit, the limit is fine; if it hugs the limit, raise it. The monthly figure lands between the Standard and Production rows, around $300 to $390 before discounts plus disk, which is the comparison to put beside GitLab.com's per-seat plans for the same team.

The auto-scaling runners post covers the CI side in detail, and the GitLab SaaS versus self-hosted comparison does the per-seat arithmetic for a 40-developer team.

Frequently Asked Questions

Can GitLab run on 4 GB of RAM?

Not supportably. GitLab's requirements page, checked on 1 November 2026, gives 16 GB as the baseline and at least 8 GB for a memory-constrained install. The Starter configuration on MassiveGRID PaaS allocates 8 GiB for that reason; a smaller allocation will be killed under load.

Does the monthly cost include CI runners?

The Standard and Production rows include one and two runner nodes respectively, billed only for the hours they run. Runners scale with the pipeline queue, so a quiet week costs less than the table and a release week can cost more.

How is repository storage billed?

Per gigabyte used, on top of the cloudlets, and the same applies to artifacts, package registries and container images. GitLab recommends SSD-backed storage for Gitaly and advises against NFS; the platform's persistent storage is local SSD.