Seu próprio servidor Git.
O repositório é o organograma.

Quase todo argumento sobre auto-hospedar o Git é um argumento sobre o código-fonte, e o código-fonte é a parte que menos importa. A maior parte dele não tem nada de especial, boa parte é apenas uma camada fina sobre bibliotecas de código aberto, e se vazasse amanhã o dano prático costumaria ser constrangimento, não prejuízo real. É por isso que "meu código não é secreto" parece uma resposta completa — e por que não é.

O que cerca o código é a parte interessante. Um repositório é um registro de trabalho datado, atribuído e de alta resolução: os horários dos commits revelam quando você dorme, as linhas de coautoria revelam com quem você trabalha, os nomes de branch revelam produtos que ninguém anunciou, um rastreador de issues revela o que está quebrado e o quão gravemente, e um primeiro commit data o projeto inteiro. Leia cem repositórios dessa forma e você não está mais lendo software — você está lendo uma empresa, seu roadmap, seu quadro de funcionários e seus problemas.

Em uma plataforma, esse registro não é seu em nenhum sentido relevante. Ele fica em uma infraestrutura que você não controla, sob uma conta vinculada a uma identidade que você verificou, em uma jurisdição cujo processo legal o alcança, vasculhado por sistemas cujo escopo é definido por um documento que pode ser alterado. Nada disso exige má-fé de ninguém: é apenas o que significa alugar o rastreador. Quatro arranjos, e o que cada um deles realmente expõe:

A terceira linha é a que pega de surpresa as equipes que acham que já resolveram essa questão. Uma forja que você mesmo instalou, em uma máquina alugada com o cartão da empresa sob uma conta corporativa verificada, tirou a aplicação da plataforma e deixou a identidade exatamente onde estava. Isso é um ganho real de controle e absolutamente nenhum ganho em exposição.

E a quarta linha declara seu próprio custo com todas as letras, porque o resto deste guia é basicamente sobre como pagá-lo. O modo de falha da auto-hospedagem não é vigilância, é perda. Uma plataforma mantém backups em que você nunca pensa. O seu servidor mantém os backups que você configurou. A etapa 06 não é o acabamento opcional do final — é a etapa que torna as outras cinco seguras.

Peça a máquina primeiro. No painel: Order → VPS → Sentinel, imagem Debian 12, em qualquer bastião onde você queira que o histórico viva — Helsinki, Stockholm, Oslo ou Reykjavík. Nenhum endereço de e-mail é exigido para abrir a conta, e a fatura é paga em Monero, Bitcoin, Lightning ou qualquer outro ativo aceito. Isso importa mais aqui do que na maioria das cargas de trabalho: uma forja é o único serviço cuja proposta de valor inteira é que o registro do seu trabalho não esteja vinculado a um nome.

Depois rode o checklist de hardening da primeira hora — SSH somente com chave em uma porta alterada, atualizações automáticas, um firewall que nega tudo por padrão — porque tudo o que vem a seguir presume uma máquina que ainda não é de outra pessoa.

Aponte um hostname para a máquina — um registro A, e um AAAA se você quiser que ela seja acessível via IPv6 — e deixe isso se propagar antes de começar, porque o proxy reverso vai tentar obter um certificado para esse nome na primeira vez que subir, e um desafio que falha é uma forma confusa de começar. Depois escreva as regras de firewall enquanto ainda não há nada escutando.

O problema dos dois SSH. Uma forja fala SSH para o Git, e o seu servidor já fala SSH para administração. Os dois não podem ser donos da porta 22 ao mesmo tempo, e misturá-los é como as pessoas acabam com um daemon administrativo que também precisa entender de Git. Mantenha-os separados: administração na porta alterada do guia de hardening, Git em uma porta pública dedicada que mapeia para dentro do contêiner. 2222 é a escolha convencional, e não há nada de sagrado nela.

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.

Instale o Docker a partir do repositório oficial, em vez do pacote da distribuição, para garantir que o Compose v2 esteja presente e a versão esteja atualizada. Depois crie um diretório para a stack e faça dele o único lugar na máquina que guarda estado — é esse o diretório que a etapa 06 vai fazer backup.

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

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

Cole sua chave pública nas configurações de perfil, e depois ensine ao seu cliente onde a forja mora. Como o Git está em uma porta não padrão, uma entrada no seu arquivo de configuração de SSH vale os trinta segundos — ela mantém a porta fora de toda URL que você vai digitar dali em diante, e torna os remotos portáveis.

# ~/.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

Esse último comando é o que te diz se o mapeamento de porta, o servidor SSH do contêiner e a sua chave estão todos de acordo. Uma saudação do Forgejo significa que toda a cadeia funciona. Um pedido de senha significa que você chegou, em vez disso, ao sshd administrativo do host, e o mapeamento de porta está errado.

Agora assine os seus commits. Essa é a etapa que a maioria dos guias de auto-hospedagem pula, e em uma forja auto-hospedada ela importa mais do que em uma plataforma. O campo de autor de um commit é texto livre — qualquer um que possa fazer push pode escrever o seu nome nele. Uma assinatura é prova de que uma chave específica fez um commit específico, e ela continua sendo prova mesmo depois que o servidor para o qual foi enviada tiver sido comprometido, migrado ou descartado. O Git consegue assinar com a chave SSH que você já tem, então não é mais preciso o desvio pelo PGP:

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

Depois adicione a mesma chave pública uma segunda vez na forja, como chave de assinatura, e não como chave de autenticação. O Forgejo verifica a assinatura no lado do servidor e mostra o commit como verificado; sem essa segunda entrada, ele não tem como conectar a assinatura à sua conta, e todo commit aparece como não verificado, mesmo estando assinado corretamente.

Chaves de implantação, para as máquinas que só leem. Um servidor de produção, uma máquina de build ou um espelho não precisam de uma conta de usuário na forja. Dê a eles uma chave de implantação em vez disso: um par de chaves adicionado a um único repositório, somente leitura a menos que você conceda escrita explicitamente, sem dar acesso a mais nada na instância. Revogá-la é apagar uma entrada. Esse é o hábito mais eficaz de todos para manter uma forja auto-hospedada organizada, porque contas de usuário acumulam permissões, e chaves de implantação não podem.

Migrar de uma plataforma é um bom momento para fazer tudo isso direito. O fluxo New Migration do Forgejo recebe a URL de um repositório e um token de acesso, e traz consigo branches, tags, issues, comentários, etiquetas, marcos, releases e pull requests. Rode um repositório primeiro para ver a cara do resultado, espere que os limites de taxa da API deixem os lotes grandes mais lentos, e mantenha a origem somente leitura por algumas semanas, em vez de apagá-la no mesmo dia.

O Git é incomumente tolerante nesse ponto, e vale a pena ser preciso sobre o porquê. Todo clone é uma cópia completa do histórico, então, contanto que um desenvolvedor tenha uma cópia de trabalho atualizada, o código sobrevive ao servidor. Isso é genuinamente tranquilizador, e cobre exatamente uma das duas coisas que a sua forja guarda. A outra — issues, discussões de pull request, threads de revisão, releases, páginas de wiki, usuários, equipes, permissões, histórico de CI — existe só no banco de dados, ninguém tem um clone dela, e costuma ser a parte que levou três anos para se acumular.

Primeiro, um espelho push. Ele é gratuito e cuida de si mesmo. Em um repositório: Settings → Mirror settings → adicione um espelho push com a URL e um token de acesso para o destino. O Forgejo então replica cada branch e cada tag depois de todo push, para um segundo Forgejo, para o Codeberg, ou para uma plataforma que você decidiu manter como vitrine, e não como casa. Uma ressalva que vale a pena deixar bem clara: um espelho push republica o histórico fielmente, incluindo um segredo que você queria ter removido.

Depois um backup de verdade, que não é o arquivo embutido. O Forgejo vem com um comando forgejo dump que empacota configuração, repositórios, dados e um dump do banco de dados em um único zip. É uma coisa genuinamente útil para entregar a um mantenedor ao relatar um bug. Não é aquilo com que você deveria contar para voltar dos mortos: o SQL que ele produz tem problemas conhecidos de longa data na reimportação, e o arquivo reescreve todo o conjunto de repositórios a cada execução, o que, em uma instância real, significa um arquivo grande escrito do zero toda noite. Use o caminho chato e verificável em vez disso — faça o dump do banco de dados com a própria ferramenta do banco, e faça backup do diretório de dados como arquivos:

#!/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

Envie-o para uma máquina em uma jurisdição diferente da forja, por meio de um repositório somente para acréscimo, para que um comprometimento da forja não consiga apagar o próprio histórico — o guia de backups criptografados é a versão longa das três linhas acima, incluindo o timer do systemd e a restrição de chave somente para acréscimo.

Depois restaure tudo uma vez, de propósito. Peça uma VPS descartável, restaure o snapshot nela, suba o mesmo arquivo do Compose apontando para o diretório de dados restaurado, carregue o dump do banco de dados, aponte uma entrada no arquivo hosts para ela e faça login. Cronometre tudo isso. Esse número — não a mera existência do job de backup — é a sua posição real de recuperação, e todo mundo que já fez esse exercício encontrou pelo menos uma coisa faltando na lista de inclusão da primeira vez.

# 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

Atualizações, em resumo. Fixe a imagem em uma versão principal, em vez de :latest, para que um pull automático não te faça atravessar uma mudança que quebra compatibilidade enquanto você dorme. Leia as notas de lançamento antes de cruzar uma fronteira de versão principal, tire um snapshot antes, e lembre-se de que uma migração de banco de dados roda na primeira inicialização da nova versão — o que é uma porta sem volta. Atualização automática no estilo Watchtower é uma boa ideia para um site estático e uma péssima ideia para a máquina que guarda cada branch que você tem.

Quatro verificações antes de dar por encerrado. Saia da conta e confirme que a instância não oferece nenhuma forma de criar uma conta. A partir de um navegador sem sessão, confirme que um repositório privado fica invisível, e não apenas proibido. Confirme que o runner não consegue ler o diretório de dados da forja. E confirme que o último restic check passou — o job de backup que falha silenciosamente é aquele que todo mundo tem, até o dia em que precisa dele.