If you’re looking for a web app or service to assist with keeping track of all your source code, then Gitlab is definitely something you should consider. Gitlab is more than just a front-end to Git, it actually contains quite a few features to empower software development. In this video, Jay will walk you through setting up your very own Gitlab server with Ubuntu on Linode.

Thanks to Linode for sponsoring today’s video. Check them out and get set up with $100 in credit toward your new account!

Setting up Gitlab Community Edition on Linode

One of my favorite ways to Learn Linux is to work on actual projects, which gives you hands-on experience. And there’s no better way to get hands-on experience than building something that you might actually use!

So in this video/article, I’m going to walk you through building a self-hosted Gitlab instance on Linode.

Gitlab is something I’ve been using behind the scenes for my infrastructure here at LearnLinuxTV for several years now, and it’s worked out quite well for me. Gitlab is a version control system based on git, not unlike Github. But it’s also more than just a front-end to Git, since Gitlab has many additional features around developer collaboration, software delivery, and much more.

And if you didn’t already know, Gitlab is actually what the GNOME project uses for their project. How cool is that!

What do you need in order to follow along?

At this point, I should probably go over what in particular you’ll need in order to get started.

The first thing you’ll need is a Linux instance. In the video, I’ll show you the process of sitting up Gitlab on Ubuntu 22.04, so if you plan on following along – then I recommend you set up a Linux instance with Ubuntu 22.04 as well. Of course, Gitlab itself doesn’t require Gitlab, but I can’t show you the process on every Linux distro (that would be crazy!)

If you don’t already have a Linux instance for this project, then you might want to consider checking out Linode, who is sponsoring this video. The instructions I’m going to give you aren’t specific to Linode though, if you’re already set up with another cloud provider, you can go ahead and use that. In fact, you can even set up Gitlab on a physical Linux server as well – but if you do, you’ll have to configure port forwarding which unfortunately is outside the scope of this video. I mean, there’s only a zillion different variations of router/firewall firmware out there.

More specifically, it’s recommended that you have a Linux server with access to at least 4 CPU cores, and at least 4GB of memory. In the video, I set up a Linux server on Linode with an instance type that has 4 CPU cores and 8GB of RAM. Having 8GB of RAM is actually double the recommended RAM requirement, but this instance type also has 160GB of storage – so I think it’s a great fit since you have not only a lot of headroom, you also have a fair amount of storage to use for your software repositories!

Also, you’ll need a domain as well. If you don’t already have one, then you’ll need to purchase one from your registrar of choice. If you don’t have a preferred registrar, then I highly recommend Hover. Hover is not a sponsor of this channel, but I mention Hover because it’s the service I use when it comes to purchasing domains. Their domain prices are a few dollars more than other providers, but the tradeoff is that they have fantastic customer service and they attempt to upsell you less than other providers. But all in all, it doesn’t really matter where you get your domain from as long as you have one. Be sure to point your domain to the IP address of the Linux instance you plan on using for Gitlab.

After you create your cloud instance, there’s one last step before you get started with building Gitlab. You’ll want to be sure to install all available updates, create a non-root user for yourself, and lock down SSH. I’m not going to show you how to perform those tasks in this video, because I have a dedicated video that goes over all of that. If you haven’t already updated your server and created a non-root user (at least) then I recommend you do that before we get started.

Once you have all of those things prepared, we can get started with building our Gitlab instance, which is exactly what we’ll be doing in the next section.

Installing the Gitlab Repository for Ubuntu

The first thing I’m going to do is install the official repository for Gitlab. This will give us access to the community edition of Gitlab, straight from Gitlab themselves.

To install the repository, we’ll run following command:

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

Before you run that command though, I always recommend you check scripts that are fetched from the Internet before running them. It’s always a good security practice to verify things like this. I’ve already done that before producing this video, but definitely be sure to download this script and inspect it first in case anything changes in the future.

Installing and Configuring Gitlab CE

Now that we have the repository installed, let’s install Gitlab itself. To do that, we’ll run the following command:

sudo apt install gitlab-ce

At this point, Gitlab is installed, but it’s not actually set up yet and it’s not going to be accessible until we configure it.

Before we do, we’ll want to make sure we can access our server from its domain. Sometimes, DNS propagation takes a while, so if you’ve just now pointed your domain to your Gitlab server, then it may take a bit until the server is accessible from that domain.

As long as you can access the server via its domain, we can go ahead and continue with configuring our Gitlab instance.

And to do that, we’ll edit the following file:

sudo nano /etc/gitlab/gitlab.rb

That’s the main configuration file for Gitlab. To configure Gitlab, you basically edit the settings within that file and then run a reconfigure command to make sure the settings take effect, which we’ll shortly.

What we’ll do right now do is change one line of configuration in this file, and the rest can remain at their defaults.

The line in particular that we’ll change is this one:

external_url 'http://gitlab.example.com'

As you can probably guess, you’ll change that line to match whatever domain or subdomain you’ve chosen for your server..

To make the change we’ve just made take effect, we’ll run the following command to force Gitlab to reconfigure itself:

sudo gitblab-ctl reconfigure

This might take a little while to finish, so just give it some time…

Once that’s done, we should actually be able to reach our Gitlab instance via its domain at this point, and a default root password should’ve been generated for us.

To retrieve said password, we’ll just grab it from our instance. And it’s important that we retrieve this password as soon as possible, because this file will actually delete itself within 24 hours. You can use the following command to reveal the password:

cat /etc/gitlab/initial_root_password

With our initial root password, we should be able to access our instance. In a web browser, you can log in to Gitlab with username root, and the password is the one you’ve retrieved during the previous step.

Technically, everything is all set now – but I recommend that you continue and set up a TLS certificate with Let’s Encrypt.

Securing your Gitlab instance with a Certificate

There’s no certificate for our server, so it’s not a secure installation. Let’s fix that.

Back on the terminal, let’s open up the configuration file for Gitlab again:

sudo nano /etc/gitlab/gitlab.rb

The first change we’ll make is to alter the URL to include https, rather than http. You’ll make that change on the same external_url line we edited earlier.

After that, search the file for letsencrypt, and that should take us right to a specific section that allows us to configure that.

First, we’ll enable letsencrypt:

letsencrypt['enable'] = true

Next, we’ll add an e-mail address on the next line, whichever one we want to have letsencrypt notifications sent to:

letsencrypt['contact_emails'] = ['your_email_address_here']

We’ll also make sure auto renew is enabled:

letsencrypt['auto_renew'] = true

That should be all you have to do as far as editing the config file. But the changes won’t be applied until we reconfigure Gitlab again:

sudo gitblab-ctl reconfigure

At this point, we’re all set! Our Gitlab server is all set and ready to go, and I hope you enjoy using it!