Wafrn na współdzielonym serwerze: jak pogodzić federację z istniejącą infrastrukturą

Jeden wpis, wiele platform

Idea fediverse przyciąga. Napisać raz, a pojawić się jednocześnie na Mastodonie, BlueSky czy Lemmy. Wafrn obiecuje właśnie to – centralny panel, który sam ogarnia cross-posting. Problem w tym, że narzędzie zakłada dość specyficzny sposób uruchomienia: dedykowany serwer, kontener Dockera i Caddy przejmujący całość ruchu.

Dla kogoś, kto już ma na VPS-ie WordPressa, kilka API i stare aplikacje, takie „wszystko albo nic” bywa kłopotliwe.

Domyślna instalacja i jej ograniczenia

Oficjalna instrukcja wygląda prosto:

• uruchamiasz kontener z wbudowanym Caddy,
• Caddy automatycznie pobiera certyfikaty Let’s Encrypt,
• BlueSky wymaga poprawnego certyfikatu na domenie (ATProto).

Gdy na porcie 443 siedzi już Nginx lub inny serwer, pojawia się konflikt. Nie da się postawić drugiego procesu na tym samym porcie, a zarządzanie certyfikatami dla jednej domeny przez dwa różne narzędzia szybko zamienia się w chaos.

Rozwiązanie: Caddy jako usługa poboczna

Zamiast wymieniać cały stack, można uruchomić Wafrn razem z własnym Caddy za głównym proxy. Schemat wygląda tak:

Zewnętrzny klient
    ↓
Główne proxy (Nginx / Caddy) :443
    ↓
Wewnętrzna sieć
    ↓
Caddy + Wafrn (obsługa certyfikatów ATProto)

Ruch przychodzący trafia najpierw do istniejącego serwera. Tam przekierowujesz wybrane ścieżki (np. /wafrn/*) do wewnętrznego Caddy. Ten drugi Caddy dostaje własny certyfikat i obsługuje wymagania protokołu ATProto, podczas gdy Twoje główne proxy nadal zarządza resztą usług.

Konwersja konfiguracji – gdzie AI pomaga, a gdzie nie

Jeśli zdecydujesz się wymienić Nginx na Caddy, przepisanie nginx.conf na Caddyfile jest zadaniem, z którym modele językowe radzą sobie całkiem nieźle. To głównie zmiana składni.

Natomiast zaprojektowanie poprawnego mostka między głównym proxy a Wafrn wymaga znajomości niuansów: które zmienne środowiskowe wpływają na proxy, jak ATProto weryfikuje certyfikaty i gdzie kryją się pułapki bezpieczeństwa. Tutaj AI często proponuje rozwiązania, które potem trzeba długo debugować.

Lekcja praktyczna: używaj automatycznych konwerterów do zmiany formatu, ale architekturę sprawdzaj samodzielnie lub z kimś, kto już to robił.

Warto dokumentować własne rozwiązania

Prawie każdy, kto wdraża Wafrn poza domyślnym schematem, trafia na brakujące fragmenty dokumentacji. Jeśli znajdziesz działającą konfigurację, warto ją opublikować – czy to jako fork repozytorium, osobny poradnik, czy publiczną konfigurację na GitHubie. Zaoszczędzisz komuś kilku godzin błądzenia.

Najważniejsze wnioski

1. ATProto wymaga poprawnego certyfikatu – nie da się tego obejść.
2. Domyślna instalacja zakłada czysty serwer; na współdzielonym VPS-ie trzeba kombinować.
3. Uruchom Caddy + Wafrn za głównym proxy, izolując wymagania protokołu.
4. AI przyspiesza przepisywanie plików konfiguracyjnych, ale nie zastępuje wiedzy o infrastrukturze.
5. Dziel się rozwiązaniami – społeczność zyska, a Ty będziesz miał gotowy szablon na przyszłość.

Co dalej?

Ten sam schemat – dedykowane proxy wewnątrz większej infrastruktury – przydaje się przy innych aplikacjach federacyjnych, które muszą kontrolować własne certyfikaty. Jeśli prowadzisz podobny setup lub masz pytania dotyczące Wafrn, daj znać w komentarzach.