I’ve never liked hosting my git repos on someone else’s servers. GitHub especially is not a company I’d do business with, ever. I do have a repo or two hosted over at GitLab because those are projects I want to be easily available to anyone. But I store almost everything in git — notes, my whole documents folder, all my code projects, all my writing, pretty much everything is in git — but I like to keep all that private and on my own server.

For years I used Gitlist because it was clean, simple, and did 95 percent of what I needed in a web-based interface for my repos. But Gitlist is abandonware at this point and broken if you’re using PHP 7.2. There are few forks that patch it, but it’s copyrighted to the original dev and I don’t want to depend on illegitimate forks for something so critical to my workflow. Then there’s self-hosted Gitlab, which I like, but the system requirements are ridiculous.

Some searching eventually led me to Gitea, which is lightweight, written in Go and has everything I need.

Here’s a quick guide to getting Gitea up and running on your Ubuntu 18.04 — or similar — VPS.

Set up Gitea

The first thing we’re going to do is isolate Gitea from the rest of our server, running it under a different user seems to be the standard practice. Installing Gitea via the Arch User Repository will create a git user, so that’s what I used on Ubuntu 18.04 as well.

Here’s a shell command to create a user named git:

sudo adduser --system --shell /bin/bash --group --disabled-password --home /home/git git

This is pretty much a standard adduser command such as you’d use when setting up a new VPS, the only difference is that we’ve added the --disable-password flag so you can’t actually log in with it. While we will use this user to authenticate over SSH, we’ll do so with a key, not a password.

Now we need to grab the latest Gitea binary. At the time of writing that’s version 1.5.2, but be sure to check the Gitea downloads page for the latest version and adjust the commands below to work with that version number. Let’s download the Gitea binary and then we’ll verify the signing key. Verifying keys is very important when working with binaries since you can’t see the code behind them¹.

wget -O gitea https://dl.gitea.io/gitea/1.5.2/gitea-1.5.2-linux-amd64
gpg --keyserver pgp.mit.edu --recv 0x2D9AE806EC1592E2
wget https://dl.gitea.io/gitea/1.5.2/gitea-1.5.2-linux-amd64.asc
gpg --verify gitea-1.5.2-linux-amd64.asc gitea

A couple of notes here, GPG should say the keys match, but then it should also warn that “this key is not certified with a trusted signature!” That means, essentially, that this binary could have been signed by anybody. All we know for sure is that wasn’t tampered with in transit¹.

Now let’s make the binary executable and test it to make sure it’s working:

chmod +x gitea
./gitea web

You can stop Gitea with Ctrl+C. Let’s move the binary to a more traditional location:

sudo cp gitea /usr/local/bin/gitea

The next thing we’re going to do is create all the directories we need.

sudo mkdir -p /var/lib/gitea/{custom,data,indexers,public,log}
sudo chown git:git /var/lib/gitea/{data,indexers,log}
sudo chmod 750 /var/lib/gitea/{data,indexers,log}
sudo mkdir /etc/gitea
sudo chown root:git /etc/gitea
sudo chmod 770 /etc/gitea

That last line should make you nervous, that’s too permissive for a public directory, but don’t worry, as soon as we’re done setting up Gitea we’ll change the permissions on that directory and the config file inside it.

Before we do that though let’s create a systemd service file to start and stop Gitea. The Gitea project has a service file that will work well for our purposes, so let’s grab it, make a couple changes and then we’ll add it to our system:

wget https://raw.githubusercontent.com/go-gitea/gitea/master/contrib/systemd/gitea.service 

Now open that file and uncomment the line After=postgresql.service so that Gitea starts after postgresql is running. The resulting config file should look like this:

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
#After=mysqld.service
After=postgresql.service
#After=memcached.service
#After=redis.service

[Service]
# Modify these two values and uncomment them if you have
# repos with lots of files and get an HTTP error 500 because
# of that
###
#LimitMEMLOCK=infinity
#LimitNOFILE=65535
RestartSec=2s
Type=simple
User=git
Group=git
WorkingDirectory=/var/lib/gitea/
ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini
Restart=always
Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea
# If you want to bind Gitea to a port below 1024 uncomment
# the two values below
###
#CapabilityBoundingSet=CAP_NET_BIND_SERVICE
#AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target

Now we need to move the service file to somewhere systemd expects it and then start and enable the service so Gitea will launch automatically when the server boots.

sudo cp gitea.service /etc/systemd/system/
sudo systemctl enable gitea
sudo systemctl start gitea

There you have it, Gitea is installed, running and will automatically start whenever we restart the server. Now we need to set up Postgresql and then Nginx to serve up our Gitea site to the world. Or at least to us.

Setup a Postgresql and Nginx

Gitea needs a database to store all our data in; I use PostgreSQL. You can also use MySQL, but you’re on your own there. Install PostgreSQL if you haven’t already:

sudo apt install postgresql

Now let’s create a new user and database for Gitea:

sudo su postgres
createuser gitea
createdb gitea -O gitea

Exit the postgres user shell by hitting Ctrl+D.

Now let’s set up Nginx to serve our Gitea site.

sudo apt update
sudo apt install nginx

For the next part you’ll need a domain name. I use a subdomain, git.mydomain.com, but for simplicity sake I’ll refer to mydomain.com for the rest of this tutorial. Replace mydomain.com in all the instructions below with your actual domain name.

We need to create a config file for our domain. By default Nginx will look for config files in /etc/nginx/sites-enabled/, so the config file we’ll create is:

nano /etc/nginx/sites-enabled/mydomain.com.conf

Here’s what that file looks like:

server {
    listen 80;
    listen [::]:80;
    server_name <mydomain.com>;


    location / {
        proxy_pass http://localhost:3000;
    }

    proxy_set_header X-Real-IP $remote_addr;
}

The main line here is the proxy_pass bit, which takes all requests and sends it to gitea, which is listening on localhost:3000 by default. You can change that if you have something else that conflicts with it, but you’ll need to change it here and in the service file that we used to start Gitea.

The last step is to add an SSL cert to our site so we can clone over https (and SSH if you keep reading). I have another tutorial on setting up Certbot for Nginx on Ubuntu. You can use that to get Certbot installed and auto-renewing certs. Then all you need to do is run:

sudo certbot --nginx

Select your Gitea domain, follow the prompts and when you’re done you’ll be ready to set up Gitea.

Setting up Gitea

Point your browser to https://mydomain.com/install and go through the Gitea setup process. That screen looks like this, and you can use these values, except for the domain name (and be sure to enter the password you used when we created the gitea user for postgresql).

One note, if you intend your Gitea instance to be for you alone, I strongly recommend you check the “disable self registration” box, which will stop anyone else from being able to sign up. But, turning off registration means you’ll need to create an administrator account at the bottom of the page.

Okay, now that we’ve got Gitea initialized it’s time to go back and change the permissions on those directories that we set up earlier.

sudo chmod 750 /etc/gitea
sudo chmod 644 /etc/gitea/app.ini

Now you’re ready to create your first repo in Gitea. Click the little button next to the repositories menu on the right side of your Gitea dashboard and that’ll walk you through creating your first repo. Once that’s done you can clone that repo with:

git clone https://mydomain.com/giteausername/reponame.git

Now if you have an existing repo that you want to push to your new Gitea repo, just edit the .git/config files to make your Gitea repo the new url, e.g.:

[remote "origin"]
    url = https://mydomain.com/giteausername/reponame.git
    fetch = +refs/heads/*:refs/remotes/origin/*

Now do this:

git push origin master 

Setting up SSH

Working with git over https is pretty good, but I prefer the more secure method of SSH with a key. To get that working we’ll need to add our SSH key to Gitea. That means you’ll need a GPG key. If you don’t have one already, open the terminal on your local machine and issue this command:

ssh-keygen -o -a 100 -t ed25519

That will create a key named id_ed25519 in the directory .ssh/. If you want to know where that command comes from, read this article.

Now we need to add that key to Gitea. First open the file .ssh/id_ed25519.pub and copy the contents to your clipboard. Now in the Gitea web interface, click on the user menu at the upper right and select “settings”. Then across the top you’ll see a bunch of tabs. Click the one that reads “SSH / GPG Keys”. Click the add key button, give your key a name and paste in the contents of the key.

Note: depending on how your VPS was set up, you may need to add the git user to your sshd config. Open /etc/ssh/sshd_config and look for a line that reads something like this:

AllowUsers myuser myotheruser git

Add git to the list of allowed users so you’ll be able to authenticate with the git user over ssh. Now test SSH cloning with this line, substituting your SSH clone url:

git clone ssh://git@mydomain/giteausername/reponame.git

Assuming that works then you’re all set, Gitea is working and you can create all the repos you need. If you have any problems you can drop a comment in the form below and I’ll do my best to help you out.

If you want to add some other niceties, the Gitea docs have a good guide to setting up Fail2Ban for Gitea and then there’s a whole section on backing up Gitea that’s well worth a read.