Your team's own self-hosted GitLab server

How big a server does GitLab need?

GitLab's own requirements answer this. For a single server, the starting point is 8 virtual CPUs and 16 GB of memory. It will run on 8 GB, but that is the floor, not the comfortable middle.

• Disks: at least 40 GB for GitLab itself, the system, logs and temporary files, plus room for every repository you will store. GitLab recommends SSDs and warns against network file systems such as NFS.
• Database: GitLab uses PostgreSQL and nothing else. Most instances need 5 to 10 GB for it. The installer brings its own copy.
• Swap: GitLab says to switch it off where you can, because it slows everything under load. If you cannot, give the server enough memory that swap is never touched.
• Processor: GitLab advises against burstable cloud instances, whose speed changes from minute to minute.

The server that fits

Everything GitLab asks for, steady cores, plenty of memory and fast local disks, describes a dedicated machine. Our NVMe servers put the code and database on NVMe drives. Blade and rack models put the drives behind a hardware RAID controller; the m510, m710x and m750 cartridge models use software RAID instead.

Your network port is not shared with any other customer at the switch, and it is unmetered, so a morning where everyone clones the big repository costs nothing extra. A failed drive or any other part is replaced within four hours of your call.

Installing GitLab, step by step

1. Choose Ubuntu 24.04 or 26.04 for the server; GitLab supports both, and 26.04 from GitLab 19.3.
2. Point a web address such as gitlab.yourcompany.com at the server's IP address. GitLab's free Let's Encrypt certificate needs it, along with incoming web traffic.
3. Run the commands below. They add GitLab's package source and install the free Community Edition with your address built in.
4. Open your address and sign in as root. GitLab writes the first password to /etc/gitlab/initial_root_password and removes that file a day later, so read it and set your own straight away.

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.yourcompany.com" apt install gitlab-ce
sudo cat /etc/gitlab/initial_root_password

GitLab's installation guide opens three firewall ports: 22 so people can push code over SSH, 80 so the certificate can be issued, and 443 for the site itself. If you use ufw, allow those three before you enable it.

The backup step people miss

GitLab's backup command saves your repositories and database, but not its settings. Two files have to be saved by hand: gitlab-secrets.json, which holds the key GitLab uses to encrypt sensitive data in the database, and gitlab.rb, your configuration. Restore a backup without the secrets file and GitLab cannot read the encrypted parts of its own 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/

Copy both the backup and the two files off the server, and store the files somewhere other than the backup itself. A key kept next to the data it protects protects nothing.

Upgrading without surprises

You cannot leap straight from an old GitLab to the newest one. Each major version has required stops you must pass through in order. GitLab's Upgrade Path tool tells you exactly which versions to install between where you are and where you are going. Back up before every stop.

Give your pipelines their own machine

GitLab recommends running GitLab Runner, the program that executes your CI/CD jobs, on a different machine from GitLab itself, for both security and speed. Builds and tests are heavy, and they run whatever code a repository contains. Kept apart, a slow build never makes the web interface crawl for everyone else.

So plan for two servers: one for GitLab and one or more for runners. Each can be built to order: you pick the processor, memory and disks for its job.

When hosting it yourself is not worth it

For a small team that just wants Git hosting, GitLab's own hosted service takes all of this off your plate. Your own server makes sense when the code has to stay on hardware you control, when the team or the repositories are large, or when your pipelines need a specific machine. And if you are moving an existing GitLab, our migration help is free.

Questions people ask

Can GitLab run on 8 GB of memory?

Yes, GitLab's requirements say a single server works with as little as 8 GB. Its recommended starting point is 16 GB, though, and swap should stay off or unused, so 16 GB is the safer choice for a team.

Is the Community Edition free?

Yes. The commands on this page install gitlab-ce, the free Community Edition. The Enterprise Edition installs the same way with gitlab-ee in place of gitlab-ce.

Do I have to set up the HTTPS certificate myself?

No. If your address starts with https, GitLab's installer requests a free Let's Encrypt certificate for you. Your domain has to point at the server and port 80 has to be reachable.

Why do I need to back up gitlab-secrets.json?

It holds the key GitLab uses to encrypt sensitive data in its database. The normal backup does not include it, and a restore without it leaves the encrypted data unreadable.

How quickly can I have a server?

A server we already have racked is ready in about 30 minutes once your order is approved. A custom build takes 4 to 24 hours, sometimes longer depending on parts.

Should my CI jobs run on the GitLab server?

GitLab recommends against it. Give GitLab Runner its own machine so builds cannot slow down or endanger the server that holds your code.