Hospedando o Wafrn em Infraestrutura Compartilhada: Um Guia Prático

Publicar em Vários Lugares ao Mesmo Tempo

A ideia do fediverse é simples e poderosa: escrever uma vez e aparecer em várias plataformas ao mesmo tempo. O Wafrn tenta resolver exatamente isso, oferecendo um painel único que distribui seu conteúdo para BlueSky, Mastodon e outras redes descentralizadas. Porém, como acontece com muitos projetos open source, a forma como ele foi pensado para rodar nem sempre encaixa na realidade de quem já mantém vários serviços no mesmo servidor.

O grande obstáculo aparece logo no início. O Wafrn foi criado pensando em um servidor só para ele. A instalação padrão usa Docker com Caddy embutido, que cuida automaticamente dos certificados SSL. Isso funciona muito bem em um VPS dedicado, mas complica tudo quando você já tem Nginx ou outro servidor web gerenciando seu domínio.

Por Que a Configuração Padrão Não Funciona

O problema não é só de portas conflitando. O Wafrn precisa que o Caddy controle os certificados para atender aos requisitos do protocolo ATProto, usado pelo BlueSky. Sem isso, a federação simplesmente não funciona. Quando outro servidor já está escutando na porta 443, não dá para colocar outro competindo pelo mesmo domínio.

A Solução: Caddy Isolado

Em vez de trocar toda sua infraestrutura, você pode rodar o Wafrn com seu próprio Caddy em segundo plano. Seu servidor principal continua cuidando do tráfego normal, mas direciona apenas as rotas do Wafrn para essa instância isolada. Assim, o Caddy consegue gerenciar seus próprios certificados sem interferir no resto do sistema.

A arquitetura fica mais ou menos assim:

Cliente (BlueSky, Mastodon...)
    ↓
Seu domínio (Nginx na porta 443)
    ↓
Rede interna
    ↓
Caddy + Wafrn (cuida dos certificados ATProto)

Usando IA para Converter Configurações

Se você decidir migrar seu proxy principal de Nginx para Caddy, ferramentas de IA podem ajudar bastante na conversão básica dos arquivos de configuração. O processo é mecânico o suficiente para dar certo na primeira tentativa.

Porém, adaptar o Wafrn para funcionar nesse modelo híbrido exige conhecimento específico que a IA ainda não domina bem. Coisas como entender os requisitos de certificado do ATProto, identificar quais variáveis de ambiente controlar ou diagnosticar falhas de federação são detalhes que exigem experiência prática.

Por Que Documentar Sua Configuração Vale a Pena

Se você já passou por esse processo, provavelmente descobriu vários pontos onde a documentação oficial assume coisas que nem sempre são verdadeiras. Compartilhar sua solução — seja em um fork, em um guia separado ou em um repositório público — economiza tempo de quem vai tentar a mesma coisa depois.

Pontos Principais

• O ATProto exige certificados válidos ligados ao seu domínio para funcionar
• Nem todo projeto open source foi pensado para rodar junto com outros serviços
• Isolar o Caddy do Wafrn é mais simples do que tentar integrar tudo no mesmo servidor
• Use IA para converter configurações, mas não para arquitetar soluções complexas
• Documentar o que funcionou ajuda a comunidade inteira

Próximos Passos

O padrão de isolar o proxy de aplicações que precisam de controle sobre certificados serve para outros projetos de federação também. Se você está lidando com algo parecido, essa abordagem pode ser um bom ponto de partida.

Quer conhecer alternativas self-hosted para ferramentas de cross-posting ou entender melhor como funciona a federação com ATProto e ActivityPub? Deixe seu comentário abaixo.