From Organic Design
Cone.png This article or section is a stub. Stubs are articles that have not yet received substantial attention from the authors. They are short or insufficient pieces of information and require additions to further increase the article's usefulness. The project values stubs as useful first steps toward complete articles.


We used the default Docker installation which was very straight forward. The only change to the default docker-compose.yml we made was to change the external ports to 333 since we already have Mastodon using port 3000. The HTTP port is also served on localhost only since it will be accessed via proxy only.

version: "2"
    external: false
    image: gitea/gitea:latest
      - USER_UID=1000
      - USER_GID=1000
    restart: always
      - gitea
      - ./gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
      - ""
      - "222:22"

After you are able to access the site online, you can then go through the initial user registration, which asks a bunch of admin question, for us we couldn't set anything, except the database which needed to be set to SQLite3. The web UI configuration page is currently read-only and settings are configured in the gitea/gitea/conf/app.ini file (if you used the default volumes setup). We made the following changes.

APP_NAME             = Organic Design Gitea
ENABLED              = true
MAILER_TYPE          = sendmail
FROM                 =

Nginx reverse proxy

Setting up Nginx as a reverse proxy server means that you can use a normal default port and redirect requests to the docker service internally. For us the site runs as HTTPS publicly which is done with a simple virtual host container and all our existing SSL set up that's already in place for all the sites. The reverse proxy the redirects requests to Gitea internally unencrypted so we don't need to bother with any SSL or certificate configuration there.

server {
	listen 443 ssl;
	listen [::]:443 ssl;
	include /var/www/work/nginx.ssl.conf;
	location / {
		proxy_pass http://localhost:3000;

Pushing an existing repository from the command line

This is over HTTP because pushing an entire repo and its history is a lot of data that will likely not be accepted by the reverse proxy, so SSH will need to be used. We can update the remote origin URL of our existing repo and insert out non-standard SSH port and then push it as in the following example:

git remote set-url origin ssh://
git push -u origin master

Automatically updating a repo with webhooks

We like to have some repos on the server that are automatically updated when anything is changed. We do this by executing a git pull as root as shown in our Git article. The Gitea webhooks documentation has a sample PHP script that receives the webhook post from Gitea which works perfectly. The only change is that we remove the true argument from the json_decode so that it's not an associative array, and then add the following to perform the pull on the correct repo in /var/www.

$decoded = json_decode( $payload );
$repo = $decoded->repository->name;
exec( "cd /var/www/$repo && sudo git pull --no-edit" );
  • Note1: see the webhooks section of the Git article for details about allowing the git pull to be performed as root.
  • Note2: the repo being updated should be using SSH (using the clone URL format shown above) to avoid authentication trouble.


Backing up can be done with the following command as shown in the docs, but this results in a zip file inside the container that then needs to be moved into the volume as root.

docker exec -u git -it -w /tmp $(docker ps -qf "name=gitea-docker_server_1") bash -c '/app/gitea/gitea dump'
docker exec -u root -it $(docker ps -qf "name=gitea-docker_server_1") sh -c 'mv /tmp/gitea-dump-*.zip /data'

See also