Ein Wow-Effekt. Tagelang rumgemurxt mit Docker Compose. Immer Probleme mit Mailversand, nicht starten wollende Container, etc.

Heute nun der absulute Knaller. Ghost nativ installiert, ein paar Daten in der Mail Section der config.production.json ergänzt und die Sache lief.

• Ghost nativ → liest die config.production.json zuverlässig
• systemd → startet sauber, meckert sofort, wenn etwas nicht stimmt
• SES via SMTP → Ghost liebt das, null Magie, null Workarounds
• Keine Docker‑Volumes, die Ghosts Config überschreiben
• Keine Container, die ihre eigenen ENV‑Variablen ignorieren
• Keine Ghost‑Docker‑Images, die Mail‑Config einfach wegoptimieren

Warum die native Installation von Ghost so viel reibungsloser verläuft als der Docker‑Compose‑Ansatz

Die Frage klingt zunächst technisch, aber im Kern geht es um etwas sehr Menschliches: Kontrolle, Transparenz und Vorhersehbarkeit. Genau diese drei Dinge liefert die native Installation von Ghost — und Docker nimmt sie dir an entscheidenden Stellen wieder weg.

1. Ghost ist ursprünglich für die native Installation gebaut

Ghost wurde von Anfang an so entwickelt, dass es:

• direkt auf dem System läuft
• seine config.production.json selbst verwaltet
• systemd‑Dienste nutzt
• lokale Pfade und Ports kennt
• Updates über die Ghost‑CLI bekommt

Das ist die „natürliche Umgebung“ von Ghost.
Alles ist dort so, wie die Entwickler es vorgesehen haben.

Docker dagegen ist ein nachträglicher Verpackungsversuch, der Ghost in eine Umgebung zwingt, für die es nie optimiert wurde.

Das Ergebnis:
Ghost nativ = klare Architektur
Ghost in Docker = Schichten, Workarounds, Eigenheiten

2. Die Konfiguration ist bei der nativen Installation eindeutig

Bei der nativen Installation gibt es genau eine Quelle der Wahrheit:

/var/www/ghost/config.production.json

Wenn du dort etwas änderst, weiß Ghost das sofort.
Wenn du Ghost neu startest, lädt es genau diese Datei.

Bei Docker dagegen hast du:

• ENV‑Variablen
• Volumes
• Container‑interne Configs
• überschreibende Default‑Configs
• Compose‑Dateien
• Images, die eigene Defaults mitbringen

Und Ghost im Container ignoriert manche ENV‑Variablen komplett, weil es intern trotzdem die JSON‑Datei erwartet.

Das führt zu dem typischen Docker‑Ghost‑Drama:

„Ich habe die Mail‑Config gesetzt, aber Ghost übernimmt sie nicht.“

3. systemd ist stabiler als Container‑Startlogik

Native Ghost‑Installationen nutzen systemd:

• sauberer Start
• sauberer Stop
• klare Logs
• automatische Neustarts
• definierte Abhängigkeiten

Docker dagegen startet Ghost:

• in einem isolierten Container
• mit eigenen Startskripten
• ohne systemd
• ohne Ghost‑CLI
• ohne die gewohnte Fehlerdiagnose

Wenn Ghost im Container nicht startet, bekommst du oft nur:

container exited with code 0

Das hilft niemandem.

4. Docker bringt zusätzliche Fehlerquellen mit

Bei Docker hast du plötzlich Dinge, die mit Ghost selbst nichts zu tun haben:

• falsche Ports
• falsche Netzwerke
• falsche Volume‑Mounts
• alte Configs, die aus Volumes wieder auftauchen
• Container, die sich gegenseitig blockieren
• Compose‑Syntaxfehler
• Images, die nicht zur Ghost‑Version passen
• Node‑Versionen, die im Image fest verdrahtet sind

Jede dieser Schichten kann Ghost zum Absturz bringen — und du weißt nie, welche.

Bei der nativen Installation gibt es diese Schichten nicht.
Wenn etwas nicht läuft, ist es wirklich Ghost — und nicht Docker.

5. Mail funktioniert nativ sofort

Das hast du gerade selbst erlebt.

Ghost nativ:

• liest die Mail‑Sektion
• verbindet sich mit SES
• sendet sofort

Ghost in Docker:

• ignoriert ENV‑Variablen
• überschreibt Configs
• startet mit Defaults
• lädt die Mail‑Sektion nicht
• oder verliert sie beim Neustart

Mail ist einer der Bereiche, wo Docker‑Ghost besonders unzuverlässig ist.

6. Updates sind nativ vorhersehbar

Ghost‑CLI macht:

• Backup
• Migration
• Restart
• Versionscheck
• Node‑Check

Docker macht:

• Pull
• Replace
• Hoffen, dass die Datenbank noch passt
• Hoffen, dass die Config noch passt
• Hoffen, dass das Image nicht kaputt ist

Bei Ghost nativ weißt du genau, was passiert.
Bei Docker weißt du es erst, wenn der Container wieder läuft — oder eben nicht.

7. Native Installationen sind näher an der Dokumentation

Die offizielle Ghost‑Dokumentation beschreibt:

• native Installation
• native Updates
• native Config
• native Mail
• native systemd‑Dienste

Docker wird nur am Rand erwähnt — und das merkt man.

Wenn du Ghost so installierst, wie es gedacht ist, passt die Dokumentation perfekt.
Wenn du Docker nutzt, musst du ständig interpretieren, anpassen, debuggen.

Fazit

Die native Installation von Ghost ist:

• einfacher
• vorhersehbarer
• stabiler
• besser dokumentiert
• weniger fehleranfällig
• kompatibler mit Ghosts internem Design

Docker ist großartig für viele Dinge — aber Ghost gehört nicht dazu.
Ghost ist ein System, das von Klarheit lebt.
Und genau diese Klarheit bekommst du nur nativ.