Mon infrastructure

hernandes.cloud n'est pas juste un site : c'est la porte d'entrée de mon petit système auto-hébergé. Cette page explique comment il est construit, et pourquoi - les services eux-mêmes sont visibles en direct sur /services et /monitoring.

Vue d'ensemble

Plusieurs rôles, plusieurs machines, chacune avec un usage précis :

Serveur local - allumé 24/7. Reverse proxy nginx, secours pour ce site, quelques services auto-hébergés (Nextcloud, Vaultwarden, Grafana, Plex).
NAS Synology - stockage et services applicatifs DSM (photos, notes, fichiers, vidéosurveillance...), exposés via le même reverse proxy.
Desktop - poste de travail interactif quotidien. C'est délibérément la machine la plus protégée du lot.
Kali - machine dédiée monitoring/sécurité, réveillée à la demande pour la démo.

Topologie réseau

Ce schéma ne couvre que mon réseau local (le homelab) - la partie distribuée (bascule automatique entre serveurs) est détaillée dans « Déploiement et résilience » plus bas. Généré par un script perso qui découvre le LAN, plutôt que dessiné à la main - routeur, switch, WiFi, et ce qui est branché derrière. Noms et adresses réels remplacés par des rôles génériques. Le pont domotique pilote aussi de l'éclairage en Zigbee, un réseau à part, invisible depuis le LAN - d'où le trait en pointillés.

Topologie du réseau domestique : routeur, switch, WiFi, et les appareils connectés

Pourquoi ces choix

Peu de machines exposées directement, les autres réveillées ou éteintes selon leur usage réel - pensé pour limiter la surface d'exposition, pas par souci de simplicité.

Déploiement et résilience

Le point d'entrée public n'est plus une seule machine mais une propriété du DNS : un serveur sert le trafic par défaut - le site et l'API du chatbot Gabrielle - avec bascule automatique vers le serveur local en secours en cas de panne, et retour automatique une fois le service rétabli. Les deux machines restent reliées en permanence par un mesh VPN auto-hébergé, mon poste de sécurité.

Le déploiement suit un pipeline CI/CD déclenché à chaque push sur la branche principale : build d'images Docker multi-architecture sur des runners natifs, publication sur un registre de conteneurs, puis mise à jour automatisée de la machine cible. Comme pour le reste de cette page, la mécanique précise de bascule (ports, identifiants, scripts) n'est pas détaillée ici - l'idée est de montrer les choix, pas de documenter une cible d'attaque.