Wafrn på delt hosting: Sådan kører du flere services uden at rode i hinandens trafik

Enkelte post, mange platforme

Fødererede netværk som Mastodon og BlueSky giver dig mulighed for at ramme flere målgrupper med ét indlæg. Wafrn er lavet til netop det: ét dashboard, der fordeler indholdet automatisk. Men som så mange andre open source-projekter er det bygget til en ren server, hvor det kan styre hele processen.

Det er her, det kniber for mange. De fleste af os har allerede en VPS i drift med WordPress, en lille API eller to og måske en ældre applikation. Wafrn forventer derimod at få port 443 for sig selv og lade Caddy håndtere alt. Det passer sjældent med en eksisterende opsætning.

Hvorfor den officielle vejletning ofte ikke dur

Wafrn leveres typisk som en Docker-container med indbygget Caddy. Caddy sørger for automatisk HTTPS via Let's Encrypt, og det er nødvendigt for at godkende din ATProto-konto over for BlueSky. Uden gyldige certifikater på domænet afviser protokollen forbindelsen.

Når du allerede har Nginx eller en anden webserver, der lytter på port 443, opstår der straks konflikt. To servere kan ikke dele samme port, og det bliver endnu mere kompliceret, når certifikaterne skal styres af flere processer på én gang.

Kør Caddy som en sidevogn

Løsningen er at lade Caddy og Wafrn køre isoleret bag din primære reverse proxy. Trafikken rammer først din eksisterende webserver – typisk Nginx på port 443 – og bliver derefter videresendt til den interne Caddy-instans via en specifik sti som /wafrn/*.

Caddy får lov til at håndtere sine egne certifikater til ATProto-valideringen, mens din primære server fortsat styrer resten af domænet. På den måde undgår du portkonflikter og bevarer den opsætning, du allerede har.

AI til konvertering – ikke til arkitektur

Skal du alligevel flytte fra Nginx til Caddy som primær server, kan AI-værktøjer hjælpe med at omskrive konfigurationen. Det er en mekanisk opgave, som de fleste modeller klarer uden problemer.

Men når det gælder den hybride Wafrn-opsætning, er det en anden sag. Her kræves kendskab til ATProto-krav, miljøvariabler og fejlfinding ved federation. AI-forslag kan være et udgangspunkt, men de skal altid gennemgås manuelt. Ellers risikerer du at bruge mere tid på at rette fejl end på at skrive konfigurationen selv.

Del din løsning

De fleste, der har fået Wafrn til at fungere på delt hosting, har brugt tid på at finde ud af, hvor standardvejledningen ikke passer til virkeligheden. Den viden er værdifuld for andre.

Overvej at publicere din konfiguration som en GitHub-repo, en opdateret guide eller et bidrag til projektets officielle dokumentation. Det sparer den næste udvikler for flere timers prøve-og-fejl.

Fem hurtige pointer

• ATProto kræver gyldige certifikater på domænet – det er ikke valgfrit.
• Standard-deployment passer sjældent til en VPS med flere services.
• Lad Caddy køre isoleret og håndtere Wafrns specifikke krav.
• Brug AI til at oversætte konfigurationer, ikke til at designe infrastrukturen.
• Dokumentér din løsning – både for dig selv og for fællesskabet.

Samme mønster, andre værktøjer

Når først du har fået princippet på plads, kan du genbruge det til andre fødererede applikationer, der kræver kontrol over certifikater. Isolér proxy-laget, lad tjenesten styre sin egen TLS, og diriger trafikken gennem din primære reverse proxy.

Har du lignende udfordringer med selv-hosting, eller vil du høre mere om ATProto og ActivityPub? Skriv gerne i kommentarerne.