Comment auto-héberger Ghost en 2026 : MySQL, newsletters et sauvegardes de contenu

Un déploiement Ghost défaillant ne tombe pas forcément en panne. Il peut afficher une page de connexion alors que le paramètre url utilise HTTP ou que le volume de contenu a été remplacé. Commencez plutôt par un contrôle de bout en bout : terminer la configuration du propriétaire, publier un article avec une image, inscrire un membre et envoyer une newsletter de test via l’adresse e-mail configurée.

Ce contrôle correspond à la finalité répertoriée de Ghost : une plateforme de publication avec gestion des memberships et des newsletters. Il révèle également plus tôt les dépendances manquantes, les hypothèses incorrectes concernant le proxy et les données éphémères qu’un simple contrôle de disponibilité.

Définir le périmètre d’exécution de Ghost

Définissez trois périmètres autour de Ghost : l’ingress vers le port 2368, l’état durable et les prérequis de support. Le conteneur peut être remplacé, mais les deux autres éléments doivent avoir des responsables explicites. Le contrat réseau de Ghost repose sur MySQL 8, SMTP et, pour les sites utilisant beaucoup de médias, un stockage objet facultatif. Gardez les endpoints privés sur un DNS interne, n’autorisez que les appels sortants nécessaires et attribuez à Ghost un identifiant de service aux permissions limitées.

Le schéma est complet lorsqu’un client vierge peut terminer la configuration du propriétaire, publier un article avec une image, inscrire un membre et envoyer une newsletter de test via l’adresse e-mail configurée. Collectez les données de durée et de ressources pour les requêtes MySQL, le stockage des images, le rendu du thème, le nombre de membres et les limites du fournisseur d’envoi d’e-mails en masse. Si la transaction échoue, le premier périmètre qui ne se comporte pas comme prévu indique s’il faut examiner le routage, la capacité locale ou un service de support.

Vérifier que Ghost résiste au remplacement

Une image de conteneur peut être téléchargée à nouveau ; la base de données MySQL ainsi que les thèmes, les images et les fichiers de contenu ne le peuvent pas. Montez /var/lib/ghost/content avant le bootstrap, écrivez des données d’exemple sans danger, puis remplacez le conteneur pour vérifier que ce chemin est bien persistant. Inspectez le montage effectif au lieu de faire confiance à un nom de fichier Compose, et vérifiez que l’utilisateur d’exécution peut écrire là où Ghost l’attend.

Choisissez une politique de rétention et une destination hors hôte, puis répétez la procédure de restauration sans toucher à la production. Le test n’est réussi que lorsque les articles, les membres, les newsletters, les thèmes et les images sont restaurés et qu’un membre de test peut ouvrir la publication restaurée. Pour les données adossées à une base, associez les snapshots du stockage à des exports cohérents avec l’application, comme indiqué dans restauration à un instant donné ou snapshots.

Identifiants, rôles et surfaces exposées

Le risque de sécurité propre à l’application consiste à utiliser SQLite dans une architecture de production non prise en charge ou à exposer les identifiants de messagerie. La réponse opérationnelle consiste à protéger Ghost Admin, à conserver les identifiants de messagerie et de base de données côté serveur et à définir l’URL HTTPS finale avant toute publication. Effectuez le bootstrap via une route restreinte et supprimez immédiatement l’accès temporaire à la fin de l’opération.

url est un paramètre de configuration, pas un secret ; gardez sa valeur explicite tout en protégeant les identifiants distincts utilisés par Ghost. Accordez au processus Ghost uniquement les montages et les routes vers les dépendances documentés ; évitez tout accès à la racine de l’hôte et au socket Docker. Journalisez les échecs d’authentification et les erreurs de configuration, mais masquez les tokens, les chaînes de connexion et le contenu utilisateur.

Vérifier le déploiement Ghost de bout en bout

Le compte rendu de mise en production de Ghost doit contenir des faits, pas un simple « ça fonctionne ». Enregistrez le digest de l’image sélectionnée, la checksum de configuration, le hostname public et le résultat horodaté des opérations suivantes : terminer la configuration du propriétaire, publier un article avec une image, inscrire un membre et envoyer une newsletter de test via l’adresse e-mail configurée. Utilisez des données d’exemple hors production afin que le contrôle puisse être exécuté après chaque déploiement.

Vérifiez séparément deux événements du cycle de vie. Le remplacement d’un conteneur doit préserver le fonctionnement normal ; une restauration complète doit montrer que les articles, les membres, les newsletters, les thèmes et les images sont restaurés et qu’un membre de test peut ouvrir la publication restaurée. Pendant les contrôles, mesurez les requêtes MySQL, le stockage des images, le rendu du thème, le nombre de membres et les limites du fournisseur d’envoi d’e-mails en masse, puis conservez le résultat comme enveloppe de référence pour cette version.

Testez également une condition de refus ou d’invalidité : refusez temporairement à l’identité de test l’accès à MySQL 8, à SMTP et au stockage objet facultatif pour les sites utilisant beaucoup de médias. Ghost doit échouer de manière diagnosable et ne doit pas écraser un état sain. Rétablissez la condition valide, relancez l’exemple et joignez les journaux pertinents après masquage. Ces artefacts fournissent des éléments concrets pour une future décision de rollback.

Une configuration Docker de base pour Ghost

Conservez une commande d’initialisation Ghost suffisamment reproductible pour pouvoir être examinée dans une pull request.

docker run -d \
  --name ghost \
  --restart unless-stopped \
  -p 127.0.0.1:2368:2368 \
  -v ghost-data:/var/lib/ghost/content \
  -e url=https://app.example.com \
  -e database__client=mysql \
  -e database__connection__host=mysql.internal \
  -e database__connection__user=ghost \
  -e database__connection__password=replace-with-a-strong-database-password \
  -e database__connection__database=ghost \
  ghost:latest

Ne vous fiez pas à latest une fois que de vraies données existent. Notez le digest fonctionnel, l’utilisateur du conteneur et les droits du propriétaire du montage. Suivez le journal de l’application pendant un test complet — terminer la configuration du propriétaire, publier un article avec une image, inscrire un membre et envoyer une newsletter de test via l’adresse e-mail configurée — et notez les éventuelles migrations avant d’exposer la route au trafic de production.

Le TLS est simple ; les URL générées, non

Définissez url avec le domaine HTTPS final avant toute publication. Envoyez le hostname choisi vers le port 2368 du conteneur, transmettez l’hôte d’origine et le schéma HTTPS, et évitez de publier un second origin direct.

Testez Ghost depuis un client externe vierge. Distinguez un échec de l’ingress de la limite applicative connue — le paramètre url utilise HTTP ou le volume de contenu a été remplacé. Une erreur de certificat, de DNS ou de type 502 relève du routage ; une requête qui atteint Ghost puis échoue relève de l’état de l’application, de la capacité ou de l’un de ses prérequis. Le guide TLS pour domaine personnalisé couvre le premier groupe.

Contrôles de capacité et de mise à niveau

Les tests de capacité doivent solliciter les requêtes MySQL, le stockage des images, le rendu du thème, le nombre de membres et les limites du fournisseur d’envoi d’e-mails en masse, et non envoyer en boucle une requête vers /. Exécutez le scénario « terminer la configuration du propriétaire, publier un article avec une image, inscrire un membre et envoyer une newsletter de test via l’adresse e-mail configurée » avec une concurrence réaliste, puis relevez la latence, le taux d’erreur et la croissance du stockage.

La planification des mises à niveau doit tenir compte du risque suivant : les migrations Ghost, les prérequis du runtime Node et les thèmes personnalisés doivent être testés sur un site cloné. Testez la nouvelle version avec des données représentatives, puis répétez la transaction d’acceptation et comparez le résultat. Si le paramètre url utilise HTTP ou si le volume de contenu a été remplacé, capturez la transaction en échec et examinez le premier périmètre concerné au lieu de supposer que l’ingress est responsable.

Transférer les tâches d’infrastructure répétables vers Dockup

Le routage, les certificats, le remplacement des services et le stockage attaché sont de bonnes cibles pour l’automatisation. Dockup les gère pour Ghost et peut provisionner la base de données managée associée ou se connecter à des services exécutés sur le serveur du client.

Ce qu’il ne doit pas inventer, c’est la politique de confiance de Ghost. Après le déploiement, définissez url avec le domaine HTTPS final avant toute publication, appliquez cette règle — protéger Ghost Admin, conserver les identifiants de messagerie et de base de données côté serveur et définir l’URL HTTPS finale avant toute publication — puis vérifiez le résultat de ce scénario : terminer la configuration du propriétaire, publier un article avec une image, inscrire un membre et envoyer une newsletter de test via l’adresse e-mail configurée. Le résultat est une infrastructure en un clic accompagnée d’un test d’acceptation propre à l’application.

Foire aux questions

De quoi Ghost a-t-il besoin pour un déploiement en production ?

Acheminez le conteneur Ghost sur le port 2368 via un unique origin HTTPS. Le prérequis réseau associé est MySQL 8, SMTP et, pour les sites utilisant beaucoup de médias, un stockage objet facultatif. Ne considérez pas Ghost comme prêt tant que vous ne pouvez pas terminer la configuration du propriétaire, publier un article avec une image, inscrire un membre et envoyer une newsletter de test via l’adresse e-mail configurée.

Quelles données Ghost doivent être incluses dans une sauvegarde ?

Rendez /var/lib/ghost/content persistant et incluez la base de données MySQL ainsi que les thèmes, les images et les fichiers de contenu dans le même manifeste de restauration. Une restauration complète de Ghost n’est réussie que lorsque les articles, les membres, les newsletters, les thèmes et les images sont restaurés et qu’un membre de test peut ouvrir la publication restaurée.

Ghost nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origin public de Ghost et gardez le port 2368 sur la route interne. Appliquez correctement le paramètre Ghost : définissez url avec le domaine HTTPS final avant toute publication. Pour Ghost, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transmission et garantit un comportement cohérent des clients dépendant de l’origin.

Comment tester une mise à niveau de Ghost ?

Restaurez l’état actuel de Ghost dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif aux migrations Ghost, aux prérequis du runtime Node et aux thèmes personnalisés, qui doivent être testés sur un site cloné. Conservez l’image Ghost précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.