Self-hosting

Potete eseguire il workbench di Oloproof sul vostro server: on premise, in un cloud privato o presso un fornitore cloud canadese. Il pacchetto in deploy/self-hosted/ esegue le stesse due immagini di oloproof.com (web e worker) e PostgreSQL, scaricate per digest. I vostri dati restano dove lo eseguite, e nulla viene inviato a Oloproof.

Requisiti

• Un host Linux con Docker Engine e il plugin Compose. 4 GB di memoria e 2 CPU bastano per un team; il worker è limitato a 1,5 GB e il web a 768 MB.
• Spazio su disco per PostgreSQL. Ogni esecuzione che inviate viene salvata lì.
• Un reverse proxy per HTTPS (Caddyfile.example è un esempio funzionante; va bene anche nginx).
• Accesso a ghcr.io/etobicoke/oloproof, oppure le immagini copiate nel vostro registry.

Installazione

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

Impostate OLOPROOF_WEB_IMAGE, OLOPROOF_WORKER_IMAGE (entrambi digest ...@sha256:) e OLOPROOF_PUBLIC_URL in .env, e almeno un modo per accedere: la posta per gli account con password (OLOPROOF_MAIL_FROM con OLOPROOF_SMTP_URL o OLOPROOF_RESEND_API_KEY) o un provider OAuth. Il web si rifiuta di partire senza. Poi avviatelo:

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

Il servizio migrate aggiorna il database prima che partano il web e il worker. La registrazione avviene su invito, emesso con OLOPROOF_OPERATOR_TOKEN (deploy/README.md, «Signup»).

Configurazione

.env.example elenca ogni variabile letta dal web e dal worker, ciascuna segnata come obbligatoria, generata o facoltativa. Una variabile facoltativa vuota disattiva la sua funzione. Conservate i segreti generati: una nuova password del database vi chiude fuori dal database, e una nuova chiave di firma avvia un nuovo firmatario. Un pacchetto self-hosted non ha fatturazione, quindi ogni spazio di lavoro ha i conteggi mensili di casi del piano gratuito; aumentate OLOPROOF_FREE_TIER_PUSHED_MONTHLY e OLOPROOF_FREE_TIER_MANAGED_MONTHLY per il vostro team.

Nessuna rete in uscita per impostazione predefinita

Lo stack non invia telemetria e non chiama alcun servizio di Oloproof. Raggiunge la rete solo per ciò che attivate: la posta (un relay SMTP nella vostra rete, o Resend), l'accesso OAuth, Turnstile e i fornitori di modelli per cui uno spazio di lavoro conserva una chiave. Senza nessuno di questi, funziona senza alcuna via verso l'esterno. Per un host isolato, copiate le tre immagini nel vostro registry e puntate lì le variabili delle immagini. Gli account con password hanno bisogno della posta, quindi su una rete isolata impostate OLOPROOF_SMTP_URL su un relay al suo interno.

Backup

sh backup.sh /srv/backups/oloproof

backup.sh scrive un pg_dump compresso nella directory scelta. Pianificatelo con cron o un timer systemd, e copiate voi stessi la directory fuori dall'host. Lo script mostra il comando di ripristino.

Il dump non contiene .env, e .env contiene OLOPROOF_CONTENT_KEY e gli altri segreti generati: senza di esso un database ripristinato non può leggere il contenuto cifrato. Fate una copia di .env quando lo create e a ogni modifica, separata dai dump e offline (un gestore di password o un disco cifrato), mai accanto a essi.

Aggiornamenti

Scrivete i due digest della nuova release in .env, poi eseguite:

sh upgrade.sh /srv/backups/oloproof

Esegue il backup, scarica, migra e riavvia il web e il worker. Aspettatevi una breve interruzione. Per tornare indietro, scrivete i digest precedenti e ripristinate il backup che ha fatto.

Cosa è supportato

• Un solo host. Non c'è alta disponibilità: lo stack è disponibile quanto la sua macchina.
• La residenza dei dati è dove lo eseguite. Oloproof non conserva nessuno dei vostri dati.
• Nessun rilascio senza interruzioni. Quelli appartengono solo al servizio ospitato.
• Il pacchetto è verificato da deploy/self-hosted/check.sh, che lo avvia con un proprio nome di progetto, attende /api/health, recupera le pagine pubbliche e lo rimuove.