Déployer Sovrium sur un VPS avec systemd et Caddy

Vous avez un VPS Linux et voulez que le binaire Sovrium tourne comme service géré avec HTTPS automatique — sans Docker.

L'exécuter comme service

Installez le binaire dans un chemin système fixe. Le script d'installation vise ~/.sovrium par défaut, ce qui ne convient pas à un service exécuté par un utilisateur dédié — pointez-le vers un emplacement stable :

sudo useradd --system --home /srv/app --shell /usr/sbin/nologin sovrium
sudo install -d -o sovrium -g sovrium /srv/app
sudo env SOVRIUM_INSTALL_DIR=/opt/sovrium sh -c \
  'curl -fsSL https://sovrium.com/install | sh -s -- --no-modify-path'

useradd --system ne crée pas le répertoire personnel : install -d n'est donc pas optionnel — sans lui, le service échoue au démarrage avec 200/CHDIR. La forme sudo env compte elle aussi : la politique sudoers par défaut refuse un sudo VAR=value … nu.

Le binaire atterrit alors dans /opt/sovrium/bin/sovrium. Placez votre configuration dans /srv/app/app.yaml — l'unité ci-dessous s'exécute avec /srv/app comme répertoire de travail, ExecStart la désigne donc par un chemin relatif.

Gardez les identifiants hors du fichier d'unité — tout ce qui se trouve dans /etc/systemd/system/ est lisible par tous. Placez plutôt l'environnement dans un fichier en mode 600, qui accueillera aussi les identifiants de fournisseurs le jour où vous en ajouterez :

sudo install -m 600 -o root -g root /dev/null /etc/sovrium.env
sudo sh -c 'cat > /etc/sovrium.env' <<'EOF'
PORT=3000
NODE_ENV=production
BASE_URL=https://app.example.com
SOVRIUM_DATA_DIR=/srv/app/.sovrium
TRUSTED_PROXY_HOPS=1
EOF

Le <<'EOF' entre quotes est délibéré : un heredoc non quoté développerait les substitutions dans votre shell avant même que sudo ne s'exécute.

Aucun secret dans ce fichier, et ce n'est pas un oubli. Cet hôte dispose d'un disque durable : au premier démarrage, Sovrium génère donc sa propre clé de chiffrement et l'écrit dans /srv/app/.sovrium/encryption-key — mode 0600, propriété de l'utilisateur du service, à côté de la base SQLite qu'elle protège. Le secret de signature des sessions dérive de cette clé : il n'y a rien d'autre à générer, ni à maintenir en cohérence.

Une obligation l'accompagne : le fichier de clé fait partie de votre sauvegarde. Emportez-le avec la base — une base restaurée sans sa clé laisse des identifiants stockés que plus personne ne peut déchiffrer. Le premier redémarrage confirme que la clé est stable : la bannière affiche Encryption key: from /srv/app/.sovrium/encryption-key, et non generated at.

Pour gérer la valeur vous-même, ajoutez plutôt SOVRIUM_ENCRYPTION_KEY à /etc/sovrium.env avant le premier démarrage : aucun fichier de clé ne sera écrit. Voir Secrets.

TRUSTED_PROXY_HOPS=1 indique à Sovrium que Caddy est la seule chose placée devant lui : l'adresse client transmise par Caddy est donc crue, et les limites de débit s'appliquent par visiteur. Sans cette variable, chaque requête semble venir de Caddy et tous vos visiteurs partagent un seul budget de limitation. Si vous ajoutez plus tard un CDN devant Caddy, passez à 2 — et jamais au-delà du nombre de proxies réellement en place. Voir Reverse proxy en amont.

Définissez ensuite l'unité :

# /etc/systemd/system/sovrium.service
[Unit]
Description=Sovrium
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=sovrium
Group=sovrium
WorkingDirectory=/srv/app
EnvironmentFile=/etc/sovrium.env
ExecStart=/opt/sovrium/bin/sovrium start app.yaml
Restart=on-failure
RestartSec=5

# Durcissement
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=strict
ReadWritePaths=/srv/app
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictSUIDSGID=true
LockPersonality=true
CapabilityBoundingSet=

[Install]
WantedBy=multi-user.target

ProtectSystem=strict rend l'ensemble du système de fichiers en lecture seule, à l'exception des chemins listés dans ReadWritePaths : SOVRIUM_DATA_DIR doit donc se trouver sous /srv/app. Sur un hôte qui fait tourner plusieurs applications, ajoutez MemoryMax= pour qu'un processus emballé ne puisse pas emporter ses voisins.

Placez Caddy devant pour le TLS — il récupère et renouvelle le certificat pour vous. Installez-le d'abord si l'hôte ne l'a pas :

sudo apt install -y caddy   # nécessite d'abord le dépôt apt de Caddy — voir caddyserver.com/docs/install

Remplacez ensuite le site par défaut par le vôtre :

# /etc/caddy/Caddyfile
app.example.com {
  reverse_proxy localhost:3000
}

Faites pointer app.example.com vers l'IP publique du serveur avant de recharger — Caddy émet le certificat à la première requête, et le défi ACME échoue sans DNS fonctionnel.

Vérifier

sudo systemctl enable --now sovrium && sudo systemctl reload caddy
sudo grep -c . /etc/sovrium.env    # 5 attendu — toutes les variables sont bien là
curl -fsS https://app.example.com/ >/dev/null && echo "up"

Suite

• Référence CLI — start, reload et les options utilisables par l'unité.
• Durcissement de la sécurité — pare-feu, utilisateur non-root et gestion des secrets.
• Variables d'environnement — tout ce que le bloc [Service] peut définir.