iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
The simplest dependable way to install GitLab on your own VPS is the official GitLab Community Edition (CE) Linux package on a supported Ubuntu release. Point a DNS name at the server, open SSH and web ports, add GitLab’s package repository, and install gitlab-ce with an EXTERNAL_URL. The package includes PostgreSQL and Nginx, so you do not have to assemble those services yourself.
Size the VPS before running the installer. GitLab’s official single-node production baseline is 8 vCPU and 16 GB of memory for up to 1,000 users or about 20 requests per second. A much smaller configuration can work for a trial, but it will trade speed and reliability for lower cost.
The installation plan
A working deployment has five moving parts:
- A supported Ubuntu VPS with enough CPU, memory and disk.
- A hostname such as
gitlab.example.comwhose DNS record points to the VPS. - SSH, HTTP and HTTPS access through the VPS firewall and any cloud firewall.
- The GitLab CE package repository and its dependencies.
- An external URL that GitLab uses for links, clone URLs and certificate configuration.
The procedure below uses the package installation route. It is the practical default for most self-hosted installations because upgrades are handled through APT and the package configures the bundled services. A source build is possible, but it requires you to manage more dependencies and perform more upgrade work yourself.
Choose a VPS size before you install
GitLab is more demanding than a small static website. Repository storage, background jobs, PostgreSQL, Redis, web workers and the bundled monitoring services all compete for memory. Use the tier that matches your purpose rather than treating the smallest published figure as a production recommendation.
| Use case | Memory and swap | CPU and storage | What to expect |
|---|---|---|---|
| Short trial or personal experiment | 2 GB RAM plus 1 GB swap minimum; 2.5 GB RAM plus 1 GB swap is described as optimal for memory-constrained environments | 20 GB storage; AMD64 with 1 core, or 4 ARM cores | GitLab can start, but swap-dependent operation is slower and unsuitable for a busy team |
| Very small team | At least 8 GB RAM is a practical floor for a lightly used instance | Choose SSD storage and more than the minimum CPU available from your VPS plan; an exact CPU figure is not established for this tier | Works for modest activity when repositories, CI jobs and concurrent users remain limited |
| Official single-node production baseline | 16 GB RAM | 8 vCPU and at least 40 GB for a basic installation; SSD or a 7,200 RPM HDD is recommended | Designed for up to 1,000 users or approximately 20 requests per second, according to GitLab’s requirements guidance |
The 40 GB figure covers a basic installation without repository data. Git repositories, artifacts, package registries, container images, uploads, logs and backups consume additional space, so allocate more than 40 GB when you expect sustained use. The Linux package itself needs about 2.5 GB merely to install.
You may still see older recommendations of 4 GB RAM and four cores for roughly 500 users. Those figures are not a safe production baseline for a current installation. A forum discussion also reports that configurations below four CPUs and 8 GB tend to become problematic. Treat those older numbers as historical anecdotes, not capacity planning guidance.
Why swap is not a substitute for memory
The memory-constrained guide allows a 2 GB system with 1 GB of swap, but that configuration relies on disk-backed memory. It is useful for learning the interface or testing a repository. Under concurrent web requests, background jobs or large Git operations, swapping increases latency and can make the instance appear unresponsive. For a team server, increase RAM instead of trying to hide a shortage with a large swap file.
Prerequisites for self-hosting GitLab on Ubuntu
Operating system and architecture
The current Ubuntu package guidance lists Ubuntu 22.04 and Ubuntu 24.04. Confirm that your exact GitLab package version still supports the release you choose before provisioning, because supported distributions and installation commands change. Use a 64-bit VPS; the memory-constrained guidance specifically describes AMD64 and a separate ARM configuration.
Network identity
Assign a stable public IP address and create an A record such as gitlab.example.com pointing to it. Wait for DNS to resolve from outside the VPS before requesting a certificate. The hostname becomes part of every web link and SSH clone URL, so changing it later requires a deliberate reconfiguration.
Required access
- A user with
sudoaccess. - Inbound TCP 22 for SSH administration and Git-over-SSH.
- Inbound TCP 80 and 443 for the web interface and, when you use GitLab’s certificate automation, HTTP-01 certificate validation.
- Outbound access to Ubuntu mirrors and GitLab’s package repository.
If your provider has both a cloud firewall and an operating-system firewall, permit the ports in both places. The following UFW rules are a starting point:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enableDo not enable a firewall until you have confirmed that your SSH session is permitted, or you can lock yourself out.
Mail prerequisite
The package installation commonly installs postfix along with curl, openssh-server, ca-certificates, perl and tzdata. During the Postfix dialog, select an Internet-facing mail configuration only if the VPS is allowed to send mail directly and you have configured a valid mail hostname. If you plan to relay through an SMTP service, install the package now and configure the relay after GitLab is online.
Install GitLab CE step by step
1. Update Ubuntu and install dependencies
Connect over SSH, update the package index and install the prerequisite packages:
sudo apt update
sudo apt install -y curl openssh-server ca-certificates postfix perl tzdataIf Postfix opens an interactive configuration screen, provide the mail settings appropriate for your environment. You can revisit them later; they do not replace GitLab’s own SMTP configuration.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems2. Add the GitLab CE repository
GitLab publishes a repository setup script for Debian-based systems. Run the official script over HTTPS:
curl -fsSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bashThe script adds the signing configuration and APT source for the Community Edition package. Review the terminal output for repository or distribution errors rather than proceeding after a failed command. The script URL is https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh.
3. Install the package with the external URL
Replace the example hostname with the DNS name that resolves to your VPS:
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ceThe EXTERNAL_URL value is optional in the package installer but strongly recommended. GitLab uses it to generate browser links, repository clone addresses and web callbacks. Using an HTTPS URL also gives the package a clear basis for web-server and certificate configuration.
During installation, the package configures its bundled Nginx and PostgreSQL services. Allow the process to finish; it may take several minutes while database migrations and service checks run. If you need to rerun the configuration phase after correcting a setting, use:
sudo gitlab-ctl reconfigure4. Sign in as the initial administrator
The package creates an initial administrator account named root and writes a temporary password to the generated initial-password file. On current Linux package deployments this is normally:
sudo cat /etc/gitlab/initial_root_passwordUse the password promptly, then change it in the web interface. The file is intended for initial access and may be removed by the package after its retention period. If the file is missing, do not guess the password: check the installation output and your GitLab package documentation, or use the documented administrator password-reset procedure from the server console.
5. Complete the first browser login
- Open
https://gitlab.example.comin a browser. - Sign in with username
rootand the temporary password. - Change the password to a unique value stored in a password manager.
- Review the administrator area before inviting users or importing repositories.
If you installed with an HTTP URL for a private test, use that exact URL initially. For an internet-facing server, plan the HTTPS conversion before adding credentials or source code.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →HTTPS, DNS and the bundled Nginx server
The Linux package includes Nginx. That means a pre-existing Nginx or Apache service may already occupy ports 80 or 443. Check listeners before installation:
sudo ss -tulpn | grep -E ':80|:443'If another service owns those ports, stop it only after confirming what it serves, or configure GitLab to use your existing reverse proxy. Running two web servers that both bind the same port will leave GitLab unable to start.
When you use a domain name and want automated certificate issuance, keep ports 80 and 443 reachable from the public internet during validation. DNS must resolve to the VPS, and any upstream firewall must pass the validation request. If your organization terminates TLS at a separate proxy, configure that proxy and GitLab’s external URL consistently; do not expose the temporary HTTP endpoint longer than necessary.
Verify the installation before inviting users
Check service state
sudo gitlab-ctl statusAll expected GitLab services should report as running. A failed service usually points to a port conflict, insufficient memory, a configuration error or a failed migration.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallRun the built-in health check
sudo gitlab-rake gitlab:checkRead every warning rather than treating a successful web login as proof that repositories, background jobs and storage are healthy.
Test the workflows that matter
- Create a test project and push a small repository over SSH and HTTPS.
- Clone the project from a second machine.
- Upload an issue attachment and confirm that it can be downloaded.
- Trigger a background job, such as a repository import, and watch its completion.
- Send a test notification if you configured SMTP.
Initial administration and maintenance
Protect administrator access
Add your SSH public key to the VPS user account, use a non-root system account for routine administration and restrict SSH exposure at the firewall where practical. In GitLab, review user registration, session settings, personal access token policies and two-factor authentication before opening the server to a wider group.
Plan backups separately from the VPS disk
A VPS snapshot is not the same as an application-consistent GitLab backup. Schedule GitLab’s backup task and copy the resulting files to storage that is independent of the server. Test a restore before you depend on the backup for recovery. Repository data, uploaded files, package artifacts, registry content and configuration secrets may have different backup requirements.
A manual application backup can be started with:
sudo gitlab-backup createProtect the backup location and document how you would restore the database, repositories, encryption secrets and external configuration together.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Keep the package current
Package upgrades arrive through APT. Before upgrading, read the release notes for your installed GitLab version, confirm that the VPS has sufficient free disk space and take a tested backup. Then update the package index and apply the upgrade during a maintenance window:
sudo apt update
sudo apt install gitlab-ceDo not assume that every GitLab release supports every Ubuntu release. Verify the supported combination before a major operating-system or GitLab upgrade.
Best Value
Monitor disk and memory
GitLab’s repositories and artifacts grow independently of the operating system. Check disk usage with df -h, identify large directories with du, and watch memory pressure with free -h. On a 2 GB or 8 GB instance, a sudden increase in CI jobs or repository activity can exhaust memory before CPU reaches 100 percent.
Package installation versus compiling GitLab yourself
| Decision factor | Linux package | Self-compiled installation |
|---|---|---|
| Installation effort | Repository script and one package command; bundled Nginx and PostgreSQL reduce manual setup | Manual dependencies, service configuration and application setup |
| Upgrades | Managed through APT after reviewing release notes | Manual source upgrades, migrations and dependency changes |
| Control | Opinionated layout and bundled components | More control over versions and service topology |
| Best fit | Most VPS owners who want a maintainable CE server | Operators who specifically need a custom build and can maintain it |
GitLab’s self-compiled guide is written for and tested on Debian and Ubuntu, but compiling does not remove the operational responsibilities: you still need a supported database, a web server, background workers, backups, upgrades and monitoring. Unless you have a concrete reason to customize the stack, the package route is less error-prone.
Free tools Windows power users keep installed
One-click scans. No signup required.
Troubleshoot the failures you are most likely to see
APT cannot find gitlab-ce
Inspect the repository-script output and confirm that your Ubuntu release is supported. Run sudo apt update again and look for GPG, DNS or TLS errors. A repository entry for a different distribution can make the package appear unavailable; remove the incorrect entry and rerun the setup procedure for the correct release.
GitLab will not start because port 80 or 443 is busy
Use sudo ss -tulpn | grep -E ':80|:443' to identify the process. Stop or reconfigure the conflicting web server, or place GitLab behind a deliberately configured reverse proxy. Do not repeatedly run reconfigure while the port conflict remains; it will not resolve ownership of the socket.
The server runs out of memory
Check free -h and the service logs, then reduce concurrent workloads or move to a larger VPS. A swap file can keep a trial alive, but it does not deliver the responsiveness of additional RAM. The official production baseline is 16 GB RAM and 8 vCPU; use that as the target when the instance serves a team or automation workload.
The browser shows a certificate or redirect error
Confirm that the DNS A record points to the current IP, the external URL matches the hostname users enter and ports 80/443 are reachable. If you changed EXTERNAL_URL, run sudo gitlab-ctl reconfigure and test in a private browser window to avoid cached redirects.
Recommended Free Tools
The initial password file is absent
Check the package installation output and verify that the package finished successfully. Do not search arbitrary log files for a password or leave the temporary account exposed. Use GitLab’s documented password-reset method from the VPS console, then immediately set a new administrator password.
Email notifications do not arrive
Verify that Postfix or your SMTP relay is configured, that the VPS provider permits outbound mail and that GitLab’s SMTP settings contain the correct host, port, credentials and encryption mode. Test delivery from the administrator settings and inspect the mail and GitLab logs for rejected recipients or authentication failures.
When this VPS approach is appropriate
Self-hosting GitLab makes sense when you need control over data location, network access, user policies or integrations and are prepared to maintain an operating system and application. It is not a one-time install: disk growth, security updates, certificate renewal, backups, monitoring and recovery testing remain your responsibility.
For a personal trial, start with the memory-constrained configuration and expect slow performance. For a small team, treat 8 GB RAM as a lower practical boundary and monitor it closely. For production serving up to 1,000 users or approximately 20 requests per second, provision the official 8-vCPU, 16-GB baseline with more than 40 GB of SSD-backed storage, then scale based on repository, CI and artifact growth.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
