Référence de déploiement EmDash CMS en auto-hébergement Node

Publié le 2026-04-08 par Emdash Cms Everything

Quand l’auto-hébergement est le bon choix

Choisissez l’auto-hébergement lorsque vos contraintes sont opérationnelles, juridiques ou architecturales :

• exigences strictes de résidence des données
• vous exploitez déjà des services de plateforme partagés en interne
• vous avez besoin d’un contrôle total sur le runtime, le modèle de processus et les chemins réseau
• vous voulez éviter le couplage cloud managé aux premiers stades

L’auto-hébergement n’est pas automatiquement moins cher. Il est en général plus contrôlable.

Modèle de progression recommandé

Ne commencez pas par la complexité maximale. Utilisez un déploiement par étapes :

1. Node.js + SQLite + stockage fichier local
2. PostgreSQL pour la sécurité multi-instance et une durabilité renforcée
3. Stockage objet compatible S3 pour la portabilité des médias
4. Supervision des processus et durcissement de l’observabilité

Cette séquence minimise le choc de migration tout en gardant un chemin de production propre.

Architecture de base (étape 1)

Pour une production sur un seul nœud ou un lancement anticipé :

• runtime applicatif : adaptateur Node (standalone)
• base de données : fichier SQLite sur disque persistant
• médias : répertoire local des téléversements
• reverse proxy : Nginx ou Caddy

Cette configuration suffit pour des charges éditoriales faibles à modérées avec une instance runtime.

# Build et exécution en production
npm install
npm run build
npm run start

Critères de passage à l’étape 2 (PostgreSQL)

Montez de niveau côté base lorsque l’un de ces signes apparaît :

• contention d’écriture concurrente fréquente
• objectifs de sauvegarde / restauration dépassant la stratégie de copie de fichier
• besoin d’un déploiement multi-instance plus sûr

Utilisez PostgreSQL avant d’ajouter une montée en charge horizontale de l’application. Faire tourner plusieurs nœuds d’app sur SQLite crée vite un risque opérationnel.

Stratégie de stockage : fichiers locaux vs stockage objet

Fichiers locaux (commencer ici)

Adapté aux environnements à instance unique avec croissance de stockage prévisible.

Stockage objet compatible S3 (passer ici pour la montée en charge)

À utiliser lorsque :

• plusieurs instances d’application ont besoin d’un accès média partagé
• la sauvegarde et la reprise après sinistre doivent être standardisées
• la stratégie CDN et cache edge dépend d’URL d’objets stables

MinIO peut être utilisé sur infrastructure privée pour un comportement compatible S3.

Processus runtime et base du proxy

Gestion des processus

Utilisez l’un des suivants :

• systemd pour le contrôle de service natif Linux
• pm2 pour les équipes qui veulent des métriques processus et des redémarrages rapides

Reverse proxy

Terminez le TLS au proxy et transmettez vers l’app Node :

• préserver les en-têtes Host et X-Forwarded-*
• configurer le chemin de health check
• définir des limites de taille de corps alignées sur la politique de téléversement

Politique de sauvegarde et de restauration

Traitez la politique de sauvegarde comme bloquante au lancement, pas comme tâche post-lancement.

Minimum :

• instantanés de base de données planifiés
• sauvegardes ou réplication du stockage médias
• au moins un exercice de restauration avant le lancement public

Une sauvegarde jamais restaurée en test est une rumeur, pas un contrôle.

Liste de contrôle de préparation opérationnelle

Avant la bascule en production, confirmez :

• le redémarrage à froid fonctionne sans modification manuelle
• les journaux applicatifs sont centralisés et consultables
• l’alerting sur les 5xx est actif
• l’usage disque et la croissance du stockage sont surveillés
• le processus de rotation des secrets est documenté

Notes de migration depuis une configuration orientée Cloudflare

Si le projet a commencé avec des hypothèses Cloudflare :

• retirer les liaisons réservées au cloud de la config runtime
• remplacer les adaptateurs D1/R2 par des adaptateurs base de données et stockage compatibles Node
• revalider l’auth et les URLs de callback derrière votre reverse proxy

Le risque de migration est surtout dans les hypothèses d’environnement, pas dans le code au niveau des pages.

Cadre de décision pour les équipes

Utilisez cette règle :

• si vous voulez de la vitesse et peu d’ops, privilégiez le chemin cloud managé
• si vous voulez le contrôle et l’intégration à l’infra existante, privilégiez l’auto-hébergement

Choisissez un chemin par défaut par environnement. Les modèles hybrides sont possibles, mais ils augmentent la charge cognitive et le support.