Setting Up A Personal GitLab Instance On Ubuntu

Running your own GitLab server gives you a private home for source code, issue tracking, merge requests, documentation, and automated builds. Instead of sending every repository to a public service, you can keep personal projects, family records, coursework, or small-business code under your own control.

Ubuntu is a practical base for this project because its Long Term Support releases receive years of security updates and have extensive documentation. GitLab also provides an official package for Ubuntu, allowing you to install the platform as a managed application rather than assembling every component by hand.

A personal GitLab instance can live on a spare mini PC, a virtual machine, or an inexpensive cloud server. Australian users may choose a Sydney or Melbourne data centre for lower latency, while a home installation can work well over a reliable NBN connection if upload speed, power usage, and backup access are considered carefully.

Choose The Right Ubuntu Host

For a new installation, Ubuntu Server 24.04 LTS is a sensible choice. Ubuntu Desktop can also run GitLab, but a server installation uses fewer resources and avoids unnecessary graphical services. A small test instance should have at least 4 GB of RAM, while 8 GB gives GitLab, PostgreSQL, Redis, and background jobs more breathing room.

Storage matters as repositories, package registries, container images, logs, and uploaded files grow. Begin with a fast SSD and at least 40 GB of available space, then monitor usage regularly. A home server connected through an NBN service should ideally use a wired Ethernet connection and a reserved address from the router. If the public IP changes, a dynamic DNS service can keep your hostname reachable.

A cloud virtual machine in Sydney may be easier to expose to the internet than a server behind carrier-grade NAT. Australian residential providers do not all offer a straightforward inbound connection, and some connections may restrict incoming ports. If you host at home, check whether your ISP provides a public IPv4 address and whether port forwarding is permitted before committing to the setup.

Prepare DNS, Firewall, And Email

Choose a hostname such as git.example.com, then create a DNS A record pointing to the server’s public IPv4 address. If your provider supplies IPv6, add an AAAA record only after confirming that the firewall and router handle it correctly. An incorrect IPv6 record can make a service appear randomly unavailable to users whose networks prefer IPv6.

Allow only the services you need. SSH normally uses port 22, HTTP uses port 80 for certificate validation and redirects, and HTTPS uses port 443 for normal access. With Ubuntu’s uncomplicated firewall, the basic rules are:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

GitLab’s bundled web server may use the same ports, so the Nginx profile name is simply a convenient way to permit HTTP and HTTPS traffic. Do not expose PostgreSQL, Redis, or GitLab’s internal services to the public internet.

Email is important for password resets, invitations, notifications, and account verification. Create an SMTP account with a reputable provider rather than attempting to operate a mail server from a residential connection. Australian business users should also check whether their email provider, domain records, and privacy practices suit the organisation’s obligations under local data-handling rules.

Install GitLab With The Official Package

First update Ubuntu and install the packages needed to add GitLab’s repository:

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

Add the official GitLab repository, then install the Community Edition package:

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

Replace the hostname with the address you configured in DNS. The installation process deploys GitLab’s main services, database, web interface, background workers, and repository storage. It can take several minutes on modest hardware, particularly when the package performs its initial configuration.

For general Linux news, desktop guidance, and distribution coverage, Ubuntu Linux coverage can sit alongside the official GitLab documentation in your reference list. The official documentation remains the authority for version-specific settings, while community publications can provide useful context for everyday Ubuntu administration.

After installation, retrieve the temporary administrator password:

sudo cat /etc/gitlab/initial_root_password

The file is normally removed after a limited period, so sign in promptly at https://git.example.com with the username root, change the password, and store the new credentials in a password manager. Never leave the temporary password in shell history, screenshots, notes, or shared chat messages.

Complete The First GitLab Configuration

Open GitLab’s administration area and review the instance settings before inviting anyone. Set a clear instance name, configure the time zone, decide whether new users may register themselves, and restrict sign-ups if the server is for private use. A personal installation should usually disable public registration and create accounts manually.

The GitLab time zone can be set to an Australian location such as Australia/Sydney, although the server itself should generally keep system time in UTC. This avoids confusion in logs and scheduled jobs while presenting dates in a familiar local zone. Remember that daylight saving differs across Australia: New South Wales, Victoria, Tasmania, and the Australian Capital Territory change clocks, while Queensland, Western Australia, and the Northern Territory do not.

Configure outbound email under the administration settings or in /etc/gitlab/gitlab.rb. A typical SMTP configuration includes the provider’s hostname, port, username, password, encryption mode, and a verified sender address. Apply changes with:

sudo gitlab-ctl reconfigure

Test password reset and notification email before relying on the service. If messages fail, inspect GitLab’s logs and check the provider’s authentication requirements. A sender address on your own domain, supported by SPF, DKIM, and DMARC records, is less likely to disappear into spam folders.

Secure Access And User Accounts

GitLab serves its web interface over HTTPS when the external URL uses an HTTPS address. The Omnibus package can request and renew a Let’s Encrypt certificate automatically if the DNS record resolves correctly and port 80 is reachable. Enable the integrated certificate handling in /etc/gitlab/gitlab.rb, then run sudo gitlab-ctl reconfigure. Renewal should be tested before the first certificate period ends.

SSH keys provide a safer and more convenient way to clone and push repositories. On a workstation, create an ed25519 key if you do not already have one:

ssh-keygen -t ed25519 -C "your-email@example.com"

Copy the public key from ~/.ssh/id_ed25519.pub, add it under your GitLab profile’s SSH keys, and test the connection with ssh -T git@git.example.com. Keep the private key protected and use an agent or hardware-backed credential where practical.

Require two-factor authentication for administrator accounts and consider enforcing it for every user. Time-based one-time passwords work well, while a hardware security key offers stronger protection against phishing. Limit administrator access, remove unused accounts quickly, and review personal access tokens because a forgotten token may retain access long after a project has been abandoned.

Organise Projects And Backups

GitLab works best when repositories are organised into groups rather than left as an unstructured collection of personal projects. Create groups for areas such as “Home Lab”, “Websites”, “Study”, or “Client Work”, then apply consistent visibility and access rules. Private projects should remain private by default, particularly when they contain configuration files, infrastructure details, or personal information.

Use a .gitignore file for operating-system clutter, build output, virtual environments, and local secrets. Passwords, API keys, cloud credentials, and private certificates should never be committed. If a secret is accidentally pushed, revoke it immediately; deleting the file in a later commit does not remove it from the repository’s history.

GitLab’s built-in backup command can create an archive of repositories, database content, uploads, and other application data:

sudo gitlab-backup create

The resulting files are commonly stored under /var/opt/gitlab/backups. Copy them to a separate disk, NAS, or encrypted cloud storage location. A backup on the same machine is useful for accidental deletion but does not protect against disk failure, theft, fire, or ransomware.

For a home server in Brisbane, Perth, or regional New South Wales, consider the practical impact of summer heat, power interruptions, and long periods when nobody is present. A small UPS can provide clean shutdown time, while an off-site encrypted copy protects against local incidents. Test restoration on a separate Ubuntu virtual machine instead of assuming that a successful archive automatically means a usable recovery plan.

Maintain Performance And Reliability

GitLab includes several services that can consume memory and processor time. Monitor the machine with free -h, df -h, and htop, and inspect service status with sudo gitlab-ctl status. If the server begins swapping heavily, reduce unnecessary CI workers, add memory, or move runners to a separate machine.

Keep Ubuntu and GitLab updated, but read the release notes before applying major upgrades. A normal package update can be performed with sudo apt update followed by sudo apt upgrade, while GitLab upgrades should follow the supported version path rather than jumping across several major releases. Create a backup before each significant change.

GitLab CI/CD runners are useful for testing code and building packages, but they should not automatically run untrusted jobs on the same host as the GitLab application. A separate runner, disposable virtual machine, or containerised build environment limits the damage caused by malicious or careless build scripts. Treat runner registration tokens and deployment credentials as sensitive secrets.

When researching Linux applications or package formats, use official repositories and project documentation first; third-party pages such as software notes should be treated as supplementary reading rather than a source for packages or credentials. Verify checksums, inspect repository ownership, and avoid scripts that demand root access without explaining what they change.

Connect Your Local Development Workflow

On a workstation, clone a project using its SSH address:

git clone git@git.example.com:group/project.git

Set your author details locally or globally with git config, create a feature branch, commit small logical changes, and push the branch to GitLab. Merge requests then provide a place to review code, discuss decisions, and record why a change was accepted. Even a solo developer benefits from this history when returning to a project months later.

Add a basic CI pipeline in .gitlab-ci.yml to run tests, linting, or a build command. Start with a simple job and a trusted runner, then add caching and deployment stages once the process is reliable. Keep environment variables and production credentials in GitLab’s protected CI/CD variable store, not in the YAML file.

A personal GitLab server does involve ongoing administration: patching, monitoring, backups, certificate renewal, and account control. In return, it offers a flexible private development platform that can grow from a single repository into a complete home lab or small-team service. Begin with one project, confirm that login, SSH, email, HTTPS, and recovery all work, and then expand carefully.

The next concrete step is to create an Ubuntu Server 24.04 LTS virtual machine with 8 GB of RAM, assign it a reserved address, and verify that git.example.com resolves to it before installing GitLab.