Self-hosted GitLab CE: minimum viable server spec

I have seen GitLab CE grind a 2 GB VPS to a halt, and I have also seen it run reasonably well on hardware that most guides dismiss as "too small." The difference is knowing exactly which knobs to turn and what to expect before you hand over your credit card. This article lays out the real, honest minimum server requirements to run GitLab CE, not the marketing version, and matches each spec to a concrete VPS plan that will not leave you staring at a 502 error page every time three people push code.

Prerequisites

• A Linux VPS running Ubuntu 24.04 LTS or Debian 12. I recommend Debian 12 because its lower default memory footprint leaves more room for GitLab.
• Full root access via SSH. GitLab needs to bind to privileged ports (80, 443) and install system packages.
• A registered domain name pointed at your VPS IP address (an A record). GitLab does not run comfortably on a raw IP.
• Familiarity with the terminal. This is not a shared hosting setup.

自托管 GitLab CE 至少需要 4 GB 内存和 2 个 vCPU，否则服务会频繁崩溃。

Self-hosted GitLab CE needs at least 4 GB of RAM and 2 vCPUs, or the service will crash frequently.

Why Self-Host GitLab at All?

GitLab SaaS is a mature product, but there are concrete reasons to run your own instance. When you self-host, every pipeline minute, every artifact, every container registry push stays inside your own infrastructure. No per-user seat licensing, no storage limits that grow into surprise bills, and no "maintenance window" that interrupts your deployment schedule at an inconvenient hour. For teams that handle sensitive code or operate under data-residency rules, for example, a Vietnamese company whose code must stay on infrastructure operated by Viettel IDC or VNPT IDC under domestic jurisdiction, self-hosting is not a luxury. It is a compliance requirement. The trade-off is that you become the operations team, which means the server spec matters.

What GitLab CE Actually Needs Before It Works

GitLab is a monolith. Inside the same /opt/gitlab directory sit a Rails application server, Sidekiq background workers, a PostgreSQL database, a Redis cache, an Nginx reverse proxy, and a repository file system that grows as your team commits. Each one of these components demands a slice of your RAM and CPU, and the official documentation is surprisingly honest about the floor: 4 GB of RAM and 2 vCPUs for a basic installation with up to 100 users. That is not a "nice to have." That is the limit below which the gitlab-ctl reconfigure command completes, but the web UI times out, Sidekiq queues back up, and the bundled Prometheus process gets OOM-killed every few hours.

I have tested GitLab CE 16.x and 17.x on a single vCPU with 2 GB of RAM. It installs. It runs. Then the first push from two developers at the same time triggers a CI pipeline, Prometheus scrapes metrics, and the server starts swapping heavily. The swap file is on NVMe storage, so it is not as painful as spinning rust, but it is still orders of magnitude slower than RAM. The experience is borderline usable for one person testing the interface; it is not usable for a team.

Step 1, Choosing the Right VPS Tier for GitLab CE

Given the numbers above, the sweet spot is a 4 GB RAM VPS with 2 vCPUs. At thueVPS, that is the VNx2 tier: 2 vCPU, 4 GB RAM, 50 GB NVMe storage, a dedicated IPv4 from the Vietnam range, and domestic bandwidth capped at 100 Mbps on a 1 Gbps port. The international bandwidth is a shared pool, roughly 4 to 10 Mbps, which is fine for pulling Docker images from Docker Hub or for a small remote team. Keep in mind that traffic is unlimited with no data cap, so you are not counting gigabytes.

The VNLite tier (1 vCPU, 2 GB RAM, 20 GB NVMe) is tempting because it is cheaper, but I do not recommend it for GitLab. A 2 GB machine will work only if you disable Prometheus, reduce Sidekiq concurrency to one, and never run more than one CI job at a time. Even then, the experience is fragile. If your team is larger than two people, skip it and start at VNx2. For teams of 10 to 20 developers running multiple CI pipelines, the VNx4 (4 vCPU, 8 GB RAM, 80 GB NVMe) gives you room to breathe, especially if you store large artifacts or container images in the built-in registry. The VNx8 (8 vCPU, 16 GB RAM, 100 GB NVMe) is overkill for most GitLab-only workloads; you would use it if you also run additional services on the same host, but the standard recommendation for a dedicated GitLab instance is to keep other services off it.

Step 2, Installing GitLab CE on Ubuntu 24.04 or Debian 12

The installation process has not changed much in recent years. Open an SSH session as root and run the following commands. I use Debian 12 in the example, but the procedure on Ubuntu 24.04 is identical except for the package repository URL (you select the distribution name accordingly).

apt update
apt install -y curl openssh-server ca-certificates perl

Then add the official GitLab repository and install the CE package:

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash
EXTERNAL_URL="https://gitlab.yourdomain.com" apt install gitlab-ce

Replace gitlab.yourdomain.com with your real domain. The installer runs gitlab-ctl reconfigure at the end, which sets up PostgreSQL, Redis, Nginx, and all internal services. This step takes 3 to 5 minutes on a 4 GB VPS with NVMe storage. When it finishes, you can access the GitLab web UI at https://gitlab.yourdomain.com and set the initial root password from the page that loads.

Step 3, Post-Install Tweaks That Save Your Sanity

The default configuration is designed for servers with more resources than a 4 GB VPS. You need to make a few changes immediately.

Disable Prometheus and node_exporter, the bundled monitoring stack consumes about 400 MB of RAM on its own. Unless you are integrating GitLab metrics into a central Prometheus setup, turn it off:

gitlab-ctl stop prometheus
gitlab-ctl stop node_exporter
gitlab-ctl stop redis_exporter
gitlab-ctl stop postgres_exporter
gitlab-ctl stop gitlab_exporter

echo "prometheus_monitoring['enable'] = false" >> /etc/gitlab/gitlab.rb
echo "node_exporter['enable'] = false" >> /etc/gitlab/gitlab.rb

Then run gitlab-ctl reconfigure and gitlab-ctl restart. Check the memory difference with free -h. You should see roughly 300 to 400 MB freed.

Reduce Sidekiq concurrency, the default is 25 Sidekiq threads. On a 4 GB box, that number can spike memory usage during CI backlogs. Set it to 10:

echo "sidekiq['concurrency'] = 10" >> /etc/gitlab/gitlab.rb
gitlab-ctl reconfigure
gitlab-ctl restart

Lower PostgreSQL memory settings, the automatic tuning picks values that assume more RAM is available. Override them to be conservative:

echo "postgresql['shared_buffers'] = '512MB'" >> /etc/gitlab/gitlab.rb
echo "postgresql['work_mem'] = '8MB'" >> /etc/gitlab/gitlab.rb
gitlab-ctl reconfigure
gitlab-ctl restart postgresql

Verify that everything is running and within your memory budget:

gitlab-ctl status
free -h

Each service should show a PID and a run state. The free output should show 500 to 800 MB free + cached, with no swap usage.

Step 4, Setting Up Backups (Do Not Skip)

GitLab stores your code, issues, CI/CD configurations, and merge requests in one PostgreSQL database plus the repository file system on disk. The built-in backup Rake task is reliable and should run daily through a cron job:

gitlab-rake gitlab:backup:create
echo "0 3 * * * /usr/bin/gitlab-rake gitlab:backup:create CRON=1" > /etc/cron.d/gitlab-backup

The backup archive lands in /var/opt/gitlab/backups. Copy it off the server to a separate location, thueVPS offers snapshot-based backups that you can enable from the control panel, which give you a full disk-level image on top of the application-level backup. Using both is the correct approach. Snapshots handle hardware failure; the Rake backup handles accidental project deletion or a corrupt Git repository.

Also back up the /etc/gitlab/gitlab.rb file. Without it, a restore from a Rake backup fails because the configuration is missing. The easiest way is to include it in your regular external file backup routine:

cp /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/

FAQ

Related articles

• Self-hosted GitLab CE: minimum viable server spec
• Set up LEMP stack Nginx MariaDB PHP 8.3 on Ubuntu 24.04
• Docker networking explained: bridge, host, overlay
• Self-hosting n8n for workflow automation on a VPS