Wafrn auf Shared Hosting: So läuft der Dienst hinter einem bestehenden Reverse Proxy

Ein System, viele Plattformen

Im Fediverse willst du eigentlich nur einmal schreiben und erreichst Leser auf Mastodon, BlueSky, Lemmy und Co. Wafrn soll genau das leisten: ein zentrales Dashboard, das deine Beiträge überallhin verteilt. Die meisten Anleitungen gehen jedoch davon aus, dass du einen frischen Server bekommst und dort einfach den Docker-Container startest. Wer schon WordPress, APIs oder andere Anwendungen auf demselben VPS betreibt, stößt schnell an Grenzen.

Warum die Standard-Installation scheitert

Wafrn bringt Caddy mit, der automatisch Let's-Encrypt-Zertifikate besorgt. Das klingt praktisch – ist aber zwingend notwendig. ATProto (BlueSkys Protokoll) prüft beim Federation, ob du wirklich Inhaber der Domain bist. Das geschieht über das Zertifikat. Steht auf Port 443 schon Nginx oder ein anderer Webserver, kommt es zum Konflikt: zwei Prozesse wollen dieselben Zertifikate verwalten, und die Validierung schlägt fehl.

Die Lösung: Caddy als Sidecar

Statt den bestehenden Webserver zu ersetzen, lagerst du Caddy und Wafrn einfach aus. Der Aufbau sieht so aus:

Client (BlueSky, Mastodon …)
    ↓
Dein Domain-Webserver (Nginx auf :443)
    ↓
Internes Netz
    ↓
Caddy + Wafrn (eigene Zertifikate für ATProto)

So funktioniert der Traffic:

1. Anfragen treffen auf deinem Haupt-Webserver ein.
2. Dieser leitet nur die Wafrn-Pfade (z. B. /wafrn/*) an den internen Caddy weiter.
3. Caddy holt sich eigene Zertifikate – entweder für eine Subdomain oder per Token-Validierung.
4. Wafrn kann nun sauber mit Mastodon und BlueSky kommunizieren, ohne Port-Konflikte.

Nginx nach Caddy konvertieren – wo KI hilft und wo nicht

Willst du den Haupt-Webserver komplett auf Caddy umstellen, sind Konverter-Tools oft ausreichend. Die Syntax-Umwandlung ist vorhersehbar. Sobald es aber um Wafrns spezifische Anforderungen geht – ATProto-Validierung, Proxy-Variablen, Debugging von Federation-Fehlern – liefert KI meist nur Einstiegspunkte. Du wirst trotzdem manuell nachjustieren müssen.

Warum eigene Dokumentation zählt

Die offiziellen Docs setzen meist auf „einen frischen Server“. Wer stattdessen mehrere Dienste mischt, stolpert über Lücken. Wer seine funktionierende Konfiguration als Fork, separates Repo oder Patch hochlädt, spart anderen Stunden an Trial-and-Error. Die Community profitiert, und du hast später selbst eine Referenz.

Kurzfassung

• ATProto verlangt echte Domain-Zertifikate.
• Standard-Setups passen selten zu bestehenden Infrastrukturen.
• Caddy als Sidecar trennt Zuständigkeiten sauber.
• KI eignet sich für reine Format-Konvertierung, nicht für Architektur-Entscheidungen.
• Geteiltes Wissen spart allen Zeit.

Und jetzt?

Das gleiche Muster – Proxy auslagern, TLS selbst verwalten – funktioniert bei vielen föderierten Diensten. Wenn du ähnliche Herausforderungen hast, lohnt es sich, die Lösung festzuhalten.