Auto-hébergement

Vous pouvez faire tourner l'atelier Oloproof sur votre propre serveur : sur site, dans un cloud privé ou chez un fournisseur cloud canadien. Le paquet deploy/self-hosted/ lance les deux mêmes images qu'oloproof.com (web et worker) et PostgreSQL, tirées par digest. Vos données restent là où vous le faites tourner, et rien n'est envoyé à Oloproof.

Prérequis

• Un hôte Linux avec Docker Engine et le plugin Compose. 4 Go de mémoire et 2 CPU suffisent pour une équipe ; le worker est plafonné à 1,5 Go et le web à 768 Mo.
• De l'espace disque pour PostgreSQL. Chaque exécution que vous poussez y est stockée.
• Un proxy inverse pour HTTPS (Caddyfile.example est un exemple fonctionnel ; nginx convient aussi).
• Un accès à ghcr.io/etobicoke/oloproof, ou les images copiées dans votre propre registre.

Installation

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

Renseignez OLOPROOF_WEB_IMAGE, OLOPROOF_WORKER_IMAGE (deux digests ...@sha256:) et OLOPROOF_PUBLIC_URL dans .env, ainsi qu'au moins un moyen de se connecter : le courriel pour les comptes à mot de passe (OLOPROOF_MAIL_FROM avec OLOPROOF_SMTP_URL ou OLOPROOF_RESEND_API_KEY) ou un fournisseur OAuth. Le web refuse de démarrer sans l'un d'eux. Puis lancez-le :

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

Le service migrate met la base de données à jour avant que le web et le worker démarrent. L'inscription se fait sur invitation, émise avec OLOPROOF_OPERATOR_TOKEN (deploy/README.md, « Signup »).

Configuration

.env.example liste toutes les variables que lisent le web et le worker, chacune marquée requise, générée ou optionnelle. Une variable optionnelle vide désactive sa fonction. Gardez les secrets générés : un nouveau mot de passe de base de données vous en ferme l'accès, et une nouvelle clé de signature démarre un nouveau signataire. Un paquet auto-hébergé n'a pas de facturation : chaque espace de travail a donc les volumes mensuels de cas de l'offre gratuite ; augmentez OLOPROOF_FREE_TIER_PUSHED_MONTHLY et OLOPROOF_FREE_TIER_MANAGED_MONTHLY pour votre équipe.

Aucun accès réseau sortant par défaut

La pile n'envoie aucune télémétrie et n'appelle aucun service d'Oloproof. Elle n'atteint le réseau que pour ce que vous activez : le courriel (un relais SMTP dans votre réseau, ou Resend), la connexion OAuth, Turnstile, et les fournisseurs de modèles pour lesquels un espace de travail stocke une clé. Sans aucun d'eux, elle tourne sans route vers l'extérieur. Pour un hôte isolé, copiez les trois images dans votre propre registre et faites pointer les variables d'image vers lui. Les comptes à mot de passe ont besoin du courriel ; sur un réseau isolé, réglez donc OLOPROOF_SMTP_URL sur un relais à l'intérieur.

Sauvegardes

sh backup.sh /srv/backups/oloproof

backup.sh écrit un pg_dump compressé dans le répertoire choisi. Planifiez-le avec cron ou un timer systemd, et copiez vous-même le répertoire hors de l'hôte. Le script affiche la commande de restauration.

La sauvegarde ne contient pas .env, et .env contient OLOPROOF_CONTENT_KEY et les autres secrets générés : sans lui, une base restaurée ne peut pas lire son contenu chiffré. Sauvegardez .env à sa création et à chaque modification, à part des sauvegardes et hors ligne (gestionnaire de mots de passe ou disque chiffré), jamais à côté d'elles.

Mises à jour

Écrivez les deux digests de la nouvelle version dans .env, puis lancez :

sh upgrade.sh /srv/backups/oloproof

Il sauvegarde, tire les images, migre et redémarre le web et le worker. Attendez-vous à une courte interruption. Pour revenir en arrière, écrivez les digests précédents et restaurez la sauvegarde qu'il a faite.

Ce qui est pris en charge

• Un seul hôte. Il n'y a pas de haute disponibilité : la pile est aussi disponible que sa machine.
• La résidence des données est là où vous la faites tourner. Oloproof ne détient aucune de vos données.
• Pas de mises en production sans interruption. Elles sont réservées au service hébergé.
• Le paquet est vérifié par deploy/self-hosted/check.sh, qui le démarre sous son propre nom de projet, attend /api/health, récupère les pages publiques et le supprime.