Self-Host GitLab CE on Ubuntu VPS in Vietnam

You have a team of five, code in three repositories, and you are tired of paying per-seat pricing to a SaaS Git host. Self-hosting GitLab Community Edition on an Ubuntu VPS in Vietnam gives you unlimited private repositories, a built-in CI/CD runner for your own hardware, and full control over your data. This guide walks through the complete setup on Ubuntu 24.04 LTS, from VPS sizing to the first `git push` over HTTPS.

Prerequisites

Before you start, make sure you have the following:

• An Ubuntu 24.04 LTS VPS with at least 4 GB of RAM and 2 vCPUs. GitLab is memory-hungry; 2 GB works for a single user but starts swapping with two active users.
• A domain name (for example, git.yourcompany.com) with an A record pointing to the server's IPv4 address.
• Root or sudo access to the server.
• A basic understanding of the command line.

If you are renting locally, a Linux VPS with a dedicated IPv4 in Vietnam keeps latency low for teams inside the country. For a small team, the 4 GB VNx2 plan is a reasonable starting point. GitLab itself does not care where the server lives, but your developers will notice the difference between 10 ms and 150 ms round trips on every `git fetch`.

Why self-host GitLab instead of paying per seat

Every time a SaaS Git host raises its price, a sysadmin somewhere does the math. GitLab CE is free, and the only real cost is the VPS and your time. For a team of ten, the break-even point is fast: most SaaS plans charge per user per month, and the cost compounds as the team grows.

Self-hosting also means your source code never leaves your infrastructure. For Vietnamese companies working under Decree 53/2022/ND-CP, data localization matters. Storing repositories on a GitLab VPS inside Vietnam keeps the code within national borders. You also get unlimited private repositories, no user limits, and a built-in CI/CD runner that uses your own CPU instead of shared cloud minutes.

The trade-off is operational: you own the upgrades, backups, and security patches. GitLab releases a new version monthly, and you need to run apt upgrade on schedule. If that sounds manageable, read on.

Step 1 - Sizing the VPS and swapping correctly

GitLab CE is a Rails application that wants memory. A fresh install with Prometheus and the bundled PostgreSQL sits at around 2.5 GB of RAM after boot with no traffic. The official documentation lists 4 GB as the minimum for a "small team", and that matches real-world usage.

Before installing anything, make sure swap is enabled. On a 4 GB VPS, a 2 GB swapfile saves you from random OOM kills when the garbage collector runs:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
sudo sysctl vm.swappiness=10

The vm.swappiness=10 line tells the kernel to prefer RAM over swap, which matters on a VPS where swap lives on the NVMe disk. Add it to /etc/sysctl.conf so it survives a reboot.

Verify the swap is active:

free -h

You should see a Swap line with 2.0Gi in the total column.

Step 2 - Installing GitLab CE with apt

GitLab provides a native apt repository for Ubuntu. Install the dependencies and add the repository:

sudo apt update
sudo apt install -y curl ca-certificates tzdata perl
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

The script adds GitLab's signing key and repository to /etc/apt/sources.list.d/gitlab_gitlab-ce.list. Now install the package itself. You set the external URL during install so GitLab generates the correct Nginx configuration:

sudo EXTERNAL_URL="https://git.yourcompany.com" apt install gitlab-ce

Substitute your actual domain. The install runs Omnibus configuration, which bundles Nginx, PostgreSQL, Redis, and Puma into a single package. The whole process takes several minutes, and the package downloads around 800 MB, so use a server with decent bandwidth.

When the install finishes, GitLab automatically runs gitlab-ctl reconfigure. Verify the service is up:

sudo gitlab-ctl status

You should see run next to nginx, postgresql, redis, and puma. If anything shows down, check the logs:

sudo gitlab-ctl tail

Step 3 - Setting the initial root password and first login

The first time you visit https://git.yourcompany.com, GitLab shows a password setup page. If it does not, the initial password was randomly generated and stored on disk:

sudo cat /etc/gitlab/initial_root_password

Log in with username root and the password from that file. GitLab forces you to change it on first login. Create a normal user for yourself right away, and give it the admin role only if you need it.

Change the password for the root account even if the setup page did not ask:

sudo gitlab-rails runner "user = User.find_by(username: 'root'); user.password = 'YourStrongPassword'; user.password_confirmation = 'YourStrongPassword'; user.save!"

Step 4 - Configuring HTTPS with Let's Encrypt

GitLab Omnibus can request a Let's Encrypt certificate automatically, but it only works when port 80 is reachable. Update the external URL and enable the built-in certificate management in /etc/gitlab/gitlab.rb:

sudo nano /etc/gitlab/gitlab.rb

Find these lines and edit them:

external_url 'https://git.yourcompany.com'
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['[email protected]']

Apply the configuration:

sudo gitlab-ctl reconfigure

GitLab requests the certificate from Let's Encrypt and sets up automatic renewal. Verify the certificate is valid:

curl -I https://git.yourcompany.com

The response should include HTTP/2 302 and a location header pointing to the login page. If your domain already has a commercial certificate, you can install it manually. Services like GoGetSSL certificates work fine with Omnibus; just place the files under /etc/gitlab/ssl/ and set nginx['ssl_certificate'] to the path.

Step 5 - Configuring the firewall for GitLab

GitLab only needs port 22 for SSH and port 443 for HTTPS. On Ubuntu, ufw is the simplest option:

sudo ufw allow OpenSSH
sudo ufw allow 443/tcp
sudo ufw enable

Note that GitLab runs its own SSH server on port 22. If you changed the system SSH port for security, you need to tell GitLab to use a different port for Git operations, otherwise users cannot push over SSH. If you keep port 22 for GitLab, consider disabling password auth on the system SSH and moving GitLab SSH to port 2222:

# in /etc/gitlab/gitlab.rb
gitlab_rails['gitlab_shell_ssh_port'] = 2222

sudo gitlab-ctl reconfigure

For more details on locking down access, read the guide on hardening SSH on a new VPS. The same principles apply here, with the extra caveat that GitLab owns port 22.

Step 6 - Creating your first project and pushing code

Create a new project from the GitLab web UI: click the New project button, choose Create blank project, and give it a name. GitLab shows the exact commands to push an existing repository:

cd existing-repo
git remote add origin [email protected]:username/project.git
git push -u origin main

If you are using SSH over port 2222, the command changes slightly:

git remote add origin ssh://[email protected]:2222/username/project.git

Verify the push works and that the repository appears in the UI. Commit a change and confirm the CI/CD pipeline triggers if you have a .gitlab-ci.yml file.

Troubleshooting

Here are the failures you will actually hit:

502 Bad Gateway after reconfigure

Puma failed to start. Check memory first:

free -h

On a 2 GB VPS, this is almost always an out-of-memory kill. Reduce memory usage by disabling Prometheus in /etc/gitlab/gitlab.rb:

prometheus_monitoring['enable'] = false

Then reconfigure. This frees around 500 MB of RAM.

Let's Encrypt validation fails

Port 80 must be reachable from the internet. Check if something else occupies it:

sudo ss -tlnp | grep :80

If Apache is installed, remove it or stop it before re-running the certificate request.

SSH key not working for Git operations

You added the key to GitLab, but the push still asks for a password. Check the SSH port GitLab listens on:

sudo ss -tlnp | grep :22

If the system SSH and GitLab SSH conflict, follow Step 5 and move GitLab to port 2222.

Backups and maintenance

GitLab ships a built-in backup tool. Schedule a nightly backup with cron:

sudo crontab -e

Add this line:

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1

Backups land in /var/opt/gitlab/backups. Move them off the server regularly. A snapshot of the VPS before a major upgrade is the fastest rollback path. Most providers, including thueVPS, offer snapshot functionality from the control panel.

Run upgrades once a month:

sudo apt update
sudo apt install gitlab-ce
sudo gitlab-ctl reconfigure

Read the upgrade notes before major version jumps. GitLab supports upgrading one major version at a time, so jumping from 17.x to 19.x directly will fail.

FAQ

Related articles

• Self-host GitLab CE on a VPS in 2026 step by step
• Configure a GitLab runner for CI/CD on a Linux VPS
• Self-hosted GitLab CE minimum viable server spec
• Deploy CI/CD to a VPS with GitHub Actions and SSH

在越南 VPS 上自建 GitLab，代码存储在国内，访问延迟更低。

Self-hosting GitLab on a Vietnam VPS keeps your code local and reduces latency for local teams.