Self hosted forgejo instance.

TLDR;

Two containers, one for forgejo, one for (optional) backups.

When everything is set up

• For forgejo cd to this folder and run docker compose.
• For borgmatic automatic borg updates cd to the borgmatic folder und run docker compose there.

docker compose up -d

Assumtions

• This forgejo instance is running on its own dedicated server.
• The data directory is on its own volume. (Not necessary, but probably easier to enlarge later.)
• The default ports for http(s) and ssh should be forwarded to forgejo.

Forgejo runs its own http(s) server, without any reverse-proxy.
Forgejo runs its own ssh server for git files transfer.

Important

If this server should stay accessible via your system sshd, let it listen to another port.

Variables

All variables should be set in .env. Use .env.template as template.

Note that both services (forgejo, borgmatic) need their own .env.

HTTPS

HTTPS is handled by forgejo which uses internal acme to obtain certificates from Let's Encrypt (awesome!). To respect their service and to avoid running into their rate-limits, persist https key material. Certificates can be regenerated, just not that often.

Users

Users should be able to see public code and provide feedback by issues or maybe even pull requests. Users should (per default) not be able to create repositories or otherwise use resources.

It should be possible to allow selected users access to selected repositories and/or organisations. It should be possible for selected users to create repositories.

Registration

This instance is not supposed to handle user authentification information, therefore it relies on oAuth2. Note that oAuth2 providers must be set up manually in the administration web interface.

Backup

Assumtions:

1. The backup system to use is borg backup.
2. The backup is supposed to be on a storage server.
   (Use this Hetzner referral link for free cloud credit.)
3. The backup should use its dedicated borg backup repository with a dedicated ssh keypair for separation of concerns / need to know.
4. There is another way (e.g. another keypair) to administrate, read, restore, ... the backups.

Note

Hetzner uses (and therefore this notes use) port 23 for storagebox ssh access.

Preparation

Create ssh keypair (on client, backup source)

(Skip if this server already has a keypair that should be reused.)

Create ssh user:

ssh-copy-id

(If public and private key should not be on the default location, the location must later be set in the borgmatic config.yaml.)

Authorize ssh keypair (on server, backup target)

To protect the backups from a hacked backup client:

• set the public key in ./.ssh/authorized_keys to --append-only,
• restrict the key to a fixed path with --restrict-to-path /path,
• restrict the keypair.

Arguments in authorized_keys will override the repository config, therefore append-only mode can be enabled on a key by key basis.

Tip

When using Hetzner, dont fall for what they call "sub-user". Restrict the user here.
(If you know better, I would be interested to chat!)
Other backup targets might handle things different.

Warning

When using Hetzners sub-user instead of restricting the user here, take care to not create an authorized_keys file in the folder this sub-user would have write access to.

Adjust <key type>, <key> and <key host> and append to the probably existing .ssh/authorized_keys file.

command="borg serve --append-only --restrict-to-path /home/code/forgejo",restrict <key type> <key> <key host>

Initialize borg backup repository (on client, backup source)

Use the previously created ssh key to initiate the borg backup repository.

borg init --encryption=repokey ssh://uXXXXXX@uXXXXXX.your-storagebox.de:23/./code/forgejo/REPOSITORY_NAME

Create the first borg backup archive

Use the previously initialized repository to create the initial backup.

borg create ssh://uXXXXXX@uXXXXXX.your-storagebox.de:23/./code/forgejo/REPOSITORY_NAME::ARCHIVENAME /mnt/volume-fsn1-1/forgejo/

Automate the creation of further archives.

Use docker-borgmatic.

Borg does not do anything about the internal consistency of the data it backs up.

This is a humble self hosted service without (m)any users. Until there is anybody to complain,

• just gracefully shut down the service,
• backup the data,
• restart the service.

ToDo:

[ ] Proper secret handling

[ ] Error handling

[ ] ...