Auto-hospedagem

Você pode rodar o workbench do Oloproof no seu próprio servidor: on-premises, em uma nuvem privada ou em um provedor de nuvem canadense. O pacote em deploy/self-hosted/ roda as mesmas duas imagens do oloproof.com (web e worker) e o PostgreSQL, baixadas por digest. Seus dados ficam onde você o roda, e nada é enviado ao Oloproof.

Requisitos

• Um host Linux com Docker Engine e o plugin Compose. 4 GB de memória e 2 CPUs bastam para uma equipe; o worker é limitado a 1,5 GB e a web a 768 MB.
• Disco para o PostgreSQL. Cada execução que você envia fica armazenada nele.
• Um proxy reverso para HTTPS (Caddyfile.example é um exemplo funcional; nginx também serve).
• Acesso a ghcr.io/etobicoke/oloproof, ou as imagens copiadas para o seu próprio registro.

Instalação

cd deploy/self-hosted
sh generate-env.sh          # writes .env and fills every secret

Defina OLOPROOF_WEB_IMAGE, OLOPROOF_WORKER_IMAGE (ambos digests ...@sha256:) e OLOPROOF_PUBLIC_URL no .env, e pelo menos uma forma de entrar: e-mail para contas com senha (OLOPROOF_MAIL_FROM com OLOPROOF_SMTP_URL ou OLOPROOF_RESEND_API_KEY) ou um provedor OAuth. A web se recusa a iniciar sem uma delas. Depois, inicie:

docker compose --env-file .env up -d
curl -fsS http://127.0.0.1:3000/api/health

O serviço migrate atualiza o banco de dados antes de a web e o worker iniciarem. O cadastro é por convite, emitido com OLOPROOF_OPERATOR_TOKEN (deploy/README.md, "Signup").

Configuração

.env.example lista todas as variáveis que a web e o worker leem, cada uma marcada como obrigatória, gerada ou opcional. Uma variável opcional vazia desliga o seu recurso. Guarde os segredos gerados: uma nova senha do banco de dados tranca você fora do banco, e uma nova chave de assinatura começa um novo signatário. Um pacote auto-hospedado não tem cobrança, então cada workspace tem as contagens mensais de casos do plano gratuito; aumente OLOPROOF_FREE_TIER_PUSHED_MONTHLY e OLOPROOF_FREE_TIER_MANAGED_MONTHLY para a sua equipe.

Sem rede de saída por padrão

A stack não envia telemetria e não chama nenhum serviço do Oloproof. Ela só acessa a rede para o que você ativar: e-mail (um relay SMTP dentro da sua rede, ou Resend), login OAuth, Turnstile e os provedores de modelos para os quais um workspace guarda uma chave. Sem nenhum deles, ela roda sem rota para fora. Para um host isolado, copie as três imagens para o seu próprio registro e aponte as variáveis de imagem para ele. Contas com senha precisam de e-mail, então em uma rede isolada defina OLOPROOF_SMTP_URL com um relay dentro dela.

Backups

sh backup.sh /srv/backups/oloproof

backup.sh grava um pg_dump comprimido no diretório que você escolher. Agende-o com cron ou um timer do systemd, e copie você mesmo o diretório para fora do host. O script mostra o comando de restauração.

O dump não inclui o .env, e o .env guarda o OLOPROOF_CONTENT_KEY e os demais segredos gerados: sem ele, um banco restaurado não consegue ler seu conteúdo criptografado. Faça backup do .env ao criá-lo e sempre que o alterar, separado dos dumps e offline (um gerenciador de senhas ou um disco criptografado), nunca ao lado deles.

Atualizações

Escreva os dois digests da nova versão no .env e rode:

sh upgrade.sh /srv/backups/oloproof

Ele faz o backup, baixa, migra e reinicia a web e o worker. Espere uma breve interrupção. Para reverter, escreva os digests anteriores e restaure o backup que ele fez.

O que é suportado

• Um host. Não há alta disponibilidade: a stack é tão disponível quanto a sua máquina.
• A residência dos dados é onde você a roda. O Oloproof não guarda nenhum dos seus dados.
• Sem releases sem tempo de inatividade. Eles pertencem apenas ao serviço hospedado.
• O pacote é verificado por deploy/self-hosted/check.sh, que o inicia com seu próprio nome de projeto, espera por /api/health, busca as páginas públicas e o remove.