Today we’re talking about something I think a lot of people skip until much later than they should, and that’s building a proper repository server inside their lab.
A lot of people start a homelab by spinning up VMs, installing services, testing containers, learning networking, and just building as they go. Nothing wrong with that. That’s how most of us start. But eventually the environment grows. Now you have scripts on one server, configs on another machine, notes in random places, and changes being made with no real tracking.
That’s usually the point where people realize they need structure. For me, that’s where GitLab comes in. GitLab is often viewed as something only developers or companies need, but I think that misses the bigger picture. In a homelab, GitLab can become the central control center for your environment. It can hold your code, infrastructure files, Docker stacks, automation scripts, documentation, and eventually the pipelines that deploy everything for you. That’s why I wanted to build it properly and understand it from the ground up.
The Why Behind the Build
At the core of it, GitLab is a platform built around Git. If you already understand Git, then you know Git tracks file changes over time. It lets you commit versions of your work, roll back changes, branch ideas, and keep history. We already talked about Git in our "Git Foundations for a CI/CD Lab" blog.
GitLab builds on top of that. It gives you a central place where repositories live, where people collaborate, where code gets reviewed, where pipelines run, and where deployments can be automated. It connects the development side to the operations side.
That’s why it matters. This is not just a place to store files. This can become the source of truth for your environment.
Why This Matters in a Homelab
Let’s be honest. Most homelabs eventually become more than a lab. They turn into real environments that manage our life. Now you’re hosting services. Running dashboards. Managing reverse proxies. Using Docker. Testing automation. Building websites. Running backups. Learning infrastructure as code.
Once that happens, random management stops working. You need a clean way to track changes and organize how things are built. That’s where GitLab becomes powerful.
Instead of manually logging into servers and editing files directly, you make changes locally, commit them, push them to GitLab, and now every change has history. You know what changed. You know when it changed. You know who changed it (Mostly just you...lol). And later, you can automate what happens next. That’s the real shift.
How the Workflow Starts to Change
Before using a platform like GitLab, many people manage environments by memory.
- They SSH into a server.
- They edit something.
- They forget what they changed two weeks later.
- They break something trying to fix something else.
We’ve all been there. With GitLab, the workflow becomes intentional. You make your change locally. You test it. You push it to your repository. If needed, you review it through a merge request. Then pipelines can validate it or deploy it. Now your environment becomes cleaner, safer, and easier to scale.
I know to most people this may seem unnecessary, but this is how many real production environments are built. Taking the time to set up your environment the same way is a recipe for growth.
Why I Prefer Self-Hosting It
You can absolutely use GitLab as a hosted service, and for many people that makes sense. But in a lab environment, self-hosting teaches you more. Now you’re learning how to size the server, secure access, manage updates, handle backups, think about DNS, and integrate it into your infrastructure.
That experience matters. I also like the idea of important services having a proper home in the environment instead of living somewhere external when they don’t have to.
Why I Used a Dedicated VM
Yes, GitLab can run in containers. But for something this important, I prefer giving it dedicated resources. If your repositories live there, your pipelines live there, your documentation lives there, and your automation depends on it, then this is no longer just another app. This becomes core infrastructure. That means it deserves proper CPU, memory, storage, and backups.
One of the cleanest ways to install GitLab on Linux is using the Omnibus package. This is helpful because it bundles the major components GitLab needs into one install process. Instead of manually assembling databases, web services, and dependencies one by one, you let the package handle much of the heavy lifting. That makes it a strong option for people who want to learn GitLab without turning installation into its own side project.
Things to Think About Before Installing
Before you begin, think through a few basics.
- First, make sure the server has enough resources. GitLab is more demanding than many smaller self-hosted apps.
- Second, decide how users will connect. If you plan to clone repositories using SSH, make sure SSH is enabled.
- Third, think about naming. Using a hostname or internal domain is usually cleaner than relying only on IP addresses.
- Finally, think about security. If you already have internal certificates or a reverse proxy, HTTPS is the better long-term route. If not, HTTP can still be acceptable while you’re learning and building.
Understanding How GitLab Organizes Things
Once installed, one of the most important concepts to understand is how GitLab is structured. Groups are used for organization. Think of them like departments or folders. Inside groups, you place projects. Projects are the actual repositories where your work lives.
So you might have one top-level group for your homelab. Inside that, maybe another group for infrastructure and another for services. Then inside those groups, your projects might be things like Docker stacks, monitoring configs, Terraform files, or automation playbooks. Once you understand this structure, GitLab starts making a lot more sense.
Why This Gets Powerful Later
At first, GitLab may feel like just a cleaner way to store repositories. But the real value shows up later. That’s when pipelines start running automatically. That’s when updates can deploy after a push. That’s when configs get validated before changes go live. That’s when your environment starts behaving like a real engineered platform instead of a collection of manually managed machines. That’s why I think learning this early is worth it.
Command Reference Guide
Update the Server
- sudo apt update && sudo apt upgrade -y
Install curl (this should already be installed, but if not, make sure to install it).
- sudo apt install curl -y
Add GitLab Repository
- curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
Install GitLab Using IP Address
- sudo EXTERNAL_URL="http://YOUR_SERVER_IP" apt install gitlab-ee -y
Install GitLab Using Hostname
- sudo EXTERNAL_URL="http://gitlab.yourdomain.local" apt install gitlab-ee -y
Install GitLab Using HTTPS
- sudo EXTERNAL_URL="https://gitlab.yourdomain.com" apt install gitlab-ee -y
Install GitLab Using HTTP
- sudo EXTERNAL_URL="http://gitlab.yourdomain.com" apt install gitlab-ee -y
Get Temporary Root Password
- sudo cat /etc/gitlab/initial_root_password
The main configuration file lives in /etc/gitlab/gitlab.rb, and this is where you make most of your changes such as the external URL, email settings, SSL configuration, and other core options. Any time you update the main config file, you’ll want to reconfigure GitLab so the changes are applied, then restart the services and check status to make sure everything is healthy.
- nano /etc/gitlab/gitlab.rb
- gitlab-ctl reconfigure
- gitlab-ctl restart
- gitlab-ctl status
Final Thoughts
If you’re building a serious homelab, learning DevOps, or looking to better organize how you manage infrastructure, GitLab is one of the smartest upgrades you can make. Not just because it stores code, but because it brings structure and order to your workflow. And once automation enters the picture, everything changes.
This first phase is all about getting GitLab installed and understanding the overall layout. The next phase is where things really get interesting. That’s where we’ll connect our servers, configure runners, build pipelines, and put GitLab to work for us. We’ll cover all of that in the next video of this series. As always, stay curious. Keep building.
