Journal-indexDockup / praktijknotitie
Note / self-host-ghost

Ghost zelf hosten in 2026: MySQL, nieuwsbrieven en contentback-ups

Een praktische handleiding voor het zelf hosten van Ghost met aandacht voor Docker, poorten, persistente data, TLS, beveiliging, back-ups en problemen die productiegebruik blokkeren. Stap voor stap.

Een mislukte Ghost-deployment crasht niet altijd. Het kan zijn dat er een loginpagina wordt weergegeven terwijl de url-instelling HTTP is of het contentvolume is vervangen. Begin daarom met een end-to-end-controle: voltooi de configuratie van de eigenaar, publiceer een bericht met een afbeelding, schrijf een member in en verstuur via de geconfigureerde e-mail een testnieuwsbrief.

Die controle sluit aan bij het vastgelegde doel van Ghost: een publishingplatform met memberships en nieuwsbrieven. Ook worden ontbrekende dependencies, verkeerde aannames over de proxy en vluchtige data eerder zichtbaar dan met een uptime-probe.

Breng de runtimegrens van Ghost in kaart

Breng drie grenzen rond Ghost in kaart: ingress naar poort 2368, persistente state en ondersteunende vereisten. De container kan worden vervangen, maar voor de andere twee moeten expliciete verantwoordelijken worden aangewezen. Het netwerkcontract voor Ghost bestaat uit MySQL 8, SMTP en optionele object storage voor sites met veel media. Houd private endpoints op interne DNS, sta alleen vereiste uitgaande verbindingen toe en geef Ghost een servicecredential met beperkte scope.

Het diagram is compleet wanneer een schone client de configuratie van de eigenaar kan voltooien, een bericht met een afbeelding kan publiceren, een member kan inschrijven en via de geconfigureerde e-mail een testnieuwsbrief kan versturen. Leg timing- en resourcegegevens vast voor MySQL-query's, afbeeldingsopslag, theme-rendering, het aantal members en de limieten van de bulkmailprovider. Als de transactie mislukt, laat de eerste grens die zich niet gedraagt zoals gedocumenteerd zien of je routing, lokale capaciteit of een ondersteunende service moet onderzoeken.

Toon aan dat Ghost vervanging overleeft

Een container image kan opnieuw worden gedownload; de MySQL-database plus themes, afbeeldingen en contentbestanden niet. Koppel /var/lib/ghost/content voordat je bootstrap uitvoert, schrijf onschuldige voorbeelddata en vervang de container om te bewijzen dat dat pad daadwerkelijk persistent is. Controleer de effectieve mount in plaats van blind te vertrouwen op een Compose-bestandsnaam, en controleer of de runtimegebruiker kan schrijven op de locatie die Ghost verwacht.

Kies een retentiebeleid en een bestemming buiten de host en oefen vervolgens het herstel zonder productie aan te raken. De oefening slaagt alleen wanneer berichten, members, nieuwsbrieven, themes en afbeeldingen terugkeren en een testmember de herstelde publicatie kan openen. Combineer bij state die door een database wordt beheerd storage snapshots met applicatieconsistente exports, zoals beschreven in point-in-time recovery versus snapshots.

Credentials, rollen en blootgestelde oppervlakken

Het applicatiespecifieke beveiligingsrisico bestaat uit het gebruik van SQLite in een niet-ondersteunde productietopologie of het lekken van mailcredentials. Het operationele antwoord is Ghost Admin beschermen, mail- en databasecredentials server-side houden en de definitieve HTTPS-URL instellen voordat je publiceert. Voltooi de bootstrap via een beperkte route en verwijder tijdelijke toegang tot de setup onmiddellijk daarna.

url is configuratie en geen secret; houd de waarde expliciet en bescherm de afzonderlijke credentials die Ghost gebruikt. Geef het Ghost-proces alleen de gedocumenteerde mounts en dependency-routes; vermijd toegang tot de hostroot en de Docker-socket. Log mislukte authenticatie en configuratiefouten, maar maskeer tokens, connection strings en gebruikerscontent.

Test de Ghost-deployment end-to-end

Het releaseverslag voor Ghost moet feiten bevatten, geen “ziet er goed uit”. Sla de geselecteerde image-digest, configuratiechecksum, publieke hostname en een resultaat met timestamp op voor: de configuratie van de eigenaar voltooien, een bericht met een afbeelding publiceren, een member inschrijven en via de geconfigureerde e-mail een testnieuwsbrief versturen. Gebruik niet-productievoorbeelddata zodat de controle na iedere deployment kan worden uitgevoerd.

Test twee lifecycle-gebeurtenissen afzonderlijk. Een containervervanging moet de normale werking behouden; een schoon herstel moet aantonen dat berichten, members, nieuwsbrieven, themes en afbeeldingen terugkeren en dat een testmember de herstelde publicatie kan openen. Meet tijdens de controles MySQL-query's, afbeeldingsopslag, theme-rendering, het aantal members en de limieten van de bulkmailprovider en bewaar het resultaat als de verwachte bandbreedte voor deze versie.

Test ook een geweigerde of ongeldige toestand: weiger tijdelijk de toegang van de testidentiteit tot MySQL 8, SMTP en optionele object storage voor sites met veel media. Ghost moet op een diagnoseerbare manier falen en mag geen gezonde state overschrijven. Herstel de geldige toestand, voer het voorbeeld opnieuw uit en voeg de relevante gemaskeerde logs toe. Die artefacten leveren concreet bewijs voor een toekomstige rollbackbeslissing.

Een Docker-basis voor Ghost

Houd de eerste Ghost-aanroep voldoende reproduceerbaar om in een pull request te kunnen worden nagekeken.

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

Vertrouw niet op latest zodra er echte data bestaat. Leg de werkende digest, de containergebruiker en het eigenaarschap van de mount vast. Volg het applicatielogboek tijdens een volledige test — de configuratie van de eigenaar voltooien, een bericht met een afbeelding publiceren, een member inschrijven en via de geconfigureerde e-mail een testnieuwsbrief versturen — en noteer eventuele migraties voordat je de route achter production traffic plaatst.

TLS is eenvoudig; gegenereerde URL's niet

Stel url vóór het publiceren in op het definitieve HTTPS-domein. Stuur de gekozen hostname naar containerpoort 2368, stuur de oorspronkelijke host en het HTTPS-schema door en publiceer geen tweede directe origin.

Test Ghost vanaf een schone externe client. Maak onderscheid tussen een ingressfout en de bekende applicatiegrens — de url-instelling is HTTP of het contentvolume is vervangen. Een certificaat-, DNS- of 502-fout hoort bij routing; een request dat Ghost bereikt en daarna faalt, hoort bij applicatiestate, capaciteit of een ondersteunende vereiste. De handleiding voor TLS met een custom domain behandelt de eerste groep.

Capaciteits- en upgradecontroles

Capaciteitstests moeten MySQL-query's, afbeeldingsopslag, theme-rendering, het aantal members en de limieten van de bulkmailprovider belasten, niet herhaaldelijk een request naar / uitvoeren. Voer het scenario “de configuratie van de eigenaar voltooien, een bericht met een afbeelding publiceren, een member inschrijven en via de geconfigureerde e-mail een testnieuwsbrief versturen” uit met realistische concurrency en leg latency, foutpercentage en groei van de opslag vast.

Bij de upgradeplanning moet met dit risico rekening worden gehouden: Ghost-migraties, verwachtingen rond de Node-runtime en custom themes moeten op een gekloonde site worden getest. Test de nieuwe release met representatieve input, voer daarna de acceptatietransactie opnieuw uit en vergelijk het resultaat. Als de url-instelling HTTP is of het contentvolume is vervangen, leg dan de mislukte transactie vast en onderzoek de eerste betrokken grens in plaats van ervan uit te gaan dat ingress verantwoordelijk is.

Verplaats herhaalbaar infrastructuurwerk naar Dockup

Routing, certificaten, het vervangen van services en gekoppelde storage zijn redelijke doelen voor automatisering. Dockup regelt dit voor Ghost en kan de bijbehorende managed database inrichten of verbinding maken met services op de eigen server van een klant.

Wat het niet moet verzinnen, is het trustbeleid van Ghost. Stel na de deployment url in op het definitieve HTTPS-domein voordat je publiceert, handhaaf deze grens — bescherm Ghost Admin, houd mail- en databasecredentials server-side en stel de definitieve HTTPS-URL in voordat je publiceert — en controleer het resultaat van dit scenario: de configuratie van de eigenaar voltooien, een bericht met een afbeelding publiceren, een member inschrijven en via de geconfigureerde e-mail een testnieuwsbrief versturen. Het resultaat is infrastructuur met één klik en een applicatiespecifieke acceptatietest.

Veelgestelde vragen

Wat heeft Ghost nodig voor een productiedeployment?

Routeer de Ghost-container op poort 2368 via één HTTPS-origin. De ondersteunende netwerkvereisten zijn MySQL 8, SMTP en optionele object storage voor sites met veel media. Beschouw Ghost pas als klaar wanneer je de configuratie van de eigenaar kunt voltooien, een bericht met een afbeelding kunt publiceren, een member kunt inschrijven en via de geconfigureerde e-mail een testnieuwsbrief kunt versturen.

Welke Ghost-data hoort in een back-up?

Maak /var/lib/ghost/content persistent en neem de MySQL-database plus themes, afbeeldingen en contentbestanden op in hetzelfde herstelmanifest. Een schone Ghost-restore slaagt alleen wanneer berichten, members, nieuwsbrieven, themes en afbeeldingen terugkeren en een testmember de herstelde publicatie kan openen.

Heeft Ghost HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Ghost-origin en houd poort 2368 op de interne route. Pas de Ghost-instelling correct toe: stel url vóór het publiceren in op het definitieve HTTPS-domein. Voor Ghost beschermt HTTPS credentials of gebruikerscontent tijdens het transport en zorgt het ervoor dat clientgedrag dat afhankelijk is van de origin consistent blijft.

Hoe moet een Ghost-upgrade worden getest?

Herstel de huidige Ghost-state in een geïsoleerde deployment, pas de kandidaatversie toe en voer de acceptatietransactie opnieuw uit. Let hier extra op, omdat Ghost-migraties, verwachtingen rond de Node-runtime en custom themes op een gekloonde site moeten worden getest. Bewaar de vorige Ghost-image totdat de grenzen voor datamigratie en rollback duidelijk zijn.