Så självhostar du Ghost 2026: MySQL, nyhetsbrev och säkerhetskopiering av innehåll

En misslyckad Ghost-deployment kraschar inte alltid. Den kan visa en inloggningssida trots att url-inställningen är HTTP eller att content-volymen har ersatts. Börja i stället med en end-to-end-kontroll: slutför ägarinstallationen, publicera ett inlägg med en bild, prenumerera med en medlem och skicka ett testnyhetsbrev via den konfigurerade e-posttjänsten.

Kontrollen motsvarar Ghosts dokumenterade syfte: en publiceringsplattform med medlemskap och nyhetsbrev. Den avslöjar också saknade beroenden, felaktiga antaganden om proxyn och ephemeral data tidigare än en enkel uptime-kontroll kan göra.

Rita upp Ghosts runtime-gräns

Rita upp tre gränser runt Ghost: ingress till port 2368, beständigt tillstånd och stödkrav. Containern kan ersättas, men de två andra behöver tydliga ägare. Ghosts nätverkskontrakt omfattar MySQL 8, SMTP och valfri object storage för webbplatser med mycket media. Håll privata endpoints på intern DNS, tillåt endast nödvändiga utgående anrop och ge Ghost en avgränsad service credential.

Diagrammet är komplett när en ren klient kan slutföra ägarinstallationen, publicera ett inlägg med en bild, prenumerera med en medlem och skicka ett testnyhetsbrev via den konfigurerade e-posttjänsten. Samla in tids- och resursdata för MySQL-frågor, bildlagring, temarendering, medlemsantal och bulkmail-leverantörens gränser. Om transaktionen misslyckas visar den första gräns som inte beter sig enligt dokumentationen om du bör undersöka routing, lokal kapacitet eller en stödtjänst.

Verifiera att Ghost överlever ett byte

En container image kan laddas ned igen, men MySQL-databasen samt teman, bilder och innehållsfiler kan inte det. Montera /var/lib/ghost/content före bootstrap, skriv ofarliga testdata och ersätt containern för att bevisa att sökvägen faktiskt är beständig. Kontrollera den effektiva mounten i stället för att lita på ett Compose-filnamn, och verifiera att runtime-användaren kan skriva där Ghost förväntar sig det.

Välj retention och en destination utanför värdservern, och öva sedan på återställning utan att röra produktionen. Övningen är godkänd först när inlägg, medlemmar, nyhetsbrev, teman och bilder är tillbaka och en testmedlem kan öppna den återställda publikationen. För databaserat tillstånd kombinerar du storage snapshots med applikationskonsistenta exporter enligt beskrivningen i point-in-time recovery kontra snapshots.

Credentials, roller och exponerade ytor

Den applikationsspecifika säkerhetsrisken är att använda SQLite i en produktionstopologi som inte stöds eller att läcka e-postuppgifter. Det operativa svaret är att skydda Ghost Admin, hålla e-post- och databasuppgifter på serversidan och ange den slutliga HTTPS-URL:en innan publicering. Slutför bootstrap via en begränsad route och ta omedelbart bort tillfällig åtkomst till setup efteråt.

url är konfiguration, inte en hemlighet. Håll dess värde explicit samtidigt som du skyddar de separata uppgifter som Ghost använder. Ge Ghost-processen endast de dokumenterade mountsen och beroenderoutes; undvik åtkomst till hostens root och Docker-socketen. Logga misslyckade autentiseringsförsök och konfigurationsfel, men maskera tokens, connection strings och användarinnehåll.

Verifiera Ghost-deploymenten end to end

Release-dokumentationen för Ghost behöver fakta, inte ”ser bra ut”. Spara den valda image digest, container-användaren, konfigurationschecksumma, publika hostname och ett tidsstämplat resultat för följande: slutför ägarinstallationen, publicera ett inlägg med en bild, prenumerera med en medlem och skicka ett testnyhetsbrev via den konfigurerade e-posttjänsten. Använd testdata som inte hör till produktionen så att kontrollen kan köras efter varje deployment.

Verifiera två livscykelhändelser separat. Ett byte av container måste bevara normal drift; en ren återställning måste visa att inlägg, medlemmar, nyhetsbrev, teman och bilder är tillbaka och att en testmedlem kan öppna den återställda publikationen. Mät MySQL-frågor, bildlagring, temarendering, medlemsantal och bulkmail-leverantörens gränser medan kontrollerna körs, och spara resultatet som det förväntade intervallet för den här versionen.

Testa även ett nekad eller ogiltigt tillstånd: neka tillfälligt testidentiteten åtkomst till MySQL 8, SMTP och valfri object storage för webbplatser med mycket media. Ghost ska då misslyckas på ett diagnostiserbart sätt och inte skriva över ett friskt tillstånd. Återställ det giltiga tillståndet, kör testet igen och bifoga relevanta maskerade loggar. Dessa artefakter ger ett framtida rollback-beslut konkreta bevis.

En Docker-baslinje för Ghost

Håll den första Ghost-körningen tillräckligt reproducerbar för att kunna granskas i en 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

Förlita dig inte på latest när det finns riktiga data. Spara den fungerande digestens värde, container-användaren och mount-ägarskapet. Följ applikationsloggen genom ett komplett test — slutför ägarinstallationen, publicera ett inlägg med en bild, prenumerera med en medlem och skicka ett testnyhetsbrev via den konfigurerade e-posttjänsten — och notera eventuella migreringar innan du släpper routen bakom produktionstrafik.

TLS är enkelt – genererade URL:er är det inte

Ange url till den slutliga HTTPS-domänen innan publicering. Skicka det valda hostnamnet till containerport 2368, vidarebefordra den ursprungliga hosten och HTTPS-schemat och publicera inte en andra direkt origin.

Testa Ghost från en ren extern klient. Skilj ingressfel från den kända applikationsgränsen — url-inställningen är HTTP eller content-volymen har ersatts. Ett certifikat-, DNS- eller 502-fel hör till routing; en request som når Ghost men misslyckas senare hör till applikationens tillstånd, kapacitet eller ett stödkrav. Guiden för TLS med egen domän täcker den första gruppen.

Kapacitets- och uppgraderingskontroller

Kapacitetstester ska belasta MySQL-frågor, bildlagring, temarendering, medlemsantal och bulkmail-leverantörens gränser – inte bara upprepade anrop till /. Kör scenariot ”slutför ägarinstallationen, publicera ett inlägg med en bild, prenumerera med en medlem och skicka ett testnyhetsbrev via den konfigurerade e-posttjänsten” med realistisk concurrency och registrera latency, error rate och lagringstillväxt.

Uppgraderingsplaneringen måste ta hänsyn till den här risken: Ghost-migreringar, förväntningar på Node runtime och anpassade teman ska testas på en klonad webbplats. Testa den nya releasen med representativa indata, kör sedan acceptanstestet igen och jämför resultatet. Om url-inställningen är HTTP eller content-volymen har ersatts ska du dokumentera den misslyckade transaktionen och undersöka den första berörda gränsen i stället för att anta att ingressen är orsaken.

Flytta det repeterbara infrastrukturarbetet till Dockup

Routing, certifikat, service replacement och ansluten storage är rimliga mål för automation. Dockup hanterar detta för Ghost och kan provisionera den tillhörande managed-databasen eller ansluta till tjänster på kundens egen server.

Det Dockup inte ska hitta på är Ghosts trust policy. Efter deployment anger du url till den slutliga HTTPS-domänen innan publicering, verkställer denna gräns — skydda Ghost Admin, håll e-post- och databasuppgifter på serversidan och ange den slutliga HTTPS-URL:en innan publicering — och verifierar resultatet av följande scenario: slutför ägarinstallationen, publicera ett inlägg med en bild, prenumerera med en medlem och skicka ett testnyhetsbrev via den konfigurerade e-posttjänsten. Resultatet är infrastruktur med ett klick och ett applikationsspecifikt acceptanstest.

Vanliga frågor

Vad behöver Ghost för en produktionsdeployment?

Routa Ghost-containern via port 2368 genom en enda HTTPS-origin. Det stödjande nätverkskravet är MySQL 8, SMTP och valfri object storage för webbplatser med mycket media. Betrakta inte Ghost som redo förrän du kan slutföra ägarinstallationen, publicera ett inlägg med en bild, prenumerera med en medlem och skicka ett testnyhetsbrev via den konfigurerade e-posttjänsten.

Vilka Ghost-data ska ingå i en säkerhetskopia?

Gör /var/lib/ghost/content beständig och inkludera MySQL-databasen samt teman, bilder och innehållsfiler i samma återställningsmanifest. En ren Ghost-återställning är godkänd först när inlägg, medlemmar, nyhetsbrev, teman och bilder är tillbaka och en testmedlem kan öppna den återställda publikationen.

Kräver Ghost HTTPS bakom en reverse proxy?

Använd HTTPS för Ghosts publika origin och behåll port 2368 på den interna routen. Tillämpa Ghost-inställningen korrekt: ange url till den slutliga HTTPS-domänen innan publicering. För Ghost skyddar HTTPS credentials eller användarinnehåll under överföring och håller origin-känsligt klientbeteende konsekvent.

Hur bör en Ghost-uppgradering testas?

Återställ det aktuella Ghost-tillståndet i en isolerad deployment, tillämpa kandidatversionen och kör acceptanstestet igen. Var särskilt uppmärksam eftersom Ghost-migreringar, förväntningar på Node runtime och anpassade teman ska testas på en klonad webbplats. Behåll den tidigare Ghost-imagen tills gränserna för datamigrering och rollback är förstådda.