Déployer Sovrium sur Scalingo

Vous voulez un déploiement par git push sur un PaaS européen, avec une base gérée et aucun serveur à administrer.

Configurer l'application

Scalingo construit avec des buildpacks, pas avec votre Dockerfile : le dépôt a donc besoin de trois fichiers. .buildpacks sélectionne le buildpack Sovrium, qui télécharge le binaire publié et vérifié par somme de contrôle dans bin/. .sovrium-version fige la version à récupérer. Le Procfile la démarre.

# .buildpacks
https://github.com/sovrium/scalingo-buildpack

# .sovrium-version — la version à télécharger ; incrémentez-la pour mettre à jour
0.22.2

Figez la version de votre choix depuis la page des releases ; le buildpack en vérifie la somme de contrôle avant de l'installer. Une version inexistante fait échouer le build plutôt que de déployer quelque chose d'inattendu.

# Procfile
web: bin/sovrium start app.ts

Le préfixe bin/ a son importance : le buildpack installe le binaire dans l'arborescence de l'application, pas dans le PATH du système.

Ajoutez ensuite une base PostgreSQL gérée pour que l'app tourne sur Postgres au lieu du SQLite par défaut, puis définissez l'environnement :

scalingo --app my-app addons-add postgresql postgresql-starter-1024
scalingo --app my-app env-set \
  SOVRIUM_ENCRYPTION_KEY="$(openssl rand -hex 32)" \
  BASE_URL=https://my-app.osc-fr1.scalingo.io \
  NODE_ENV=production \
  TRUSTED_PROXY_HOPS=1

Choisissez le plan d'add-on adapté à vos données ; exécutez scalingo addons-plans postgresql pour consulter la liste à jour. NODE_ENV=production n'est pas cosmétique — cette variable fait basculer Sovrium en mise en cache immuable pour les ressources versionnées par empreinte de contenu. Sans elle, chaque ressource est retéléchargée à chaque affichage de page.

SOVRIUM_ENCRYPTION_KEY est le seul secret de cette liste, et elle est définie ici pour une raison qu'il vaut mieux connaître. Sovrium génère sa propre clé quand aucune n'est fournie, mais Scalingo reconstruit le système de fichiers du conteneur à chaque déploiement et à chaque redémarrage, tandis que la base managée conserve tout ce que cette clé a chiffré. Générée, la clé serait neuve à chaque fois et les identifiants stockés cesseraient de s'ouvrir. La définir une fois supprime le problème. Le secret de signature des sessions en dérive : il n'y a donc pas de seconde valeur à définir — voir Secrets.

TRUSTED_PROXY_HOPS=1 correspond au routeur de Scalingo, seul élément placé entre Internet et votre conteneur. Sovrium croit ainsi l'adresse client transmise par ce routeur, et les limites de débit comptent par visiteur au lieu de tout imputer à l'adresse du routeur. Ne l'augmentez que si vous placez votre propre CDN devant Scalingo, et jamais au-delà du nombre de proxies réellement sur le trajet — voir Reverse proxy en amont.

Scalingo injecte DATABASE_URL et PORT automatiquement — Sovrium lit les deux, aucun câblage supplémentaire n'est nécessaire.

Déployer et vérifier

Scalingo déploie depuis master. Poussez donc explicitement votre branche vers cette référence :

git push scalingo HEAD:refs/heads/master
curl -fsS https://my-app.osc-fr1.scalingo.io/ >/dev/null && echo "up"

Suite

• Infrastructure de base de données — comment DATABASE_URL bascule Sovrium vers Postgres.
• Migrations de schéma — l'évolution du schéma s'applique au démarrage du prochain déploiement.
• Variables d'environnement — les secrets à définir avec env-set.