Self-hosting Git with Gitea on Civo

To self-host Git or not, that's been a topic of debate as major source code hosting platforms have repeatedly shown signs of unreliability.

And with supply chain attacks happening almost every other week, it's easy to see why more people are looking for alternatives.

In this post, we'll look at Gitea, a lightweight, self-hosted Git service written in Go that happily runs on a small Linux VM. We'll spin one up on Civo, install Gitea on it, and put Caddy in front so we get automatic HTTPS via Let's Encrypt.

Why self-host Gitea?

A few reasons people end up here:

• You own your data and your uptime. When <insert big provider> has a bad day, your team doesn't have to.
• Predictable pricing:  Unlimited private repos, organizations, packages, and Actions runners are all in the box.
• It's lightweight. Gitea is a single Go binary with a SQLite database
• The workflow is familiar. Issues, pull requests, Actions, container and package registries, if you can use GitHub, you can use Gitea on day one.

Prerequisites

This tutorial assumes some familiarity with the Linux command line. You'll also need:

• A Civo account
• The Civo CLI installed and authenticated (civo apikey save <name> <key>)
• An SSH key uploaded to Civo (civo sshkey upload <name> --public-key-path ~/.ssh/id_ed25519.pub)
• A domain name you control, with the ability to add an A record pointing at your VM. If you don't have a domain, we will use nip.io, a free wildcard DNS service, so any IP gets a working hostname that Caddy can fetch a certificate for

Creating a Civo virtual machine

We'll begin by creating a virtual machine using the Civo CLI:

1civo instance create \
2  --hostname=teapot \
3  --size=g4s.medium \
4  --diskimage=ubuntu-jammy \
5  --initialuser=demo \
6  --sshkey=<your-key-name>

Give it a few seconds to provision, then grab the public IP and the initial user's password. The -o custom -f flags let us pull specific fields straight out:

1civo instance show teapot -o custom -f public_ip,initial_password

(If you provisioned with an SSH key, the password field will be empty; that's fine, you'll log in with the key.)

At this point, you should be able to log in to your machine:

1ssh demo@<public-ip>

Civo dashboard showing the teapot instance up and running

Installing Gitea

With our VM up, let's install Gitea. We'll grab the binary directly from the Gitea release page and run it as a dedicated system user.

Update the package cache, upgrade installed packages, and install Git:

1sudo apt update && sudo apt upgrade -y && sudo apt install git -y

Download the Gitea binary and make it executable. We're pinning to 1.26.2 here, check the Gitea downloads page for the latest stable version:

1wget -O gitea https://dl.gitea.com/gitea/1.26.2/gitea-1.26.2-linux-amd64
2chmod +x gitea

Add the git system user that will own the Gitea process:

1sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' \
2  --group --disabled-password --home /home/git git

Create the directories Gitea uses for data, logs, and configuration:

1sudo mkdir -p /var/lib/gitea/{custom,data,log}
2sudo chown -R git:git /var/lib/gitea/
3sudo chmod -R 750 /var/lib/gitea/
4sudo mkdir /etc/gitea
5sudo chown root:git /etc/gitea
6sudo chmod 770 /etc/gitea

Move the binary onto $PATH:

1sudo cp gitea /usr/local/bin/gitea

Running Gitea as a systemd service

Running Gitea manually works for a quick check, but we want it to come back up automatically after reboots. Ubuntu ships with systemd as its init system, so let's go with that.

Write the unit file:

1sudo tee /etc/systemd/system/gitea.service > /dev/null <<'EOF'
2[Unit]
3Description=Gitea (Git with a cup of tea)
4After=syslog.target network.target
5
6[Service]
7RestartSec=2s
8Type=simple
9User=git
10Group=git
11WorkingDirectory=/var/lib/gitea/
12ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini
13Restart=always
14Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea
15# Uncomment the two lines below if you have large repos and hit HTTP 500s:
16#LimitMEMLOCK=infinity
17#LimitNOFILE=65535
18
19[Install]
20WantedBy=multi-user.target
21EOF

Reload systemd so it picks up the new unit, then enable and start Gitea:

1sudo systemctl daemon-reload
2sudo systemctl enable --now gitea.service

Check that it came up cleanly:

1sudo systemctl status gitea

The output should look something like this:

1● gitea.service - Gitea (Git with a cup of tea)
2     Loaded: loaded (/etc/systemd/system/gitea.service; enabled; vendor preset: enabled)
3     Active: active (running) since Sat 2026-05-23 19:20:43 UTC; 13h ago
4   Main PID: 1642 (gitea)
5      Tasks: 12 (limit: 4420)
6     Memory: 92.2M
7        CPU: 1min 47.864s
8     CGroup: /system.slice/gitea.service
9             └─1642 /usr/local/bin/gitea web -c /etc/gitea/app.ini

The two lines to look for are Loaded: ... enabled (it'll come back after a reboot) and Active: active (running) (it's up right now). Gitea is now listening on port 3000.

Completing the install in the browser

Gitea's first run is a one-page web installer. Open http://<your-vm-ip>:3000 in your browser, you'll land on the install form.

Gitea one-time install screen on first boot.

Choose SQLite3 as the database type. SQLite keeps the application lightweight and is a great fit for a self-hosted instance.

If you outgrow it later, you can migrate to PostgreSQL or MySQL. Leave the remaining pre-filled fields as they are and submit the form.

Once the installation completes, create the first user by visiting http://<your-vm-ip>:3000/user/sign_up.

Registering the first user, this account becomes the instance admin.

Submit the form, and you'll be dropped into a freshly initialized dashboard, ready for repositories.

A freshly-initialized Gitea dashboard, ready for its first repository.

Putting Caddy in front for automatic HTTPS

Right now, Gitea is exposed on port 3000 over plain HTTP. We'll put Caddy in front so we get HTTPS via Let's Encrypt without any certbot dance. Caddy handles certificate issuance and renewal on its own, as long as our hostname resolves to this VM.

Pick a hostname and stash it in a shell variable so every command below stays copy-paste-able. Run one of these on the VM:

1# If you have a domain:
2HOST=gitea.example.com
3
4# If you don't, build a nip.io hostname from this VM's public IP:
5HOST=gitea.$(curl -s ifconfig.me).nip.io
6
7echo "Using HOST=$HOST"

Confirm DNS is pointing the right way. From your local machine:

1dig +short "$HOST"

You should see the public IP of your teapot VM. If you don't (and you're using your own domain), wait a few minutes for DNS propagation before continuing. Let's Encrypt's first request will fail otherwise. With nip.io, this resolves instantly with no DNS configuration on your end.

Install Caddy from the official Cloudsmith repository:

1sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
2curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' \
3  | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
4curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' \
5  | sudo tee /etc/apt/sources.list.d/caddy-stable.list
6sudo apt update && sudo apt install caddy -y

Write the Caddyfile, expanding $HOST into it:

1sudo tee /etc/caddy/Caddyfile > /dev/null <<EOF
2${HOST} {
3    reverse_proxy 127.0.0.1:3000
4}
5EOF

That's the entire reverse proxy configuration. Caddy will request, install, and renew a Let's Encrypt certificate automatically the first time the site is hit. Reload Caddy to pick up the new config:

1sudo systemctl reload caddy

We also need to tell Gitea about its new public URL so links it generates (clone URLs, webhook URLs, password reset emails) use HTTPS. Patch /etc/gitea/app.ini in place, again using $HOST:

1sudo sed -i \
2  -e "s|^ROOT_URL\s*=.*|ROOT_URL = https://${HOST}/|" \
3  -e "s|^DOMAIN\s*=.*|DOMAIN   = ${HOST}|" \
4  /etc/gitea/app.ini

Restart Gitea to apply the change:

1sudo systemctl restart gitea

Heading over to gitea.<yourinstanceip>.nip.io, you should be greeted with the following screen

Gitea is reachable on the custom domain with a valid certificate

Locking down port 3000 with UFW

Caddy is doing the public-facing work now, so there's no reason to leave port 3000 open to the internet. Let's tighten things up with UFW.

1sudo apt install ufw -y
2sudo ufw default deny incoming
3sudo ufw default allow outgoing
4sudo ufw allow 22/tcp
5sudo ufw allow 80/tcp
6sudo ufw allow 443/tcp
7sudo ufw enable

We're allowing SSH on 22, HTTP on 80 (Caddy uses it for the ACME challenge and to redirect visitors to HTTPS), and HTTPS on 443. Everything else, including 3000, is now refused from outside the VM, so direct connections to Gitea have to go through Caddy.

Confirm the firewall is active:

1sudo ufw status

Closing thoughts

We've now got a self-hosted Gitea instance running on a Civo VM, fronted by Caddy with auto-renewing TLS and locked down behind a UFW firewall. From here, you might:

• Push your first repository to it, create a repo in the Gitea UI, then git remote add origin git@gitea.example.com:<you>/<repo>.git from your local machine
• Set up Gitea Actions runners to run CI on the same VM
• Mirror an existing GitHub repo into Gitea for a quick backup
• Take regular snapshots of /var/lib/gitea/ and your SQLite database so you can recover from a bad day

If you'd like to keep an eye on the VM itself, our Monitoring a Linux VM with Prometheus and Grafana tutorial is a natural next step.