Self-Host GitLab: What It Actually Needs (Real RAM Numbers)

What Does Self-Hosted GitLab Actually Need?

There is an important difference between the smallest server that may be capable of launching GitLab and a server that gives GitLab enough room to operate comfortably.

GitLab’s official recommendations are intentionally more conservative than many inexpensive-VPS tutorials. That is sensible because production performance depends on repository activity, number of users, background jobs, CI workloads and the GitLab features you enable.

A useful real-world reference

A recent independent deployment test of GitLab CE 19.2.1 on Ubuntu 24.04 reported approximately 5.5 GB of whole-system memory consumption while idle with the default configuration. After reducing Puma workers, monitoring overhead and background-job concurrency, the same test reduced idle memory to around 3 GB.

Those numbers should be treated as a reference rather than a guarantee for your server. GitLab memory consumption changes with versions, workloads, repositories, users and enabled services.

What Does It Cost to Self-Host GitLab?

The GitLab Community Edition software can be self-hosted without paying a per-user software fee. Your direct expense is primarily the infrastructure used to operate it.

That means your monthly server bill remains relatively predictable even if you add several developers. On the other hand, you become responsible for server administration, upgrades, monitoring, backups and security.

For one person, GitLab.com’s hosted free offering may be simpler than paying for a VPS. The self-hosted model becomes more compelling when you need data ownership, custom networking, internal infrastructure, additional control or predictable costs as a team grows.

1Choose a VPS for GitLab

Start with a clean Ubuntu server. Ubuntu 24.04 is supported by current GitLab Linux packages and is an excellent choice for a new deployment.

For most readers following this guide, I would choose an 8 GB RAM VPS with at least 4 virtual CPU cores and SSD storage. You can use DigitalOcean, Hetzner, Vultr, Linode, AWS, Google Cloud or another reputable provider.

If you already use a VPS provider, there is usually no technical reason to move solely for GitLab. What matters most is reliable storage, sufficient RAM, backups and access to a recovery console if SSH becomes unavailable.

2Point a Subdomain to Your Server

Instead of putting GitLab directly on your main domain, a dedicated subdomain is usually cleaner:

gitlab.example.com

Open your DNS provider and create an A record.

Wait until the record resolves to your VPS. You can verify it from your computer:

nslookup gitlab.example.com

3Install GitLab Community Edition

Connect to the server using SSH.

ssh root@YOUR_SERVER_IP

Update Ubuntu

sudo apt update
sudo apt upgrade -y

Install required packages

sudo apt install -y curl ca-certificates tzdata perl openssh-server

Add the official GitLab CE repository

curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh" | sudo bash

Install GitLab CE

Replace the example hostname with your own GitLab domain.

sudo EXTERNAL_URL="https://gitlab.example.com" apt install -y gitlab-ce

GitLab will install and configure the services included with the Linux package. Depending on your VPS CPU, network speed and storage performance, the initial installation may take several minutes.

Get the initial root password

sudo cat /etc/gitlab/initial_root_password

Check GitLab services

sudo gitlab-ctl status

Now visit:

https://gitlab.example.com

Sign in with:

• Username: root
• Password: the password from the initial password file

4Lock Down Your GitLab Server

A working installation is only the beginning. If your GitLab server is reachable from the public internet, hardening should be part of the setup, not something postponed until later.

Configure UFW

GitLab normally needs SSH plus HTTP and HTTPS access:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

Use SSH keys

Public-key authentication is preferable to repeatedly exposing a privileged account to password-based login attempts.

Once key-based access has been tested, you can review your SSH configuration:

sudo nano /etc/ssh/sshd_config

A hardened configuration may include settings such as:

PasswordAuthentication no
PermitRootLogin prohibit-password

Reload SSH only after confirming that your key works.

sudo systemctl reload ssh

Disable public registration if you don’t need it

If this is a private GitLab installation for you or your company, there is usually no reason to permit anybody on the internet to create an account.

Inside GitLab, go to your administrator settings and review the Sign-up restrictions. Disable new registrations unless public account creation is intentional.

Enable two-factor authentication

Administrator credentials deserve additional protection. Enable two-factor authentication for your GitLab account and strongly consider requiring it for other users.

How to Measure GitLab Memory on Your Own Server

Instead of relying entirely on somebody else’s benchmark, measure your installation after it has been running for a while.

Check total system memory

free -h

Watch processes interactively

top

For a friendlier interface:

sudo apt install -y htop
htop

Check GitLab services

sudo gitlab-ctl status

Do not judge the server only five seconds after a reboot. Allow the application to start completely and observe memory during normal use. Clone repositories, browse projects, push changes and trigger normal background activity.

How to Reduce GitLab RAM Usage

For a memory-constrained GitLab server, several components can be tuned. The trade-off is important: reducing worker counts or disabling monitoring can decrease memory consumption, but it can also lower throughput or remove built-in monitoring functionality.

Open the GitLab configuration

sudo nano /etc/gitlab/gitlab.rb

1. Reduce Puma processes

Puma runs the Rails web application. On a small server, reducing the number of processes can dramatically decrease memory consumption, although request throughput is reduced.

puma['worker_processes'] = 0

2. Lower Sidekiq concurrency

Sidekiq handles background work. A smaller installation can often operate with lower concurrency than a busy production instance.

sidekiq['concurrency'] = 10

3. Review Prometheus monitoring

The bundled monitoring components consume resources. If you deliberately choose not to use GitLab’s Prometheus monitoring on a small private server, you can review whether disabling it fits your environment.

prometheus_monitoring['enable'] = false

Apply configuration changes

sudo gitlab-ctl reconfigure

Then measure again:

free -h
sudo gitlab-ctl status

Can You Self-Host GitLab on 4 GB of RAM?

Technically, a carefully tuned low-traffic GitLab instance can fit into a 4 GB environment. That does not mean 4 GB is the right recommendation for every installation.

The main issue is headroom.

Imagine GitLab is already consuming around 3 GB. Ubuntu, filesystem cache, SSH, package upgrades, repository operations and temporary workload spikes must all share whatever remains.

Add swap as an emergency buffer

Swap is not a replacement for RAM. It can, however, give the operating system additional breathing room instead of immediately killing processes during a brief memory spike.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Verify:

sudo swapon --show
free -h

To make it persistent across reboots:

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Back Up GitLab Before You Need the Backup

If your GitLab instance contains the only copy of important repositories, issues, configuration and CI data, your backup strategy is part of the installation.

Create a GitLab backup

sudo gitlab-backup create

GitLab application backups do not eliminate the need to preserve important configuration and secrets. Back up:

• GitLab application data
• /etc/gitlab/gitlab.rb
• /etc/gitlab/gitlab-secrets.json
• Your SSL configuration if managed manually
• Any custom SSH or firewall configuration

What Are GitLab Upgrades Like?

Self-hosting means you are responsible for applying security updates and moving through supported GitLab versions.

For an Ubuntu/Debian Community Edition installation, the normal package update begins with:

sudo apt update
sudo apt install gitlab-ce

However, you should not automatically jump across several major GitLab versions. GitLab maintains required upgrade paths for certain versions.

After an upgrade, check:

sudo gitlab-ctl status
sudo gitlab-rake gitlab:check SANITIZE=true

GitLab vs Lightweight Self-Hosted Alternatives

Before committing an 8 GB or larger VPS to GitLab, ask whether you actually need the full GitLab platform.

If your requirement is primarily private Git repositories, user accounts and a clean web interface, lighter Git platforms can be significantly less resource-intensive.

Choose GitLab when:

• You want a broad DevOps platform instead of only Git hosting.
• You value full control over your repositories and server.
• Your organization needs private infrastructure.
• You want integrated CI/CD and project functionality.
• You accept the operational work that comes with self-hosting.

Choose something lighter when:

• You mainly need private Git repositories.
• Your VPS has very little RAM.
• You don’t need most of GitLab’s integrated platform.
• You want the simplest possible maintenance routine.

Build a Complete Self-Hosting Stack

GitLab becomes even more useful when it is part of a broader self-hosted environment. Once you are comfortable managing DNS, HTTPS, Linux services, backups and security, you can use the same skills to operate other applications.

Continue with these related guides:

• What Is Self-Hosting? Complete Beginner’s Guide
• How to Self-Host Supabase
• How to Deploy Apps With Coolify
• Browse More Server and AI Guides

If these URLs are different on your WordPress site, replace them with your actual related article URLs. These contextual internal links can help both readers and search engines understand the relationship between your self-hosting articles.

Is Self-Hosting GitLab Worth It?

GitLab is an impressive self-hosted platform, but it should not be treated like a tiny web application. A full installation combines multiple services, and those services require meaningful memory and storage.

For most new installations, an 8 GB VPS is a much more sensible starting point than trying to squeeze the default stack into the cheapest server available. If your installation is small, memory tuning can reduce the footprint substantially, but every optimization should be weighed against performance and functionality.

The deciding question is not simply whether GitLab can run on your VPS. The better question is whether you need enough of GitLab’s integrated platform to justify the resources and administration it requires.

If you want repositories, merge requests, CI/CD, user management and DevOps features under one roof—and you value control over your infrastructure— self-hosting GitLab can make excellent sense.

If you only want a private Git server, a lightweight alternative such as Forgejo or Gitea may accomplish the job with dramatically less infrastructure.

Self-Hosted GitLab FAQ

Technical References

For installation and maintenance, always verify commands against current official documentation because GitLab changes over time.

• Official GitLab Linux Package Installation Documentation
• GitLab Ubuntu Installation Documentation
• GitLab Puma Administration Documentation
• Official GitLab Upgrade Documentation