How to Deploy GitLab on a VPS

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

copysudo ufw allow OpenSSH
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable
sudo ufw status verbose

#Install GitLab

Add GitLab's official Community Edition package repository, then install the package with EXTERNAL_URL set to your real domain over https — setting it with the https scheme up front is what triggers GitLab's built-in Let's Encrypt automation during install, so there's no separate certificate step later:

copycurl --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

The package install runs gitlab-ctl reconfigure for you on first install, which brings up PostgreSQL, Redis, Gitaly, Puma, Sidekiq, and NGINX in turn — this is the slow part, expect several minutes on a freshly sized VPS.

Read the initial root password before it's gone. GitLab writes a one-time password to /etc/gitlab/initial_root_password:

copysudo cat /etc/gitlab/initial_root_password

That file is deleted on the first restart after 24 hours have passed since the first reconfigure — read it now, log in, and rotate the password (next section) rather than depending on it surviving.

Pin a version for anything beyond a first test. apt install gitlab-ce without a version pulls the latest release; for a reproducible install, check what's available and pin it:

copyapt-cache policy gitlab-ce
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce=<version>

#HTTPS + domain

Create an A record for gitlab.example.com pointing at the server's public IP before running the install above — GitLab's Let's Encrypt automation needs to answer an HTTP-01 challenge on port 80 during gitlab-ctl reconfigure, and that fails silently if DNS hasn't propagated yet.

Because EXTERNAL_URL was set with https://, Let's Encrypt is already live: GitLab checked out a certificate during install and renews it automatically (around the 4th of each month, well before the 90-day expiry). To add a contact email for renewal notices, edit /etc/gitlab/gitlab.rb:

copyletsencrypt['contact_emails'] = ['you@example.com']

Then apply it:

copysudo gitlab-ctl reconfigure

If you'd rather bring your own certificate (an internal CA, or a wildcard you already manage) instead of GitLab's built-in Let's Encrypt, set letsencrypt['enable'] = false and point nginx['ssl_certificate'] / nginx['ssl_certificate_key'] at your files in the same block, then reconfigure.

#First login and hardening

Load https://gitlab.example.com and sign in as root with the password from /etc/gitlab/initial_root_password. Do these immediately, in order:

1. Rotate the root password under User Settings → Password. The initial one lived in a plaintext file on the server; treat it as burned.
2. Turn on two-factor auth for the root account under User Settings → Account, and require it instance-wide later under Admin Area → Settings → General → Sign-up restrictions.
3. Disable public sign-up. Admin Area → Settings → General → Sign-up restrictions → turn off "Sign-up enabled". An internet-facing GitLab with open registration collects spam accounts fast. To set it from config instead, add to gitlab.rb:

   copygitlab_rails['gitlab_signup_enabled'] = false

   and sudo gitlab-ctl reconfigure.
4. Set the default project visibility to private under Admin Area → Settings → Visibility and access controls, unless you're deliberately running a public forge.
5. Configure SMTP (Admin Area → Settings, or gitlab_rails['smtp_*'] in gitlab.rb) if you skipped Postfix earlier — password resets and CI notifications depend on outbound mail working.

#Backups

Omnibus ships its own backup command, which produces a single consistent archive of the application data:

copysudo gitlab-backup create

That lands in /var/opt/gitlab/backups by default (configurable via gitlab_rails['backup_path'] in gitlab.rb) as <timestamp>_<version>_gitlab_backup.tar.

The backup command deliberately excludes secrets. Back these up separately, and store them somewhere other than next to the data backup — they're the decryption keys for it:

copysudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /path/to/off-box-backup/

Ship the tarball and the two config files off the VPS on a schedule — object storage, another machine, anywhere the server dying doesn't take them too. Restore it once into a throwaway instance so you find out now that the backup is complete, not during an outage:

copysudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
sudo gitlab-backup restore BACKUP=<timestamp_and_version_from_filename>
sudo gitlab-ctl start
sudo gitlab-rake gitlab:check SANITIZE=true

(BACKUP= takes just the ID prefix of the filename — drop the trailing _gitlab_backup.tar.)

#Upgrades

Take a backup first (previous section) — GitLab's database migrations are one-way. Then upgrade the package like any other:

copysudo apt update
sudo apt install gitlab-ce

The package's post-install hook runs gitlab-ctl reconfigure and any pending migrations automatically. GitLab enforces upgrade paths across major versions — jumping too many minor/major releases at once can skip a required intermediate step, so check the official upgrade path guidance for your current version before a big jump rather than assuming any newer package installs cleanly on top of an old one.

#Troubleshooting

The site 502s right after install. First boot is slow — Puma, Sidekiq, and Gitaly are still coming up behind gitlab-ctl reconfigure. Check sudo gitlab-ctl status and give it a few more minutes before assuming something is broken.

gitlab-ctl reconfigure fails partway through. Re-run it — Chef (the tool reconfigure runs on) is idempotent, so a second run usually finishes past whatever failed. If it keeps failing, read the tail of the output it prints; it names the exact resource that errored.

Let's Encrypt didn't issue a certificate. Confirm the domain's A record resolves to the server before reconfiguring, and that ports 80/443 are open in ufw — the HTTP-01 challenge needs both. Re-run sudo gitlab-ctl reconfigure once DNS is correct.

/etc/gitlab/initial_root_password is gone and you never logged in. It's deleted on the first restart after 24 hours have passed since the first reconfigure. Reset the root password directly instead:

copysudo gitlab-rake "gitlab:password:reset[root]"

Notification emails never arrive. SMTP isn't configured. Check gitlab_rails['smtp_enable'] and the related settings in gitlab.rb, or finish the Postfix prompt from the dependency install.

#Verification + next steps

You're done when you can: load https://gitlab.example.com with a valid certificate, sign in with the rotated root password and 2FA on, confirm sign-up is disabled in a private window, push and pull a test repository over both HTTPS and SSH, and produce a gitlab-backup create archive you have restored at least once into a throwaway instance.

From there, the natural next steps are registering a GitLab Runner for CI/CD, enabling the container registry for your own images, and deciding default project visibility for anything you add later. If you're weighing GitLab against a lighter forge before committing a 16 GB box to it, the GitLab vs Gitea comparison covers the trade-off. For the ranked host picks that actually clear GitLab's footprint, see Best VPS for GitLab.