Proxy inverse (TLS)
Tourne sur la VM cloud, seul point d'entrée public du réseau. Termine le TLS et relaie chaque hôte public vers le bon service à l'intérieur du réseau domicile via le tunnel chiffré — rien n'est exposé directement sur le pare-feu maison. La VM qui l'héberge est sous NixOS, décrite dans le dépôt des machines; les règles du côté edge (DNS, tunnels, accès) vivent dans leur propre dépôt.
# dans l'architecture générée
tunnel:k3sedgeapp:traefikclusterapp:cloudflaredclusterhost:cloud-01hardware
Ces identifiants viennent des dépôts IaC publics, pas de cette page — la vue générée les redessine chaque nuit.
Séparer le bastion de la console : mon shell vivait dans la salle d'opération
Mon shell de travail roulait sur la machine la plus opérée du labo — un Raspberry Pi de 4 Go qui portait aussi les clés de service, le pipeline de secrets et un agent k3s. Une frousse pendant une migration de disque plus tard, on a séparé les deux rôles : le bastion reste sur le Pi survivant, la console déménage dans une VM de 16 Go. En chemin : une haute disponibilité conçue puis jetée, un dépôt lu avec confiance qui datait de trois commits, une clé d'hôte SSH cuite dans l'image, et un registre en panne depuis 18 heures dont la meilleure qualité était que personne ne s'en aperçoive.
Laisser le pipeline appuyer sur apply : quatre dépôts IaC, trois outils, et une porte qui refuse les destroys
Tout le labo était déjà décrit en code, mais chaque apply passait encore par mes mains. On a fermé la boucle en une session : GitHub Actions avec OIDC pour le nuage, Argo CD pour le cluster, comin pour NixOS. Le plus intéressant n'est pas la plomberie : c'est ce que la porte refuse, et les deux Raspberry Pi qui se sont étouffés sur une dépendance de tests.
Quatre dépôts pour un labo au complet : et comment les publier sans donner les clés de la maison
Les machines, les workloads, le compte infonuagique et le edge : tout le labo est décrit dans quatre dépôts git. Ce que ça prend pour adopter une infrastructure qui existe déjà sans rien casser, comment on vérifie chaque nuit que la réalité est encore d'accord, et surtout : comment publier ce code au grand jour sans publier le labo avec.
Neuf machines, zéro clé USB : migrer tout mon homelab vers NixOS
Claude Code aux commandes, moi en mode apprentissage : tout mon parc — serveurs GPU, machines virtuelles, Raspberry Pi et une instance cloud — est passé sous NixOS en une journée. C'est quoi Nix au juste, ce que ça change par rapport à Ubuntu, et pourquoi je n'aurais pas pu faire ça tout seul.
Fable 5 au travail : verrouiller un WebDAV en une session (et vider un forfait au passage)
J'ai fait durcir l'accès WebDAV du coffre-fort de mots de passe par Fable 5 plutôt que par ma propre instance : hash bcrypt, limite de débit à la frontière Cloudflare, et une facture en jetons qui a grimpé plus vite que prévu.
Décommissionner un serveur DNS maison : de "ça a l'air simple" à "on a cassé sa propre résolution DNS"
Ce qui devait être un simple downsizing d'instance EC2 a fini par révéler qu'un vieux serveur DNS maison portait deux rôles cachés, provoquer une panne DNS auto-infligée, et débusquer une dépendance réseau invisible machine par machine.
Le MOVE qui échouait : une histoire de proxy, de schéma HTTP, et d'un coffre-fort presque corrompu
Un 502 intermittent sur WebDAV menait à un désaccord de schéma HTTP derrière un proxy — et la solution de contournement la plus tentante aurait pu corrompre un coffre-fort de mots de passe entier.
Zéro pare-feu, un tunnel : migrer un service vers un tunnel Cloudflare
Migration d'un service (interface d'administration domotique) depuis un accès direct Cloudflare-proxy vers IP publique, vers un tunnel Cloudflare déjà utilisé par un autre service, permettant de retirer complètement le groupe de sécurité AWS dédié. Couvre aussi la mise à jour d'un script de publication de site statique qui dépendait discrètement du même accès.