contact@linuxtpoint.com
Linuxtpoint
Candid photograph of a Linux server terminal with a soft olive-green glow against a dark slate background, conveying a calm technical atmosphere.

Step-by-step guides for system administrators — covering command-line basics, web server setup, and preparation material for technical interviews.

Browse Tutorials

Setting up a GitLab Server on Fedora: a practical walkthrough

Across Australian tech hubs from Sydney to Perth, self-hosted GitLab has become a popular choice for engineering teams who want full control over their source code and CI/CD pipelines. Whether you work for a fintech in Melbourne's Docklands or a research group at a Brisbane university, running your own instance keeps sensitive projects inside the country and removes dependence on overseas SaaS providers. Fedora, with its polished package management and predictable release cadence, makes a clean platform for this kind of deployment.

This walkthrough assumes a freshly provisioned Fedora Server edition with sudo access. You will need a static IP, a fully qualified domain pointing back to your box, and roughly four gigabytes of RAM free. The same steps also apply to RHEL and Rocky Linux derivatives if your hosting provider in Canberra hands you those images instead.

Preparing the Fedora server environment

Before touching any packages, bring the system up to date and confirm the kernel is recent enough for modern container runtimes. Open a terminal and run sudo dnf upgrade --refresh, then reboot if a new kernel lands. Set a meaningful hostname such as gitlab.yourcompany.com.au using hostnamectl set-hostname, and update /etc/hosts so the loopback entry resolves cleanly.

Network access across Australia is generally reliable, but NBN upload speeds at home can become a bottleneck when teammates push large repositories. For production work, point your domain at a VPS in a local region such as Equinix SY3 or NEXTDC S1 rather than hosting from a residential link in Adelaide. Open the firewall ports for SSH, HTTP, and HTTPS with sudo firewall-cmd --permanent --add-service={ssh,http,https} before reloading.

Installing the required dependencies

GitLab bundles most of what it needs, but a few helpers are still expected by the installer. The base set installs with a single command: sudo dnf install -y curl policycoreutils-python-utils openssh-server perl. Make sure SSH is enabled and started straight after with sudo systemctl enable --now sshd.

Postfix is useful for sending notification emails around merge requests and pipeline failures, so install it with sudo dnf install postfix && sudo systemctl enable --now postfix. During the Postfix setup wizard, choose "Internet Site" and enter your domain's FQDN. While planning your hardening pass, it is worth pairing GitLab with fail2ban for SSH so repeated login failures against the web UI are picked up automatically.

Adding the repository and installing the package

Fedora does not ship GitLab in the official repos, so the upstream Omnibus package is the cleanest path. Add the script repository source first with curl -fsSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash. This creates a YUM repo file under /etc/yum.repos.d/ that dnf can read on every system update.

Once the repo exists, install the CE edition with sudo dnf install -y gitlab-ce. The download weighs in at around 700 megabytes, so on a slow NBN connection you may want to schedule it off-peak. If your team is weighing community and enterprise feature lists, the GitLab deployment team has published a useful breakdown of operational trade-offs worth reading first.

Running the initial configuration

Trigger the reconfigurer to write out nginx, postgres, and sidekiq settings: sudo gitlab-ctl reconfigure. This step can take several minutes, particularly on entry-level VPS hardware in Sydney or Melbourne. When it finishes, browse to your domain and set a strong root password on first login.

Edit /etc/gitlab/gitlab.rb to lock the external URL to your real domain and to disable public sign-up if the instance is staff-only. After each edit, run sudo gitlab-ctl reconfigure again to apply the changes. Out of the box, GitLab listens on ports 80 and 443 and will request a Let's Encrypt certificate the moment the external URL is reachable.

Hardening, backups and observability

A self-hosted instance is only as good as the maintenance around it. Schedule nightly backups using sudo gitlab-backup create, and copy the resulting tarballs offsite to an S3-compatible bucket hosted with an Australian provider in a Canberra or Sydney region. Rotate SSH host keys on a yearly cycle and keep SELinux in enforcing mode rather than disabling it on production hosts.

For metrics on repository size, runner queue depth, and Puma worker health, wire GitLab's built-in /-/metrics endpoint into a Prometheus scraper. The setup details match those covered in installing Prometheus, which uses the same exporter pattern. With dashboards in place you will spot runaway jobs before they fill the disk on an AEST-monitored box at three in the morning.

Create a test project, push a commit from your laptop, and confirm a CI pipeline runs end-to-end. A working local instance beats juggling quotas on a hosted plan, and your team across Adelaide, Hobart, or Darwin will appreciate the low-latency clone times that come from keeping repos on-shore.