Héberger Ghost sur VPS : guide complet 2026

Ghost combine ce que WordPress fait laborieusement et ce que Substack facture cher : un éditeur épuré, des performances natives excellentes (Node.js), une gestion de membres et d'abonnements payants intégrée via Stripe, et l'envoi de newsletters sans plugin. Mais Ghost(Pro) facture à l'audience, et les plateformes de newsletter prennent une commission sur vos revenus.

En l'hébergeant sur votre VPS, vous gardez 100 % de vos abonnés payants (hors frais Stripe), vous personnalisez le thème sans restriction, et vous maîtrisez votre liste d'emails — votre actif le plus précieux. Avec Ghost v6, les créateurs qui monétisent leurs newsletters bénéficient aussi de la collecte automatique de la TVA via Stripe Tax, sans aucune dépendance à un service tiers.

Ghost v6 tourne sur Node.js 20 LTS minimum (Node 22 recommandé pour les performances). Prévoyez un VPS avec au moins 1 vCPU et 2 Go de RAM pour un blog avec un trafic confortable ; montez à 4 Go si votre audience grandit vite ou si vous activez les newsletters volumineuses. Pour un usage de production, réservez 20 Go de disque minimum pour les médias et la base de données.

La base de données recommandée en production est MySQL 8 (SQLite n'est supporté qu'en développement — voir la section dépannage). Il vous faut aussi un service SMTP transactionnel (Mailgun, Postmark, Brevo) pour l'envoi fiable des newsletters et des emails d'authentification des membres, un domaine blog.votredomaine.com pointé sur l'IP de votre VPS, et Caddy ou Nginx pour le reverse proxy HTTPS. Caddy est préférable : il provisionne et renouvelle les certificats Let's Encrypt sans configuration supplémentaire.

Une fois le Caddyfile écrit, démarrez ou rechargez Caddy pour appliquer la configuration :

caddy run --config /etc/caddy/Caddyfile

Si Caddy est géré en tant que service systemd (ce qui est le cas après une installation via APT), préférez la commande de rechargement sans interruption :

systemctl reload caddy

Caddy contacte immédiatement Let's Encrypt pour obtenir un certificat TLS pour votre domaine via le challenge HTTP-01. Dans les 30 secondes, https://blog.votredomaine.com doit répondre. Vérifiez l'état du certificat :

curl -sv https://blog.votredomaine.com/ 2>&1 | grep -E 'SSL|subject|issuer'

Si la commande affiche un issuer: O=Let's Encrypt, le certificat est valide. En cas d'erreur connection refused, vérifiez que Ghost tourne bien sur le port 2368 avec ghost status depuis le répertoire d'installation. Si le port 443 est fermé dans votre pare-feu, ouvrez-le avant de lancer Caddy : ufw allow 443.

Ghost v6 introduit la prise en charge du champ tax_id_collection de l'API Stripe. Ce champ permet à Stripe Tax de collecter automatiquement le numéro de TVA ou d'identification fiscale de l'acheteur au moment du paiement, conformément aux réglementations européennes et mondiales.

Pour les instances existantes migrées vers Ghost v6, cette fonctionnalité est une configuration de votre côté Stripe, pas un changement dans Ghost lui-même. Deux points à vérifier :

1. Dans le Dashboard Stripe, activez Stripe Tax et configurez vos règles fiscales par pays.
2. Dans Stripe → Checkout → Paramètres, activez la collecte du numéro fiscal si requis pour votre marché.

Les instances Ghost v5 qui mettent à jour vers v6 sans ajuster leurs paramètres Stripe continueront à fonctionner, mais les nouvelles fonctions de conformité fiscale resteront inactives tant que vous n'aurez pas configuré Stripe Tax de votre côté.

Ghost CLI simplifie les mises à jour majeures et mineures. Depuis le répertoire d'installation :

cd /var/www/ghost
ghost update

Pour cibler une version spécifique, par exemple lors d'une migration v5 → v6 :

ghost update 6.x.x

Ghost CLI arrête le process PM2, applique les migrations de base de données, met à jour les fichiers et redémarre Ghost. Si une migration échoue, Ghost CLI effectue un rollback automatique et affiche le détail de l'erreur dans le terminal.

Avant toute mise à jour majeure (v5 → v6), deux gestes préventifs sont indispensables : sauvegardez le répertoire de contenu /var/www/ghost/content (médias et thèmes personnalisés) et exportez la base MySQL :

mysqldump -u ghost -p ghost_db > ghost_backup_$(date +%F).sql

Enfin, vérifiez la version installée après la mise à jour :

ghost version

Un numéro de version incorrect après une mise à jour signale généralement un problème de permissions sur le répertoire /var/www/ghost — vérifiez que l'utilisateur dédié est bien propriétaire du dossier.

Ghost démarre mais retourne une page blanche ou une erreur 500
Vérifiez les logs avec ghost log. La cause la plus fréquente est une valeur url incorrecte dans config.production.json — Ghost génère tous ses liens internes à partir de cette valeur, et une URL en HTTP alors que Caddy sert en HTTPS provoque des boucles de redirection.

Erreur « ER_NOT_SUPPORTED_AUTH_MODE » au démarrage
Ghost v6 requiert MySQL 8 avec le plugin d'authentification mysql_native_password. Si votre MySQL est configuré en caching_sha2_password par défaut, modifiez l'utilisateur :

ALTER USER 'ghost'@'localhost' IDENTIFIED WITH mysql_native_password BY 'votre_mot_de_passe';
FLUSH PRIVILEGES;

SQLite en production : pourquoi ce n'est pas une option
Ghost accepte SQLite en mode développement, mais ce moteur n'est pas supporté en production : il ne gère pas les accès concurrents, et les newsletters volumineuses ou les pics de trafic provoquent des verrous de base irréversibles. Migrez vers MySQL avant de mettre votre instance en ligne.

L'upload de thème échoue en production
Ghost limite la taille des uploads de thèmes. Si l'upload échoue en silence ou retourne une erreur 413, ajustez la limite côté Caddy :

blog.votredomaine.com {
    request_body {
        max_size 50MB
    }
    reverse_proxy localhost:2368
}

MAIL_FROM mal configuré : membres qui ne reçoivent pas d'email
Le champ mail.from dans config.production.json doit porter une adresse dont le domaine est vérifié chez votre fournisseur SMTP (enregistrements SPF, DKIM actifs). Un domaine non vérifié aboutit à des silences à l'inscription ou à des rejets SMTP que Ghost signale rarement clairement dans ses logs.

Depuis mai 2026, les instances Ghost 6.28.0 sur Node 22 échouent à se mettre à jour avec l'erreur npm error code ENOTSUP / Cannot find matching keyid. La cause : corepack ≥ 2.x introduit une vérification de signature des paquets pnpm que les versions antérieures de corepack (≤ 0.30.x) ne savent pas résoudre sous Node 22. Ghost CLI s'arrête à l'étape corepack enable, avant même que npm installe les dépendances, laissant l'instance bloquée sur la version installée.

Le problème touche tous les environnements Docker ≥ Node 22 et a été rapporté sur le forum Ghost (fils t/62860 et t/62805, ouverts respectivement les 13 et 6 mai 2026) avec plus de 40 réponses confirmant le phénomène. Ghost CLI a depuis publié une version corrigée qui affiche les instructions de remédiation.