Ghost zwischen zwei Welten: Homeserver + WireGuard + VPS + Caddy
Ein Erfahrungsbericht über ein hybrides Hosting‑Setup
Viele Selbsthoster stehen irgendwann vor der gleichen Frage:
Wie verbinde ich meinen Homeserver sicher mit einem öffentlichen VPS, ohne meine bestehende Infrastruktur umzubauen?
In meinem Fall ging es um zwei Ghost‑Instanzen:
- Ghost #1 läuft direkt auf dem VPS und wird dort über Caddy veröffentlicht.
- Ghost #2 läuft auf meinem Homeserver in der DMZ, geschützt durch OPNsense, und soll ebenfalls öffentlich erreichbar sein — aber ohne Ports am Heimrouter zu öffnen.
Die Lösung:
Ein WireGuard‑Tunnel zwischen VPS und OPNsense, durch den der VPS den Homeserver wie ein internes Netz erreichen kann.
Und: Caddy auf dem VPS bleibt der einzige Reverse‑Proxy, der beide Ghost‑Instanzen sauber trennt.
1. Die Architektur im Überblick
Hier ist das Setup in Worten — ein Schaubild kannst du später leicht daraus bauen:
Homeserver / DMZ
- Ghost‑Instanz #2 läuft in einem Docker‑Stack
- Der Host befindet sich in einer DMZ‑Zone hinter OPNsense
- Der VPS erreicht die DMZ nur über WireGuard, nicht über das Internet
- OPNsense steuert Routing und Firewall
OPNsense
- WireGuard‑Server oder ‑Client (je nach Setup)
- Firewall‑Regeln erlauben nur:
- eingehenden Traffic vom VPS zum DMZ‑Ghost‑Port
- ausgehenden Traffic zurück zum VPS
- Keine Portfreigaben ins Internet
VPS
- Läuft bereits mit einer Ghost‑Instanz (Ghost #1)
- Caddy ist der öffentliche Reverse‑Proxy
- WireGuard‑Peer zum Homeserver
- Caddy bekommt eine zweite Domain und proxyt Ghost #2 durch den Tunnel
Caddy
- Bedient bayerwald.blog → Ghost #1
- Bedient elmo.k9max.de → Ghost #2 über WireGuard
- Automatische Zertifikate
- Keine Port‑Konflikte
- Keine Änderungen an der bestehenden Ghost‑Instanz
2. WireGuard: Die Brücke zwischen VPS und DMZ
Damit der VPS den Homeserver erreicht, braucht es:
Auf dem VPS
- WireGuard‑Peer
- Route zur DMZ‑IP des Homeservers
- Firewall erlaubt Traffic zum Tunnel
Auf OPNsense
- WireGuard‑Peer
- Regel: „Erlaube Traffic vom VPS‑Tunnel‑IP → DMZ‑Ghost‑IP:2368“
- Regel: „Erlaube Antwortverkehr zurück zum VPS“
Damit sieht der VPS den Homeserver wie ein internes Netz:
VPS → WireGuard → OPNsense → DMZ → Ghost
3. Caddy: Der zentrale Reverse‑Proxy
Der wichtigste Punkt:
Caddy bleibt der einzige öffentliche Reverse‑Proxy.
Die bestehende Konfiguration für bayerwald.blog bleibt unberührt:
{$DOMAIN} {
reverse_proxy ghost:2368
encode gzip
import snippets/SecurityHeaders
}
Für die neue Instanz wird einfach ein zweiter Hostblock ergänzt:
elmo.k9max.de {
reverse_proxy 192.168.x.x:2368
encode gzip
}
Keine Snippets, keine ActivityPub‑Blöcke, keine Admin‑Domain.
Einfach ein sauberer, separater VirtualHost.
Caddy holt sich automatisch Zertifikate und trennt beide Instanzen perfekt.
4. Warum NGINX nicht der richtige Ort war
Parallel lief auf dem VPS ein NGINX‑Container für ein anderes Projekt.
Der lief auf Port 8081 — also nicht öffentlich.
Wichtig war zu verstehen:
- NGINX ist nicht der öffentliche Reverse‑Proxy
- Caddy hält Port 80/443
- Caddy muss auch die neue Domain übernehmen
- NGINX bleibt für interne Dienste zuständig
Damit vermeidet man Port‑Konflikte und doppelte Zertifikatsverwaltung.
5. Ergebnis: Zwei Ghost‑Instanzen, ein Reverse‑Proxy, ein Tunnel
Nach dem Reload:
docker exec -it ghost-caddy-1 caddy reload --config /etc/caddy/Caddyfile
war die zweite Ghost‑Instanz sofort öffentlich erreichbar —
ohne dass die bestehende Instanz auf dem VPS auch nur berührt wurde.
6. Fazit
Dieses Setup zeigt, wie elegant man einen Homeserver mit einem VPS verbinden kann, ohne Ports zu öffnen oder die Infrastruktur umzubauen:
- WireGuard sorgt für sichere, private Konnektivität
- OPNsense kontrolliert Routing und Firewall
- Caddy übernimmt alle öffentlichen Domains
- Ghost läuft dort, wo es hingehört — egal ob VPS oder DMZ
Das Ergebnis ist ein flexibles, sicheres und erweiterbares Hosting‑Modell, das sich perfekt für Blogs, kleine Webdienste oder private Projekte eignet.
┌──────────────────────────────────────────┐
│ Internet │
└──────────────────────────────────────────┘
│
│ HTTPS (Port 443)
▼
┌──────────────────────────────────────────────┐
│ VPS │
│ (öffentlicher Reverse‑Proxy) │
├──────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────┐ │
│ │ Caddy │ │
│ │ - hält Port 80/443 │ │
│ │ - automatische Zertifikate │ │
│ │ - mehrere Domains parallel │ │
│ └──────────────────────────────────────┘ │
│ │ │ │
│ │ │ │
│ │ │ │
│ HTTPS für bayerwald.blog HTTPS für elmo.k9max.de
│ │ │
▼ │ ▼
┌──────────────────┐ │ ┌────────────────────────────────┐
│ Ghost #1 (VPS) │ │ │ reverse_proxy → 192.168.10.100 │
│ Docker‑Stack │ │ │ (Ghost #2 im Heimnetz) │
└──────────────────┘ │ └────────────────────────────────┘
│
│
▼
┌──────────────────────────────────────────────┐
│ WireGuard‑Tunnel │
│ (verschlüsselte Punkt‑zu‑Punkt‑Verbindung) │
└──────────────────────────────────────────────┘
│
│ privates WG‑Netz (z. B. 10.0.0.0/24)
▼
┌────────────────────────────────────────────────────────────┐
│ OPNsense │
│ (Firewall + Routing + DMZ) │
├────────────────────────────────────────────────────────────┤
│ - WireGuard‑Peer │
│ - Regel: Erlaube Traffic vom VPS → DMZ:2368 │
│ - Regel: Erlaube Antwortverkehr zurück zum VPS │
│ - Keine Portfreigaben ins Internet │
└────────────────────────────────────────────────────────────┘
│
│ internes DMZ‑Netz (z. B. 192.168.10.0/24)
▼
┌────────────────────────────────────────────────────────────┐
│ Homeserver │
│ (DMZ) │
├────────────────────────────────────────────────────────────┤
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Ghost #2 (DMZ) │ │
│ │ Docker‑Stack, erreichbar unter 192.168.10.100:2368 │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
└────────────────────────────────────────────────────────────┘
