Architecture v2 : FRP et Caddy, la liberté retrouvée
Après le test de XTNA / Azure Entra ID, découvrez comment j'ai repris le contrôle de mon Home Lab avec FRP et Caddy. Du test sur Azure au déploiement final sur un VPS Infomaniak, voici ma nouvelle architecture sans agents !
Dans l'article précédent, j'expliquais pourquoi j'avais abandonné XTNA : trop de dépendances, trop de friction, trop de boîtes noires. Il me fallait une solution différente — simple, souveraine, sans agent côté client.
Le concept : le Reverse Proxy... inversé
L'idée est simple : si je ne peux pas ouvrir de port chez moi, j'utilise un serveur externe qui en possède un, et je crée un pont entre les deux.
Deux outils se sont imposés :
- FRP (Fast Reverse Proxy) : expose un serveur local situé derrière un NAT ou un pare-feu vers l'extérieur, via un tunnel initié de l'intérieur
- Caddy : serveur web moderne qui gère les certificats SSL automatiquement via Let's Encrypt
Validation sur Azure avant de s'engager
Avant de payer un VPS, j'ai validé le concept sur une VM Linux avec mes crédits Azure gratuits.
Objectif : confirmer que le tunnel FRP était stable et que Caddy gérait bien plusieurs sous-domaines. Une fois mon-service.mon-domaine.com accessible depuis tous mes périphériques, j'avais ma réponse.
Passage à la production : direction Infomaniak
Hors de question de rester sur Azure : toujours cet objectif de sortir des GAFAM, et une question de coût.
Je me suis tournée vers Infomaniak pour leur éthique, leur hébergement écologique, leur ancrage européen et leurs tarifs compétitifs. Ce VPS est devenu le point d'entrée public de tout mon réseau.
Comment ça marche concrètement ?
L'architecture tient en trois étapes :
- Sur le VPS : le serveur FRP attend les connexions du homelab ; Caddy écoute les requêtes web entrantes et route chaque sous-domaine vers le proxy FRP correspondant
- Sur le homelab : le client FRP maintient un tunnel ouvert vers le VPS en permanence
- Le flux : une requête arrive sur Caddy (VPS) → elle est routée vers le bon proxy FRP → traversée du tunnel → service local
Pourquoi c'est (beaucoup) mieux ?
- Zéro agent : un simple navigateur suffit depuis n'importe quel appareil
- Indépendance : plus de SaaS tiers, plus d'Azure Entra ID
- DNS transparent : les URLs restent identiques en local comme à l'extérieur
- Maîtrise totale : je sais exactement quel trafic transite dans le tunnel
La limite de cette approche
Cette architecture fonctionne bien, mais elle a un défaut : Caddy tourne sur le VPS, et chaque nouveau service nécessite d'y ajouter un proxy FRP et une entrée Caddy. La configuration se duplique, elle est répartie entre deux machines, et modifier quelque chose implique de se connecter au VPS.
C'est cette verbosité qui m'a poussée à franchir une étape supplémentaire : rapatrier Caddy en local et réduire le VPS à un simple passe-plat TCP. C'est l'objet de l'article suivant.