How to Deploy a Self-Hosted GitLab CE Instance on Bare Metal

GitLab Community Edition (CE) is a free, open-source DevOps platform that gives your team its own private Git repository, CI/CD pipelines, issue tracking, and container registry — all under your control. Running GitLab CE on a cloud VM works fine for small teams, but once your repositories grow, pipelines run all day, and multiple developers push code at once, shared cloud resources start to slow things down. That's where a bare metal dedicated server makes a real difference: dedicated CPU cores, dedicated RAM, and dedicated disk I/O mean your CI/CD jobs finish faster and your Git operations stay snappy even under heavy load.

This guide walks you through deploying a production-ready, self-hosted GitLab CE instance on a bare metal server, step by step, from choosing hardware to securing it with SSL.

Why Choose Bare Metal for Self-Hosted GitLab CE?

GitLab is resource-hungry by design. Its background services (Sidekiq, PostgreSQL, Redis, Gitaly, Puma) all compete for CPU and memory, and CI/CD runners can spike usage sharply during builds. On a shared virtual machine, "noisy neighbours" on the same physical host can slow your pipelines without warning. A bare metal dedicated server removes that variable entirely — you get the full server to yourself, which means predictable performance, faster clone/pull speeds for large repositories, and CI/CD runners that finish jobs in a consistent amount of time.

If your workloads include container builds or large binary artifacts, pairing your GitLab instance with a server on a 10Gbps dedicated server connection also cuts down push/pull times noticeably for distributed teams.

Prerequisites

Before you start, make sure you have:

• A bare metal server with at least 4 CPU cores, 8GB RAM (16GB+ recommended for teams), and 80GB+ SSD storage.

• A fresh install of Ubuntu 22.04 LTS (GitLab officially supports this distribution well).

• Root or sudo access via SSH.

• A domain name or subdomain pointed to your server's IP (e.g. git.yourcompany.com).

• Basic familiarity with the Linux command line.

If you haven't provisioned a server yet, eServers offers Linux dedicated servers with Ubuntu pre-installed and same-day deployment, which saves you the OS installation step entirely.

Step 1: Update the Server and Set the Hostname

Connect to your server over SSH and update all packages first:

sudo apt update && sudo apt upgrade -y
                            

Set a proper hostname that matches the domain you'll use for GitLab:

sudo hostnamectl set-hostname git.yourcompany.com
                            

Step 2: Install Required Dependencies

GitLab CE needs a few packages to handle SSH access and outgoing email notifications:

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

During the Postfix setup, choose "Internet Site" and enter your domain name when prompted. This allows GitLab to send email notifications for merge requests, pipeline results, and password resets.

Step 3: Add the GitLab Repository

GitLab maintains an official install script that configures its package repository automatically:

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
                            

This script detects your OS version and sets up the correct APT repository behind the scenes.

Step 4: Install GitLab CE

Now install GitLab CE, setting the EXTERNAL_URL environment variable to your domain so GitLab configures itself with the correct address on first run:

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

The installation can take a few minutes as it sets up PostgreSQL, Redis, Nginx, and the other bundled services.

Step 5: Configure gitlab.rb

GitLab's main configuration file lives at /etc/gitlab/gitlab.rb. Open it with:

sudo nano /etc/gitlab/gitlab.rb
                            

Confirm the external URL is correct:

external_url 'https://git.yourcompany.com'
                            

For a bare metal server with dedicated storage, you can also point GitLab's repository storage to a separate disk or RAID array for better I/O performance — this is one of the practical advantages of running on your own hardware rather than a shared cloud instance.

Step 6: Reconfigure and Start GitLab

Apply the configuration changes:

sudo gitlab-ctl reconfigure
                            

Then start all GitLab services:

sudo gitlab-ctl start
                            

Reconfigure can take a couple of minutes the first time, since it builds and starts every internal service.

Step 7: Set Up the Firewall

Only open the ports GitLab actually needs — SSH, HTTP, and HTTPS:

sudo ufw allow OpenSSH
sudo ufw allow http
sudo ufw allow https
sudo ufw enable
                            

Since a Git server is a common target for brute-force login attempts and credential stuffing, it's worth putting the server behind DDoS protection if your GitLab instance will be internet-facing. This filters volumetric attacks before they ever reach your box, keeping your CI/CD pipelines running even during an attack.

Step 8: Enable HTTPS with Let's Encrypt

GitLab CE has built-in Let's Encrypt support, so you don't need to configure Nginx manually. Edit /etc/gitlab/gitlab.rb again and add:

letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['[email protected]']
                            

Then reconfigure once more:

sudo gitlab-ctl reconfigure
                            

GitLab will automatically request and renew the SSL certificate for your domain going forward.

Step 9: Log In and Retrieve the Root Password

GitLab generates a random password for the initial root account, stored in a temporary file:

sudo cat /etc/gitlab/initial_root_password
                            

Copy this password, visit https://git.yourcompany.com in your browser, log in as root, and change the password immediately from Admin Area > User Settings. This file is automatically deleted after 24 hours for security.

Step 10: Create Your First Project

Once logged in, create a new project or import an existing repository from GitHub, Bitbucket, or another GitLab instance. Add your team members under Admin Area > Users, and set up SSH keys for each developer so they can push and pull without entering a password every time.

Step 11: Back Up Your GitLab Instance

GitLab includes a built-in backup command that archives your repositories, database, and CI/CD artifacts:

sudo gitlab-backup create
                            

Schedule this as a cron job and copy the resulting archive to separate storage — ideally off the same physical server. If you need extra capacity for backup archives or container registry images, eServers' storage dedicated servers provide high-capacity, RAID-protected disk space that pairs well with a GitLab CI/CD setup.

Step 12: Tune for Performance

A few adjustments help GitLab make the most of dedicated hardware:

• Increase Puma workers in gitlab.rb if you have spare CPU cores, so more requests are handled in parallel.

• Move the container registry to its own disk if you're building Docker images frequently in CI/CD.

• Monitor resource usage with sudo gitlab-ctl status and standard tools like htop to spot bottlenecks early.

• Use a control panel such as those available through eServers if you want a simpler way to manage other services running alongside GitLab on the same server.

Wrapping Up

Self-hosting GitLab CE on bare metal gives you full ownership of your source code, predictable CI/CD performance, and none of the "noisy neighbour" slowdown that shared cloud instances can bring. With dedicated CPU, RAM, and disk I/O, your pipelines run consistently even as your team and repositories grow.

If you're ready to deploy your own instance, take a look at eServers' Bare Metal Dedicated Servers — same-day deployment, UK-based data centres, and 24/7 expert support to help if you get stuck along the way.