A self-hosted GitLab server, sized to GitLab's own baseline

What GitLab asks of the machine

PostgreSQL versions are tied to GitLab's major versions: GitLab 18 needs PostgreSQL 16.5 to 17, GitLab 19 needs 17 or 18. The Linux package ships its own, so on one node you rarely manage that yourself.

Why bare metal suits it

GitLab is many processes on one host: the web application, background jobs, Gitaly serving repositories, PostgreSQL and Redis. They all lean on the same disks, and GitLab's own guidance (SSD, no network file systems, no swap, no burstable CPU) is a description of a machine whose resources do not move under it.

On NVMe dedicated servers the storage is local NVMe, with hardware RAID on the blade and rack lines and software RAID on the m510, m710x and m750 cartridges. The access-switch port is yours alone and unmetered, which matters on the day every developer clones at once. Ubuntu up to 26.04 is installed when you configure the server, root is yours, and the blade, rack, m510 and m710x lines carry an out-of-band iLO, iDRAC or BMC console.

Installing the Linux package on Ubuntu

1. Point a DNS name, here gitlab.example.com, at the server. Let's Encrypt needs inbound HTTP and a valid hostname.
2. Add GitLab's package repository and install, setting EXTERNAL_URL on the same line. With an https address, GitLab requests a Let's Encrypt certificate itself.
3. Sign in as root with the password in /etc/gitlab/initial_root_password. GitLab deletes that file after 24 hours, so change the password first.

sudo apt update
sudo apt install -y curl
curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh" | sudo bash
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce
sudo cat /etc/gitlab/initial_root_password

That is the Community Edition; the Enterprise Edition uses gitlab-ee in both lines. GitLab's Linux package supports Ubuntu 22.04, 24.04 and, from GitLab 19.3, 26.04. Ubuntu 20.04 is no longer supported.

GitLab's install guide opens the three ports it needs, SSH for Git and the console, HTTP for the certificate, HTTPS for everything else, then enables the firewall:

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

Backups that restore

sudo gitlab-backup create captures the database and the repositories. It does not store configuration files, and two of them decide whether the backup can be used: /etc/gitlab/gitlab-secrets.json, which holds the database encryption key, and /etc/gitlab/gitlab.rb. Without the secrets file GitLab cannot decrypt the encrypted values in a restored database.

sudo gitlab-backup create
sudo mkdir -p /root/gitlab-config
sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /root/gitlab-config/

Then move both off the server, and keep them apart: GitLab's docs point out that storing encrypted data next to its key defeats the encryption.

Upgrades follow stops

GitLab cannot jump versions freely. Each major series has required stops you must upgrade through before later versions, and GitLab's Upgrade Path tool lays out the route from your version to the target. Take a backup before each step, and read the stop's notes for background migrations that must finish first.

CI runners belong elsewhere

GitLab's runner documentation says to install GitLab Runner on a machine separate from the GitLab instance, for security and performance. A pipeline compiling, testing and building images competes with Gitaly and PostgreSQL for the same cores and disks, and a job runs whatever its repository tells it to.

That makes the natural build a pair: one server for GitLab, one or more for runners, each sized for its own job. Both can be built to order with the processor, memory and drives chosen part by part.

When one server is not enough

The single-node figures above are GitLab's baseline. Its reference architectures split the components across nodes as load grows, and that is a design exercise, not a bigger box. For a handful of developers, GitLab's own hosted service removes the maintenance entirely; a machine of your own earns its place when the code must stay on your hardware, the instance is large, or the pipelines need hardware you choose. Moving an instance that already exists is covered on the migration page.