Your own Git server.
The repository is the org chart.

Almost every argument about self-hosting Git is an argument about the source code, and the source code is the part that matters least. Most of it is unremarkable, a great deal of it is a thin layer over open-source libraries, and if it leaked tomorrow the practical damage would usually be embarrassment rather than harm. That is why "my code is not secret" feels like a complete answer, and why it is not one.

What surrounds the code is the interesting part. A repository is a dated, attributed, high-resolution record of work: commit timestamps that describe when you sleep, co-author lines that describe who you work with, branch names that describe products nobody has announced, an issue tracker that describes what is broken and how badly, and a first commit that dates the whole project. Read a hundred repositories that way and you are not reading software any more — you are reading a company, its roadmap, its headcount and its trouble.

On a platform, that record is not yours in any meaningful sense. It sits on infrastructure you do not control, under an account tied to an identity you verified, in a jurisdiction whose legal process reaches it, scanned by systems whose scope is set by a document that can be amended. None of that requires bad faith from anyone: it is just what renting the tracker means. Four arrangements, and what each one actually gives away:

Row three is the row that catches teams who think they have already solved this. A forge you installed yourself, on a machine rented with a corporate card under a verified company account, has moved the application out of the platform and left the identity exactly where it was. That is a real gain in control and no gain at all in exposure.

And row four states its own cost plainly, because the rest of this guide is mostly about paying it. The failure mode of self-hosting is not surveillance, it is loss. A platform keeps backups you never think about. Your server keeps the backups you configured. Step 06 is not the optional polish at the end — it is the step that makes the other five safe.

Order the box first. In the panel: Order → VPS → Sentinel, image Debian 12, in whichever bastion you want the history to live in — Helsinki, Stockholm, Oslo or Reykjavík. No email address is required to open the account and the invoice settles in Monero, Bitcoin, Lightning or any other supported asset. That matters more here than for most workloads: a forge is the one service whose entire value proposition is that the record of your work is not attached to a name.

Then run the first-hour hardening checklist — key-only SSH on a moved port, unattended upgrades, a default-deny firewall — because everything below assumes a box that is not already someone else's.

Point a hostname at the box — an A record, and an AAAA if you want it reachable over IPv6 — and let it propagate before you start, because the reverse proxy will try to obtain a certificate for that name the first time it boots and a failed challenge is a confusing way to begin. Then write the firewall rules while nothing is listening yet.

The two-SSH problem. A forge speaks SSH for Git, and your server already speaks SSH for administration. They cannot both own port 22, and mixing them is how people end up with an administrative daemon that also has to understand Git. Keep them separate: administration on the moved port from the hardening guide, Git on a dedicated public port that maps into the container. 2222 is the conventional choice and there is nothing sacred about it.

ufw default deny incoming
ufw allow 47222/tcp                  # administrative SSH, moved
ufw allow 80/tcp                     # ACME HTTP-01 challenge
ufw allow 443/tcp                    # the web interface
ufw allow 2222/tcp                   # git over SSH, into the container
ufw enable
ufw status numbered

# Nothing else is open. In particular: PostgreSQL stays on the Docker
# network and is never published to the host, let alone the internet.

Install Docker from the official repository rather than the distribution package, so that Compose v2 is present and the version is current. Then create a directory for the stack and make it the only place on the box that holds state — it is the directory step 06 backs up.

curl -fsSL https://get.docker.com | sh
docker compose version

install -d -m 0750 /srv/forgejo
cd /srv/forgejo

Paste your public key into the profile settings, then teach your client where the forge lives. Because Git is on a non-standard port, an entry in your SSH config is worth the thirty seconds — it keeps the port out of every URL you will ever type and makes the remotes portable.

# ~/.ssh/config
Host git.example.com
    Port 2222
    User git
    IdentityFile ~/.ssh/id_ed25519

# Then, in any repository:
git remote set-url origin git@git.example.com:you/project.git
git push -u origin main
ssh -T git@git.example.com        # expect a greeting, not a shell

That last command is the one that tells you whether the port mapping, the container SSH server and your key all agree. A greeting from Forgejo means the whole chain works. A password prompt means you have reached the host's administrative sshd instead, and the port mapping is wrong.

Now sign your commits. This is the step that most self-hosting guides skip, and on a self-hosted forge it matters more than it does on a platform. A commit's author field is free text — anyone who can push can write your name into it. A signature is proof that a specific key made a specific commit, and it keeps being proof after the server it was pushed to has been compromised, migrated or thrown away. Git can sign with the SSH key you already have, so there is no PGP detour any more:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
git config --global tag.gpgsign true

git commit --allow-empty -m "signed"
git log --show-signature -1

Then add the same public key a second time in the forge, as a signing key rather than an authentication key. Forgejo verifies the signature server-side and shows the commit as verified; without that second entry it has no way to connect the signature to your account, and every commit shows as unverified even though it is signed correctly.

Deploy keys, for the machines that only read. A production server, a build box or a mirror does not need a user account on the forge. Give it a deploy key instead: a key pair added to one repository, read-only unless you explicitly grant write, granting access to nothing else on the instance. Revoking it is deleting one entry. This is the single most effective habit for keeping a self-hosted forge tidy, because user accounts accumulate permissions and deploy keys cannot.

Migrating from a platform is a good moment to do all of this properly. Forgejo's New Migration flow takes a repository URL and an access token and brings across branches, tags, issues, comments, labels, milestones, releases and pull requests. Run one repository first to see the shape of the result, expect API rate limits to slow large batches, and keep the source read-only for a few weeks rather than deleting it the same day.

Git is unusually forgiving here and it is worth being precise about why. Every clone is a complete copy of the history, so as long as one developer has a current working copy, the code survives the server. That is genuinely reassuring, and it covers exactly one of the two things your forge holds. The other — issues, pull request discussions, review threads, releases, wiki pages, users, teams, permissions, CI history — exists only in the database, nobody has a clone of it, and it is usually the part that took three years to accumulate.

First, a push mirror. It is free and it runs itself. In a repository: Settings → Mirror settings → add a push mirror with the URL and an access token for the destination. Forgejo then replicates every branch and tag after each push, to a second Forgejo, to Codeberg, or to a platform you have decided to keep as a shop window rather than a home. One caveat worth stating plainly: a push mirror republishes history faithfully, including a secret you meant to remove.

Then a real backup, which is not the built-in archive. Forgejo ships a forgejo dump command that packs configuration, repositories, data and a database dump into a single zip. It is a genuinely useful thing to hand a maintainer when reporting a bug. It is not what you should be relying on to come back from the dead: the SQL it produces has long-standing known issues on re-import, and the archive rewrites the whole repository set every run, which on a real instance means a large file written from scratch every night. Use the boring, verifiable path instead — dump the database with the database's own tool, and back up the data directory as files:

#!/bin/sh
# /usr/local/bin/forgejo-backup — run from a systemd timer, nightly
set -eu
cd /srv/forgejo

# 1. Consistent database dump, written next to the data.
docker compose exec -T db pg_dump -U forgejo -Fc forgejo > ./db.dump

# 2. Everything that matters, to an encrypted offsite repository.
restic backup ./data ./db.dump ./docker-compose.yml ./.env ./Caddyfile

# 3. Retention, then prove the repository is still readable.
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic check

Send it to a machine in a different jurisdiction from the forge, over an append-only repository so that a compromise of the forge cannot erase its own history — the encrypted backups guide is the long version of the three lines above, including the systemd timer and the append-only key restriction.

Then restore it once, on purpose. Order a scratch VPS, restore the snapshot into it, bring the same Compose file up against the restored data directory, load the database dump, point a hosts-file entry at it and sign in. Time the whole thing. That number — not the existence of the backup job — is your actual recovery position, and everybody who has done this exercise has found at least one thing missing from the include list the first time.

# restic keeps absolute paths, so the stack reappears under the target.
restic restore latest --target /srv/restore
cd /srv/restore/srv/forgejo

docker compose up -d db                # empty volume: the entrypoint creates the database
docker compose exec -T db pg_restore -U forgejo -d forgejo \
  --clean --if-exists --no-owner < db.dump

docker compose up -d                   # then sign in and walk the issue tracker

Upgrades, briefly. Pin the image to a major version rather than :latest, so an unattended pull cannot move you across a breaking change while you sleep. Read the release notes before crossing a major boundary, take a snapshot first, and remember that a database migration runs on the first start of the new version — which is a one-way door. Watchtower-style auto-updating is a fine idea for a static site and a poor one for the machine that holds every branch you have.

Four checks before you call it done. Sign out and confirm the instance offers no way to create an account. From a browser with no session, confirm a private repository is invisible rather than merely forbidden. Confirm the runner cannot read the forge's data directory. And confirm the last restic check passed — the backup job that fails silently is the one everybody has, right up until the day they need it.