Here is how I have my own gitea instance, with the possibility to add external users, running on my own private server.

gitea?

gitea is a fork of gogs (november 2016). It is an open source web frontend for your git repositories, and basically only implements the essentials, not like github (which you can’t selfhost anyway) or gitlab (which is a monster to setup and maintain for a small personal git repo site).

It’s a single go binary, and you can download it from its official download site. I just get it from there with wget or curl and dump it into gitea’s home directory (where also the sqlite database lives, more on that in the install script).

systemd setup

Since gitea is a single go binary, it’s very easy to implement in systemd. You just create a file /etc/systemd/system/gitea.service with this content:

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
[Service]
RestartSec=2s
Type=simple
User=git
Group=git
WorkingDirectory=/var/lib/gitea/
ExecStart=/usr/local/bin/gitea web --config /etc/gitea/app.ini
Restart=always
Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea
[Install]
WantedBy=multi-user.target

There are other things you can tune, eg. when you have big repositories or want to use a different database or git-lfs or something. I declare that as out of scope for this article, I just want to make my day-to-day life with this very simple gitea instance.

Which I, btw., run behind a apache2 mod_proxy which handles SNI for all my sites. The configuration for that looks like this:

        <IfModule mod_proxy.c>
                ProxyPreserveHost On
                ProxyRequests Off
                ProxyPass /robots.txt !
                <Proxy *>
                        Require all granted
                </Proxy>
                ProxyPass / http://localhost:3000/
                ProxyPassReverse / http://localhost:3000/
        </IfModule>

I never got the static files (which you would need for robots.txt) to work in gitea, so I just put it in this website’s DocumentRoot. If it works, it isn’t stupid.

Yes, I only have HTTPS access to my gitea host now, but seriously, who cares. Virtual SSH hosts, or even with different providers (as gitea has its own builtin ssh daemon) is also out scope for this document.

Now the part that is a little bit tricky. You want to have a way to upgrade gitea when new releases get put out. That’s either for getting newer or better features, but also for fixing security vulnerabilities. For this I wrote this very simple bash script:

#!/bin/sh
if [ $# -eq 0 ]
  then
    echo "Gimme version number as argument"
    exit 1
  else
    if [ -f gitea-$1-linux-amd64 ]
      then
        echo "file gitea-$1-linux-amd64 found"
      else
        echo "file gitea-$1-linux-amd64 not found"
        exit 1
    fi
fi
systemctl stop gitea
cp gitea.sqlite3 gitea.sqlite3-$1
cp gitea-$1-linux-amd64 /usr/local/bin/gitea
chmod 755 /usr/local/bin/gitea
systemctl start gitea
echo "gitea v$1 installed, enjoy!"

You just run this in your git home directory (/home/git in my case), give the version number of the gitea binary you downloaded and hopefully also verified, and Bob’s your uncle.

This script also takes a backup of your sqlite database right before you let the new binary loose on it. You might want to make a modified version of this script without the backup part for downgrading. Left as an exercise to the reader…

Oh, and putting sudo in the appropriate places is left as an exercise to the reader as well. I just YOLO it and run the script as root. I know, not the best practice.

Enjoy!