From charlesreid1

What is it?

Gitea is a self-hosted github-like web service, written in Go.

(insert screenshot here)

Main link:

Github project:


To install it, you can build it using go, or you can use the binary.

Using Binary

I kept the gitea directory organized by putting the binary in its own folder, then separating out the certificates (for https/ssl), data (gitea's sqlite database), repositories (data for git repositories), and log (logging for gitea).

+--------- bin/
+--------- certs/
+--------- data/
+--------- repositories/
+--------- log/

To install it, you just navigate to the binary and run

$ ./gitea web

This runs a setup page on port 3000. Alternatively, you can use the admin command line interface to set things up securely, without exposing the (sensitive) setup page to anyone.

That's about it.

From Source

Before you do anything else, make sure your GOPATH is set:

export GOPATH="${HOME}/gocode"

To install gitea from source, first download the source into your go path:

go get -d -u
cd $GOPATH/src/

Now check out the release that you want:

git checkout release/v1.0

and then build it using make:

TAGS="bindata sqlite" make generate build

Successful Build

Build it using make generate:

$ TAGS="bindata sqlite" make generate
go generate

Then make build:

$ TAGS="bindata" make build
go build -i -v -tags 'bindata' -ldflags '-s -w -X "main.Version=1.1.3" -X "main.Tags=bindata"' -o gitea


First (Failed) Attempt

Gitea/First Failed Attempt

Gitea with HTTPS

You can run gitea over HTTPS. The gitea binary can generate self-signed certificates, or you can use an existing HTTPS certificate.

Using existing HTTPS certificate

I needed to have gitea over HTTPS using an existing certificate. I already had an HTTPS certificate, in the form of a private .key and a public .cert, but it was set up to be restricted to root only, and nginx and Apache are perfectly okay running as www-data and not being able to read the private key file (which is only readable by root). We're fine there.

But when I pointed to these files with soft links,

$ ln -fs /sslkeys/key.pem /www/gitea/cert/key.pem
$ ln -fs /sslkeys/cert.pem /www/gitea/cert/key.pem

I was having some problems getting gitea to run. Gitea was raising a permissions error:

$ ./gitea web
2017/03/21 15:21:12 [T] Custom path: /www/gitea/bin/custom
2017/03/21 15:21:12 [T] Log path: /www/gitea/log
2017/03/21 15:21:12 [I] Gitea v1.0.1
2017/03/21 15:21:12 [I] Log Mode: File(Info)
2017/03/21 15:21:12 [I] Cache Service Enabled
2017/03/21 15:21:12 [I] Session Service Enabled
2017/03/21 15:21:12 [I] Git Version: 2.5.0
2017/03/21 15:21:12 [I] SQLite3 Supported
2017/03/21 15:21:12 [I] Run Mode: Production
2017/03/21 15:21:12 [I] Listen:
2017/03/21 15:21:12 [ runWeb()] [E] Fail to start server: open /www/gitea/certs/key.pem: permission denied

The solution was, the user that runs the Gitea web command also has to be able to read the private key file. Can just make the /sslkeys folder and contents group-readable to a new group ssl-group, and add any users that need access to the keys. Then add a git or gitea user, and run everything as the git user.

Add SSL group:

groupadd ssl-certs

Make a git user to run gitea:

useradd git

Add git user to ssl-certs group:

usermod -G ssl-certs git

Change permissions of SSL certs to be group-readable:

chgrp ssl-certs /sslcerts/{cert,key}.pem
chmod g+r /sslcerts/{cert,key}.pem

Now the keys are group-readable, and git is added to the group who can read SSL keys.

One more hurdle: we have to run gitea as the git user we just created. But we'll cover that below.

Using Self-Signed Cert

Using a self-signed HTTPS certificate is basically the equivalent to saying "Trust me!" at the end of every sentence. Any decent web browser raising an annoying warning or not loading the page at all. To use gitea to do it:

$ ./gitea cert --host

This will create a key and certificate in the same directory, with pretty loose permissions.

Users and Permissions

Here's how I organized and arranged my gitea installation:

  • set the git user as the user gitea runs as in the gitea config file
  • the git user was running the gitea binary
  • the git user was part of the ssl-certs group, which could read both public and private SSL keys
  • the public and private keys were made group-readable and owned by the ssl-certs group
  • to run gitea, I start up Screen and run the command sudo su git to get a shell as the user git. I then start up the gitea binary.

Here's what that requires:

Change the RUN_USER variable in the gitea config file, in custom/conf/app.ini:

RUN_USER = git

And then some commands to do user stuff and prepare to run the web server as git user:

# add group
groupadd ssl-certs

# add user
useradd git

# make user home directory for git user
mkdir /home/git

# add user to group
usermod -a -G ssl-certs git

# make ssl certs ownable
chgrp ssl-certs /sslkeys/{cert,key}.pem
chmod g+r /sslkeys/{cert,key}.pem

Now open up a screen and in the screen execute these commands:

# get a shell as user git
sudo su git

# run the gitea binary
cd /www/gitea/bin
./gitea web

Then detach the screen and voila.

Importing Repositories from Github

If you want to import a repository or move a repository from a different server to your gitea server, here's how you do it.


  • Get a local copy of the repo onto your server
  • Fetch all the tags, commits, remote branches, etc. so you have a local copy
  • Add a new remote server, e.g., new-origin
  • Push all local branches and tags to the new-origin server
  • Remove old origin, rename new-origin to origin


Getting local copy of repo locally

You'll be downloading a copy of the entire repository to a local disk. It doesn't need to be the remote server, although that can speed things up a bit.

Fetch all tags, commits, etc

If origin is the remote server you are migrating FROM:

git fetch origin

This will get all the latest branches and tags info, but won't necessarily grab a copy. To force git to grab a copy, do:

git branch -a

Get any branches prefixed with remote/origin/my-branch and check them out:

For example if you had remote/origin/my-branch-1 and remote/origin/my-branch-2:

git checkout -b my-branch-1 origin/my-branch-1
git checkout -b my-branch-2 origin/my-branch-2

Now verify you have local copies of all branches:

git branch -a

Create new repo on Gitea

On Gitea, make your new repository, but don't initialize it with any contents (no .gitignore or README). If you have accidentally added content to the repo already, you can add the force flag when you push commits from the copy you want to preserve to the gitea's git server.

Add new remote target for git repo

Now create your new remote, call it new-origin:

git remote add new-origin user@server:path/to/git/repo

Now we have two remotes. We'll push everything to the brand new remote, then sever any ties we had with the old remote.

Push everything to new server

To push everything to the remote new-origin:

git push --all new-origin
git push --tags new-origin

NOTE: If you are using git over HTTPS, use your Gitea login username and password. If you are using git over SSH, you will already have given your public key to Gitea so it will not need to authenticate your machine.

Update remote origin

Now get rid of the old origin and replace it with the new-origin:

git remote rm origin
git remote rename new-origin origin

Optional: delete old repo

At this point, you can delete the old remote repository on the old server if you so choose.


Have confirmed this is working. Only trick is using a force flag when you send your commits to the remote server, so you don't get stuck in a conflict.

The short version, for single-branch codes, is this:

Start by creating a project on Gitea that should be completely empty, named whatever you'd like. The repository URL is the Gitea URL referenced in the script below.

$ git checkout <github url> projectname
$ cd projectname
$ git remote add origin-new <gitea url> 
$ git push origin-new

It's literally that simple - now the entire contents have been pushed to the git server that Gitea is running, and that means a copy of the entire project's commit history has just been pushed to the Gitea server.

That's the beauty of git - decentralized version control - the history really is public and open, with the integrity of the contents assured by hashes, so the entire history of the repository travels with each user and can be spread to everyone, so that one server going down doesn't spell doom for the entire history of a code project - there are as many copies as there are contributors with a copy checked out.

Accessing the Git Server

Once you get gitea up and running, and try to get a project imported, questions will inevitably start to arise. How does it know to listen for git requests? Do I need to be running a git server? Fortunately gitea takes care of all of that, installing its own git modules and managing the git repository for the git server. (Not that running a git server is that complicated. It's basically like running an SSH server. [1])


How gitea manages the git server

Gitea manages the git repo under the hood, to turn things like hooks and the like into actual actions by an actual git repo. This is also how it's handling SSH keys, for example, or differentiating between git requests and http requests. (Same with page content - all handled by the executable, with no intervention or static content or HTML required by the user.) The Go executable wraps all of this into one monolithic executable that's listening on one port.

If you were managing your own server, here's how you'd do it: [2]

Configure gitea for checking out git repos via https and ssh

You can configure gitea with the app.ini file such that your "Check out via HTTPS/SSH" buttons on each repository's page will actually WORK.

First, open the config file in an editor. I made use of the extensive app.ini example in the gitea repo on Github:

Change the following settings in the following sections.

; Warning: this gets rid of the HTTPS option to check out repos...

PROTOCOL     = https
DOMAIN       =
CERT_FILE    = /sslcerts/cert.pem
KEY_FILE     = /sslcerts/key.pem
HTTP_PORT    = 3000
ROOT_URL     =
DISABLE_SSH  = false

These will set the parameters for Gitea to correctly provide the HTTPS and SSH addresses for you to check out repositories using git.

Final Server Gitea Configuration

Here's an example config file based on one in the gitea repo that pretty closely matches my final configuration:

;; Example Gitea Config File

APP_NAME = big ugly git repo (BUGR)
RUN_USER = git
RUN_MODE = prod

DB_TYPE  = sqlite3
HOST     =
NAME     =
USER     =
SSL_MODE = disable
PATH     = /www/gitea/data/gitea.db

ROOT = /www/gitea/repositories
; This gets rid of the HTTPS option to check out repos...

PROTOCOL     = https
DOMAIN       =
CERT_FILE    = /www/gitea/certs/cert.pem
KEY_FILE     = /www/gitea/certs/key.pem
HTTP_PORT    = 3000
ROOT_URL     =
DISABLE_SSH  = false
SSH_PORT     = 22

ENABLED = false

DISABLE_GRAVATAR        = true


MODE      = file
LEVEL     = Info
ROOT_PATH = /www/gitea/log



Virtual Network Interface

Note that gitea will create a virtual network interface available via ifconfig:

veth7c3cabc Link encap:Ethernet  HWaddr 11:22:ff:aa:ee:cc
          inet6 addr: fe80::3046:f5ff:fea:f18c/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:648 (648.0 B)  TX bytes:648 (648.0 B)

Adding Static Content

This doesn't seem to work...


Main site:

Very nice, very detailed sample app.ini config file:

Config cheat sheet:

Binary installation:

Can use Docker