Déployer Sovrium avec Docker

Vous voulez exécuter une application Sovrium sur n'importe quel hôte doté de Docker, sans rien installer d'autre que l'image.

Lancer le conteneur

Montez votre config et un volume de données, et passez un seul secret. Sur le SQLite par défaut, toute la base de données vit dans le volume /data monté :

docker run -d --name my-app -p 3000:3000 \
  -v "$PWD/app.ts:/app/app.ts:ro" \
  -v my-app-data:/data \
  -e SOVRIUM_DATA_DIR=/data \
  -e NODE_ENV=production \
  -e SOVRIUM_ENCRYPTION_KEY="$(openssl rand -hex 32)" \
  -e BASE_URL=https://app.example.com \
  -e TRUSTED_PROXY_HOPS=1 \
  ghcr.io/sovrium/sovrium:latest start /app/app.ts

SOVRIUM_DATA_DIR est ce qui rend le volume utile. Sovrium écrit dans ./.sovrium par défaut — dans le conteneur, cela pointe vers /app/.sovrium, et non vers votre montage — un volume dépourvu de cette variable ne persiste donc rien.

Un seul secret, et la liste est complète. Le secret de signature des sessions dérive de SOVRIUM_ENCRYPTION_KEY : il n'y a donc aucune seconde valeur à générer, à ranger, ni à faire tourner en même temps.

La clé elle-même est optionnelle — Sovrium en génère une au premier démarrage et la conserve dans le répertoire de données. La passer explicitement, comme ci-dessus, reste la meilleure habitude pour un conteneur : elle demeure correcte même si le volume est ensuite supprimé, recréé, ou remplacé par une base externe. Générez-la une fois et rangez-la là où vous gardez vos autres secrets de déploiement, car une clé différente au prochain docker run rend illisible chaque jeton de connexion stocké. Voir Secrets.

NODE_ENV=production fait passer les ressources versionnées par empreinte de contenu en cache immuable. Sans cette variable, chaque ressource est retéléchargée à chaque affichage de page.

TRUSTED_PROXY_HOPS=1 va de pair avec l'URL de base en https:// ci-dessus : quelque chose termine TLS devant le conteneur, et c'est cette variable qui autorise Sovrium à croire l'adresse client que cet élément transmet. Sans elle, chaque requête se résout au proxy et tous les visiteurs partagent un seul budget de limitation. Repassez à 0 si vous publiez le port du conteneur directement sur Internet, et ne dépassez jamais le nombre de proxies réellement en place — voir Reverse proxy en amont.

Vérifier

curl -fsS http://localhost:3000/ >/dev/null && echo "up"

Le conteneur sert votre application sur le port 3000 ; la base SQLite et les fichiers téléversés persistent dans le volume my-app-data d'un redémarrage (et d'une mise à jour) à l'autre.

Suite

• Variables d'environnement — chaque secret et bascule passable avec -e.
• Infrastructure de base de données — rester sur SQLite ou pointer DATABASE_URL vers Postgres.
• Durcissement de la sécurité — la checklist production avant d'exposer le port.