Héberger Wafrn sur une infrastructure partagée : le défi des services multiples avec Caddy

L'idée : publier partout depuis un seul outil

Le fediverse séduit de plus en plus. Publier une fois et toucher son audience sur BlueSky, Mastodon, Lemmy et d'autres plateformes décentralisées en même temps. Wafrn propose exactement ça : une interface unique qui gère la complexité des cross-posts. Mais comme beaucoup d'outils open source puissants, il a été conçu avec une hypothèse qui ne colle pas toujours à la réalité : un serveur dédié.

Le problème ? Wafrn part du principe que vous allez lancer un conteneur Docker et laisser Caddy tout gérer, certificats Let's Encrypt compris. Pour ceux qui font déjà tourner plusieurs services sur le même VPS — WordPress, des microservices, des applis anciennes —, cette approche tout-en-un devient vite un frein.

Pourquoi le setup par défaut pose problème

Le déploiement recommandé est simple en théorie :

• Un conteneur Docker avec Caddy intégré
• Les certificats HTTPS gérés automatiquement
• Le support ATProto, obligatoire pour la fédération avec BlueSky

Le hic apparaît dès que vous avez déjà Nginx (ou un autre serveur) qui écoute sur le port 443 de votre domaine. Wafrn a besoin de Caddy pour valider le contrôle du domaine via les certificats. Ce n'est pas une simple préférence technique : c'est une exigence du protocole ATProto. Sans certificat valide lié au domaine, la fédération ne fonctionne pas.

Et quand deux serveurs web veulent gérer le même domaine, les conflits de ports et de certificats sont inévitables.

La solution : Caddy en proxy secondaire

Plutôt que de tout remplacer, vous pouvez isoler Wafrn derrière votre reverse proxy principal. Caddy et Wafrn tournent ensemble, mais en retrait.

L'architecture ressemble à ça :

Clients (BlueSky, Mastodon…)
    ↓
Votre domaine (nginx sur :443)
    ↓
Réseau interne
    ↓
Caddy + Wafrn (gestion des certificats ATProto)

Le flux est le suivant :

1. Le trafic arrive sur votre serveur principal
2. Votre reverse proxy redirige les routes Wafrn (par exemple /wafrn/*) vers l'instance Caddy interne
3. Caddy gère ses propres certificats pour la validation ATProto
4. Wafrn peut alors fédérer sans souci

Cette approche garde votre infrastructure existante intacte tout en respectant les besoins spécifiques de Wafrn.

Migrer de Nginx vers Caddy : l'IA a ses limites

Si vous envisagez de passer complètement sur Caddy, les outils d'IA peuvent vous aider à convertir vos fichiers de configuration. Transformer une config Nginx en Caddyfile est assez mécanique pour que les LLM s'en sortent bien.

En revanche, configurer Wafrn dans ce setup hybride demande une compréhension fine du protocole ATProto, des variables d'environnement et des pièges de la fédération. L'IA ne maîtrise pas ces détails. Elle peut proposer des pistes, mais vous passerez souvent plus de temps à corriger qu'à partir de zéro.

Partager sa config : un vrai plus pour la communauté

Si vous avez résolu ce casse-tête, vous avez sûrement identifié les endroits où la documentation de Wafrn suppose un serveur dédié. Publier votre configuration — sous forme de fork, de guide ou de template public — fait gagner des heures aux suivants. La communauté y gagne, et vous aussi pour vos futurs projets.

Ce qu'il faut retenir

• La fédération ATProto impose des certificats valides liés à votre domaine
• Le setup par défaut ne convient pas forcément à un VPS partagé
• Caddy peut tourner en service isolé, derrière votre reverse proxy principal
• L'IA aide pour les conversions de config, pas pour concevoir une architecture
• Documenter et partager ses solutions profite à tout le monde

Et après ?

Si vous gérez plusieurs services sur un VPS partagé avec des exigences protocolaires précises, le cas Wafrn montre une approche intéressante : isoler la couche proxy, laisser chaque service gérer son TLS, et faire le lien via votre reverse proxy principal.

Vous voulez creuser les alternatives self-hosted pour le cross-posting ou mieux comprendre la fédération ATProto et ActivityPub ? Dites-le en commentaire.