Eseguire Wafrn su un VPS condiviso: come integrarlo senza rompere l’infrastruttura

L’idea: pubblicare una volta, arrivare ovunque

Il fascino del fediverse è forte: scrivere un post e vederlo comparire su BlueSky, Mastodon, Lemmy e altre piattaforme allo stesso tempo. Wafrn nasce proprio per questo. Offre una dashboard unica che gestisce il cross-posting automatico. Come spesso succede con i progetti open source, però, la procedura di installazione parte da un presupposto: server dedicato e container Docker che fa tutto da solo.

Chi gestisce già più servizi sullo stesso VPS — WordPress, microservizi, applicazioni legacy — si trova subito di fronte a un problema pratico.

Il setup predefinito e i suoi limiti

La documentazione ufficiale suggerisce tre passaggi semplici:

1. Avviare il container Docker con Caddy integrato
2. Lasciare che Caddy richieda i certificati SSL via Let’s Encrypt
3. Collegare un account ATProto per federare con BlueSky

Il punto critico è il secondo: Wafrn conta su Caddy per ottenere i certificati necessari alla verifica del dominio richiesta dal protocollo ATProto. Se sul VPS è già attivo Nginx o un altro reverse proxy sulla porta 443, non è possibile far convivere due server web sullo stesso dominio senza conflitti.

La soluzione: Caddy come servizio isolato

Invece di sostituire il web server principale, si può far girare Caddy e Wafrn in un ambiente separato, raggiungibile solo tramite il proxy già presente.

Il flusso diventa:

• Il traffico esterno arriva al reverse proxy principale (Nginx, Caddy o altro) sulla porta 443
• Il proxy inoltra solo le richieste destinate a Wafrn verso l’istanza interna
• Caddy gestisce i propri certificati per soddisfare i controlli ATProto
• Wafrn può federare senza interferire con il resto dell’infrastruttura

In pratica si crea un piccolo “sottosistema” dedicato a Wafrn, mentre il resto dei servizi continua a usare la configurazione esistente.

Conversione Nginx → Caddy: dove l’AI aiuta e dove no

Se si decide di migrare il reverse proxy principale da Nginx a Caddy, gli strumenti basati su intelligenza artificiale possono accelerare la conversione del file di configurazione. La sintassi è abbastanza regolare perché un modello linguistico la gestisca in un solo passaggio.

Tuttavia, quando si tratta di far funzionare Wafrn in questo scenario ibrido, servono conoscenze specifiche:

• Come ATProto verifica i certificati
• Quali variabili d’ambiente controllano il comportamento del proxy
• Come interpretare i log quando la federazione fallisce

L’AI può tradurre un file di configurazione, ma le sue proposte su architetture non standard vanno sempre verificate. Spesso si risparmia tempo scrivendo la configurazione manualmente piuttosto che debuggando output generati automaticamente.

Documentare la propria installazione

Chi ha già risolto il problema ha probabilmente individuato i punti in cui la documentazione di Wafrn dà per scontato un server dedicato. Pubblicare la propria configurazione — su GitHub, in un fork o in un post — fa risparmiare ore di tentativi a chi arriverà dopo. Anche un semplice file Caddyfile commentato può diventare un riferimento utile per la community.

Punti chiave

• Il requisito dei certificati ATProto non è negoziabile
• Il deployment standard non si adatta sempre a VPS con più servizi
• Isolare Caddy e Wafrn dietro il proxy principale è la via più pulita
• Usare l’AI per conversioni di sintassi, non per riprogettare l’infrastruttura
• Condividere la soluzione aiuta gli altri e crea un promemoria per il futuro

Prossimi passi

Lo schema descritto — proxy principale che instrada il traffico verso un Caddy dedicato — si può applicare a qualsiasi applicazione federata che richieda il controllo dei propri certificati. Se stai gestendo un setup simile o cerchi alternative self-hosted per il cross-posting, fammi sapere nei commenti.