- Partage d’expérience sur la mise en place réussie d’un environnement personnalisé après avoir essayé pendant des années différentes approches d’auto-hébergement
- Les objectifs principaux étaient le contrôle des données personnelles et le maintien d’une infrastructure fiable, en combinant pour cela plusieurs technologies clés comme NixOS, ZFS, Tailscale et Authelia
- L’expérience d’utilisation pour la famille et les proches a aussi été prise en compte, avec un SSO et une page d’accueil dédiée pour améliorer l’accessibilité
- Les problèmes rencontrés en exploitation réelle et leurs solutions concrètes (ex. : proxy public pour services privés, environnement VPN mixte, intégration de l’authentification) sont détaillés
- D’autres améliorations sont prévues, notamment le renforcement de l’infrastructure de sauvegarde et de la sécurité, avec un partage de bonnes pratiques et de ressources de référence
Introduction et motivation
- Après avoir essayé plusieurs formes d’auto-hébergement sur plusieurs années, l’auteur a fini par construire un environnement « suffisamment bon » pour ses besoins
- Il s’est appuyé sur diverses ressources open source et sur l’expérience d’autres personnes, et partage ici ce parcours pour aider d’autres développeurs
Objectifs
- Renforcer la confidentialité et réduire au minimum les risques liés aux changements ou à l’arrêt de services tiers en gardant le contrôle direct sur les données personnelles et les services associés
- Étendre ce contrôle à la famille et aux proches afin de mettre en place un environnement de services fiable
Exigences
-
Exigences essentielles
- Limiter autant que possible l’exposition des services à l’Internet public afin de réduire le risque d’incident de sécurité
- Minimiser les temps d’arrêt de l’infrastructure critique dus à des erreurs (éviter les dépendances circulaires et faciliter le rollback de configuration)
- Posséder directement les composants clés comme l’authentification, le réseau et le domaine, avec une préférence pour l’open source
- Prendre en compte la facilité d’usage pour la famille et les proches (connexion SSO cohérente, maintenance minimale)
- Adopter activement une configuration déclarative via des fichiers de configuration (facilité de gestion de versions, de sauvegarde et de restauration, et possibilité de réutiliser les configurations d’autres personnes)
- Les mises à jour doivent être simples et sûres afin de permettre une maintenance régulière
-
Exigences non prioritaires
- Pas besoin d’une modularité extrême ou d’une propreté absolue (priorité au pragmatisme)
- Tout n’a pas besoin d’être open source, mais c’est préférable quand c’est possible
- Pas de recherche de haute disponibilité (HA) ; l’auteur accepte du downtime en échange d’une architecture simple
Choix techniques
-
NixOS
- Une distribution Linux qui gère de manière déclarative toute la configuration de l’OS avec le langage Nix et son gestionnaire de paquets
- La configuration étant décrite comme du code, la gestion de versions et les rollbacks structurés sont possibles
- Supporte de nombreux paquets ainsi que l’intégration avec Docker/PODMAN, etc.
- L’auteur a accumulé du savoir-faire en s’inspirant des configurations Nix d’autres développeurs
-
ZFS
- Un système de fichiers haute performance avec d’excellentes fonctions de protection des données, comme les snapshots et le rollback
- 4 HDD de 10 To configurés en RAIDZ2 (tolérance à la panne simultanée de 2 disques), avec mise en cache sur un SDD de 256 Go
- Séparation des datasets fichiers/médias, gérés via des montages NFS selon l’usage
- Mise en place d’une architecture de stockage principale simple et fiable
-
Tailscale & headscale
- Tailscale : un mesh VPN très accessible qui permet d’accéder au réseau interne sans exposition à l’Internet public simplement en installant le client
- Headscale : backend Tailscale open source auto-hébergeable, supprimant le risque lié à un changement de politique de l’entreprise
- Renforce la sécurité réseau, mais nécessite l’installation du client sur les appareils des utilisateurs
- Du point de vue de l’ergonomie, l’installation d’un client sur chaque appareil reste un certain frein à l’entrée
-
Authelia & LLDAP
- Authelia : solution de SSO, d’authentification et d’autorisation basée sur OpenID Connect, intégrable avec un proxy nginx
- LLDAP : LDAP léger, utilisé pour la gestion des utilisateurs et groupes d’Authelia ainsi que comme solution d’authentification de secours
- Fonctionne très bien avec peu de ressources, mais la configuration est complexe et il existe une vraie courbe d’apprentissage pour comprendre l’intégration avec chaque service
Conception de l’architecture
-
Architecture
- Chaque serveur porte le nom d’une planète de Star Wars
- Le point d’entrée (serveur public) est « taris », qui fournit les services essentiels comme Authelia, headscale et le blog
- headscale, Authelia et LLDAP doivent être accessibles depuis l’extérieur, et sont donc exploités publiquement dans un périmètre limité
- Les services privés (Foundry VTT, monitoring, etc.) sont relayés par NGINX afin d’être exposés de manière sélective
-
Serveur privé
- Le serveur principal « kuat » gère, via TrueNAS, une VM NixOS et le pool de stockage ZFS
- La portée des snapshots et des sauvegardes est séparée entre « files » (données irrécupérables) et « media » (données potentiellement récupérables)
- Les services principaux tournent sur la VM « bespin » sous NixOS, avec une VM de test séparée (« alderaan »)
-
Autres services
- Les appareils critiques sont déployés comme des appliances à usage unique (par ex. Home Assistant OS séparé pour la maison connectée)
- Le serveur Matrix et le client Element utilisent le playbook Ansible officiel
- Le mail et la gestion des mots de passe sont externalisés vers ProtonMail et Bitwarden afin d’éviter les dépendances circulaires
Problèmes rencontrés et solutions
-
Page d’accueil des services
- Un tableau de bord simple basé sur Flame améliore l’accès aux services pour chaque utilisateur
- Peu gourmand et visuellement réussi, il reste pratique en attendant l’adoption éventuelle d’un service alternatif
-
Utilisation conjointe de Tailscale et d’un autre VPN
- Certains OS (notamment Android et Windows) ne permettent pas d’utiliser plusieurs VPN en même temps
- En combinant la fonction exit node de Tailscale avec Gluetun (client VPN en conteneur), il devient possible d’utiliser un VPN externe comme ProtonVPN en contournement
- Il existe toutefois des effets secondaires, comme une consommation de batterie accrue et des baisses de vitesse occasionnelles
-
Points d’attention sur l’authentification
- Principaux protocoles d’authentification des services auto-hébergés : OIDC (prioritaire), OAuth, LDAP
- Une configuration distincte est nécessaire pour chaque service et pour Authelia
- Les comptes administrateur doivent absolument être conservés séparément de l’intégration Authelia/LLDAP afin de garantir un moyen de récupération en cas de problème d’authentification
- Pour les services ne supportant pas OIDC, le contrôle d’accès est mis en œuvre via l’intégration proxy NGINX + Authelia
- L’OIDC d’Authelia et le contrôle d’accès via NGINX Proxy nécessitent des configurations séparées
-
DNS et émission des certificats SSL
- Les services publics sont exploités de manière classique (domaine → IP publique)
- Les services internes utilisent le sous-domaine « internal » et les IP Tailscale, ce qui bloque leur exposition externe
- Les certificats SSL s’appuient sur le support intégré de Let’s Encrypt dans NixOS (HTTP-01 pour les services publics, DNS-01 pour les services internes)
-
Points d’attention pour l’installation de NixOS sur un VPS
- De nombreux VPS ne proposent pas d’option d’installation NixOS
- En cas d’installation nécessaire, il faut vérifier les chemins pris en charge en s’appuyant sur le wiki de la communauté ou d’autres ressources
-
Montage de datasets TrueNAS dans une VM
- Le pare-feu par défaut de TrueNAS bloque l’accès de l’hôte depuis la VM
- Le montage des datasets NFS a été mis en place en suivant le guide officiel (création d’un réseau bridge)
-
Proxy public pour services personnels
- Avec une base headscale, il est possible d’exposer des services privés vers l’extérieur via
proxyPass de NGINX
- En plus de Tailscale Funnel officiel, des exemples de configuration et des ressources de référence sont fournis
Prochaines étapes et chantiers
- Nécessité d’ajouter un serveur de sauvegarde dédié et un mécanisme de validation de restauration
- Prévoit d’utiliser plus activement le contrôle d’accès de Tailscale/headscale
- Renforcement supplémentaire de la sécurité, notamment pour l’accès SSH
- Étudie l’adoption de solutions locales de chiffrement et de cache DNS comme Pi-hole et AdGuard Home
- Envisage d’étendre l’environnement avec de nouveaux services comme Forgejo, Manyfold et RomM
Ressources de référence
2 commentaires
C’est génial !
Commentaires Hacker News
Pour que la famille ou les amis puissent l’utiliser facilement, l’objectif est de donner à chacun un seul compte de connexion pour accéder à plusieurs services via du SSO (single sign-on). C’est vraiment la partie la plus difficile, mais aussi la plus élégante. L’open source et Linux sont profondément paradoxaux : ils sont utilisés partout et gèrent tous les protocoles, mais dès qu’il s’agit de l’environnement client réel, c’est-à-dire relier des gens entre eux et construire directement des fonctions de groupware, cela devient au contraire plus complexe. Le simple fait d’intégrer organiquement plusieurs systèmes et de mettre en place une infrastructure d’annuaire est déjà impressionnant. Je ne pensais pas qu’un jour j’exploiterais moi-même FreeIPA ou un service d’annuaire compatible Windows, mais ces derniers temps j’ai l’impression que l’écosystème basé sur OpenID commence réellement à se stabiliser.
Merci pour ton message de soutien. La simplicité de connexion et l’accessibilité étaient les exigences les plus difficiles de ce projet, et je pense que c’est précisément ce qui détermine si les gens l’utiliseront vraiment ou non. L’open source est réellement partout, mais les problèmes commencent dès qu’un utilisateur ordinaire essaie d’utiliser quelque chose lui-même. À mon avis, ce paradoxe vient du fait que chaque projet veut innover de son côté. L’absence d’un acteur qui tire tout dans une seule direction est à la fois une force et une faiblesse. Cela dit, rien qu’en regardant le self-hosting de ces cinq dernières années, j’ai l’impression que l’installation et l’usage sont devenus bien plus simples.
Je suis tout à fait d’accord avec ce paradoxe. Hier encore, j’ai publié sur ma plateforme de validation au sujet du manque d’accessibilité du FOSS pour les non-techniciens. Je me demande si la solution ne pourrait pas être une sorte de plateforme d’intégrateurs système reliant des utilisateurs techniques à des particuliers non techniques.
En réalité, ce n’est pas si difficile. Si on ne s’attache pas à un service précis et qu’on fait du support SSO le premier critère de sélection, l’installation est étonnamment simple. Moi aussi, j’avais très peu d’expérience au départ, mais j’ai rapidement monté un système self-hosted avec caddy et authentik. Sinon, yunohost est une distribution très simple qui configure même le SSO automatiquement.
J’utilise authentik avec l’authentification SSO Google, Discord et GitHub. Cela fonctionne très bien pour tout le monde.
Je sais qu’il peut falloir du temps à chacun pour trouver son propre système « parfaitement adapté », car les objectifs, préférences et environnements diffèrent. J’aimerais donc partager dans un billet de blog le cheminement complet vers ma configuration finale : objectifs et exigences, technologies utilisées, architecture et résolution des problèmes. Ma méthode ne conviendra pas à tout le monde, mais j’espère qu’elle pourra servir de référence à d’autres. J’ai moi-même beaucoup progressé grâce à de nombreux contenus et logiciels gratuits, alors j’aimerais continuer à transmettre cette aide.
Je serais curieux d’avoir ton retour sur Nix dans un homelab. De mon côté, cela fait plus de 7 ans que je fais tourner de manière assez hardcore un rack 25U avec du petit kubernetes, ceph et Talos Linux, mais j’ai de plus en plus envie de simplifier, et curieusement je finis toujours par revenir à Nix et ZFS. Les difficultés dont tu parles me sont très familières. N’hésite pas à poser des questions si tu veux.
Est-ce que tu as envisagé d’utiliser coolify ? Cela fait plus d’un an que je l’utilise, et j’aime beaucoup le fait qu’il déploie automatiquement depuis GitHub aussi facilement que Heroku. https://coolify.io/
J’aimerais savoir si tu utilises aussi le chiffrement ZFS. J’exécutais autrefois plusieurs VM comme FreeIPA sur Debian+ZFS, puis pour simplifier j’ai basculé vers une structure où seule la bibliothèque chiffrée Seafile tourne sur un VPS, avec une sauvegarde vers le serveur de la maison via ZFS send/receive. Ce serveur s’allume chaque nuit, fait les mises à jour et la synchro, puis se rendort. Pour aller plus loin en sécurité, j’envisage de faire tourner le ZFS de mon desktop Linux (Fedora) en chiffrement complet. Comme mon dataset principal est déjà chiffré, la synchro vers un disque externe ou le cloud devient beaucoup plus simple. Mettre toute ma photothèque sur Seafile hébergé sur le VPS coûte trop cher, donc je cherche une autre solution.
Ton retour d’installation et les explications détaillées étaient très utiles. Je ne peux pas l’adopter immédiatement comme toi, mais j’ai décidé d’installer flame comme tableau de bord pour faire des essais avec la famille.
Ravi de te lire, ce que tu fais est vraiment intéressant. Je travaille moi aussi sur un projet similaire basé sur NixOS. Mon objectif est de créer un petit boîtier au style Apple, quasi sans configuration, que n’importe qui pourrait brancher sur son modem puis installer via un simple assistant web. C’est encore tôt, mais il tourne déjà chez moi. Il fait à la fois office de routeur hybride (OPNSense/PFSense) et de serveur d’applications (Nextcloud, Synology, Yunohost, etc.). Toute la configuration est gérée dans une seule page de modules Nix, avec DNS dynamique, certificats Let's encrypt, attribution automatique de sous-domaines pour chaque application, blocage des pubs et headscale intégré. Je travaille maintenant sur le SSO, et je vais reprendre quelques idées de ton article. Plus d’infos ici : https://homefree.host
Quand je regarde parfois mon réseau domestique, j’imagine le préjudice que cela causerait à ma famille si je mourais, ou à quel point il serait difficile pour quelqu’un d’extérieur de comprendre mon installation. Le « jeu du homelab » répond en fait à quelque chose de similaire au vieux hobby de certains « papas » qui construisent des réseaux miniatures de trains. Je ne dis pas ça de façon péjorative ; j’ai simplement l’impression que certaines personnes ont l’instinct de vouloir leur propre monde miniature totalement contrôlable.
Je me suis fait exactement la même réflexion, donc j’ai rédigé de la documentation au cas où. La partie 1 parle de l’argent et de l’emplacement des documents importants ; la partie 2 explique comment rendre la maison « plus stupide » à nouveau. Par exemple, comment supprimer les interrupteurs intelligents et remettre des interrupteurs classiques, comment migrer des services de clés comme Bitwarden vers le cloud, les coûts de maintien des domaines et des e-mails, ou encore comment remettre le routeur fourni par l’ISP. Ma femme n’était pas très enthousiaste à l’égard de la maison connectée, mais elle a été rassurée en apprenant qu’on pouvait à tout moment revenir à une « maison bête ». Honnêtement, je ne sais pas à quel point la disparition de tout cela serait gênante, mais je me console en me disant que ce ne serait plus mon problème.
Je stocke nos photos de famille sur un home lab en RAID1, et chaque nuit je fais une sauvegarde rsync sur un disque externe branché à l’ordinateur chez mes beaux-parents. Le but est qu’en cas de problème, la famille puisse y accéder facilement. Ma femme ne s’intéresse pas à l’IT, donc je lui ai simplement dit : « Tu branches l’USB et tout est là. »
Je pense qu’on peut ignorer les scénarios de menace peu utiles, comme le vol de disques physiques. En pratique, il vaut mieux conserver toutes les photos et les documents importants sans chiffrement, avec des explications faciles à comprendre. C’est plutôt le volet domotique qui m’inquiète davantage.
Réfléchir à l’avance à ce qui se passera si l’administrateur du homelab s’absente longtemps ou disparaît est vraiment important en pratique. Je n’ai pas spécialement conçu mon installation dans ce but, mais je pense qu’il faut y réfléchir davantage. L’essentiel est de laisser les données importantes et les identifiants permettant d’y accéder. Utiliser un service comme Nextcloud pour que les données se synchronisent automatiquement sur les appareils de la famille est une bonne idée, tout comme faire en sorte que la famille ou les amis manipulent eux-mêmes réellement les services. Chez nous aussi, j’essaie de faire de Home Assistant un équipement quasiment indispensable, utilisé aussi par mon conjoint. C’est plus facile à gérer quand cela existe sous forme physique plutôt que comme simple VM. Bien sûr, tout cela relève beaucoup du vœu pieux, donc il est important d’établir un vrai plan détaillé au moins avec ses proches.
J’y ai beaucoup réfléchi moi aussi. Je pars du principe que le NAS et les services Docker ne redémarreront pas correctement sans moi. Quant aux sauvegardes de mots de passe hors site, j’ai l’impression qu’elles seraient impossibles à restaurer sans aide professionnelle. Du coup, j’enregistre simplement chaque jour des snapshots incrémentaux dans de nouveaux dossiers sur un disque dur externe NTFS via cron. Cela prend moins de 50 Go, donc c’est peu coûteux à dupliquer. En cas de décès, il suffit de brancher ce disque et de copier les dossiers. J’ai aussi une copie complète de la bibliothèque Seafile sur chaque laptop. J’ai prépayé le domaine mail pour 10 ans et il est hébergé chez iCloud ; comme les photos de famille en pièce jointe saturent la capacité et font rebondir les e-mails, j’envisage peut-être migadu.
Ce domaine m’intéresse aussi beaucoup. Je voudrais prévenir que si l’on se lance dans une activité indépendante ou une startup IT, l’envie de homelab devient encore plus forte. À force, faire tourner de simples conteneurs ne suffit plus ; on finit par déposer toutes sortes de papiers pour obtenir un vrai DBA et un ASN, puis on évolue vers son propre ISP avec son propre bloc d’IP/IPV6. Beaucoup résolvent le problème de l’ingress avec tailscale, mais c’est vraiment difficile. En théorie, une architecture basée sur STUN/TURN, avec mise en cache côté serveur uniquement des fichiers statiques et accès dynamique authentifié via un mur de connexion avec magic link par e-mail, ne me semble ni particulièrement risquée ni particulièrement coûteuse. Quand on met en place un environnement de développement à distance, on trouve même un prétexte de plus pour creuser ces sujets. Liens utiles : https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT, https://en.wikipedia.org/wiki/STUN
En ce moment, je bricole avec Immich, et à chaque fois j’hésite : l’utiliser uniquement via tailscale depuis l’extérieur, ou bien ajouter un reverse proxy sur un VPS. Ce qui me préoccupe le plus, c’est de trouver une solution de monitoring/sécurité conviviale capable de détecter qui tente des attaques sur le VPS.
Mon installation est bien plus simple.
HTTP envoie les mots de passe en clair, donc il est au minimum prudent d’utiliser un certificat autosigné.
Construire soi-même l’infra ou les services directement en code, c’est tout simplement excellent pour apprendre. Le fait de pouvoir coller exactement à ses propres besoins est aussi très appréciable.
J’aimerais bien faire tourner ce genre de homelab, mais je n’ai pas le temps. Je peux installer quelque chose le week-end, mais je n’ai pas la disponibilité nécessaire pour assurer ensuite la maintenance et les mises à jour. Du coup, je laisse tout ça à un fournisseur cloud et je n’y pense plus. Je serais curieux de savoir comment ceux qui, comme moi, n’utilisent que le cloud abordent la question.
Moi aussi, avec mon ancienne installation, la maintenance n’était pas suffisamment assurée et cela me stressait. C’est ce qui m’a fait apprécier NixOS et ZFS : avec les deux, le rollback est vraiment facile. Tu fais une mise à jour, et s’il y a un problème, tu reviens immédiatement à la version précédente. Le débogage peut attendre le moment où tu as du temps. Et si l’option cloud te convient, je pense que c’est aussi très bien. Monter son propre système demande clairement du temps ; l’important est donc de comparer le coût et la valeur que chacun y trouve.
J’auto-héberge une douzaine de services, et en général les mises à jour ne prennent même pas une minute par mois. Chaque service a son dossier avec sa stack docker-compose et ses données ; pour mettre à jour, il suffit de faire
docker compose pullpuisup -d. Il peut arriver, rarement, qu’une mise à jour nécessite un changement de configuration, mais dans la plupart des cas cela se règle en quelques minutes. Sans VM, et uniquement avec Docker Compose, je pense que le self-hosting entièrement automatisé est l’approche la plus simple.Ce n’est pas juste un truc qui se règle en une journée de week-end. Dans mon cas, tout a commencé avec l’installation de Plex, et un an plus tard j’avais une structure complexe avec Proxmox et toutes sortes de briques de domotique intégrées. À moitié pour plaisanter, à moitié sérieusement : pour une configuration minimale, commence avec docker compose, c’est simple à gérer et les mises à jour restent faciles.
Je me demande s’il est vraiment nécessaire d’introduire du SSO. Si la famille ou les amis utilisent un client wireguard — c’est très simple même sur iOS — ils peuvent rejoindre le réseau domestique d’un simple bouton, puis utiliser tous les services internes sans avoir besoin de SSO séparé. À l’échelle d’un petit réseau familial, les avantages me semblent largement supérieurs aux inconvénients.
Les services que nous utilisons, comme Nextcloud ou Mealie, ont de toute façon des comptes utilisateur individuels. Grâce au SSO, chacun peut accéder à tous les services avec le même compte, et je n’ai plus à gérer moi-même les mots de passe. L’installation est un peu plus complexe, mais l’exploitation devient au contraire plus simple, ce qui augmente les chances que la famille les utilise réellement.
J’auto-héberge 20 applications, et je suis excédé à l’idée de gérer l’authentification séparément pour chacune, donc je suis en train de mettre en place du SSO. Quand on veut aussi exposer certaines applications à la famille, le fait de pouvoir gérer l’authentification en un seul endroit est prioritaire. Je ne suis pas vraiment d’accord avec la méthode mentionnée plus haut.
Je me demande pourquoi utiliser flame à tout prix. Cela revient à introduire des dizaines, voire des centaines de dépendances tierces comme node, react, redux, etc. dans un « royaume de la sécurité », alors qu’une page d’accueil pourrait très bien n’être qu’un simple fichier HTML listant des liens.
J’aimerais essayer le self-hosting avec NixOS, mais je ne suis jamais passé à l’action. Mon environnement actuel est géré avec quelques VM et un fichier docker compose par VM, avec un playbook ansible qui ne fait que copier les fichiers compose, et je garde Fedora Server une release derrière puis je fais la mise à niveau à expiration. Comme j’utilise déjà nix-darwin sur Mac, je comprends bien les avantages de la configuration Nix, mais je n’ai pas encore ressenti un gain d’efficacité ou un retour sur temps suffisant pour porter mon environnement réel vers Nix. Peut-être que ce serait différent si un LLM (grande IA) pouvait au moins me dicter les fichiers de configuration, mais pour l’instant je manque de motivation pour me lancer.
J’ai moi aussi essayé NixOS, et en une semaine j’avais migré tout mon réseau domestique ainsi que deux vrais serveurs. Cela fait maintenant 3 ou 4 mois, et j’en suis satisfait au-delà de mes attentes. Migrer des serveurs a même été plus facile que migrer des stations de travail. Récemment, je m’amuse aussi à configurer un Jetson Orin Nano sous NixOS, ce qui aurait été impensable pour moi à l’époque de Gentoo. Ce qui m’agaçait le plus avec Gentoo, c’était les temps de compilation absurdes sur du vieux matériel ; par exemple, compiler GHC sur un XPS 2019 pouvait prendre 6 heures.
Pour moi, la plus grande différence avec NixOS, c’est la facilité incroyable du rollback quand quelque chose se casse. Avec une base ansible ou compose, la sauvegarde et la restauration sont possibles aussi, mais cela suppose d’écrire et de maintenir soi-même tout ce système. Cela dit, si tu es satisfait de ton installation actuelle, c’est très bien ainsi.
Si tu fais déjà un peu d’IaC, je n’ai pas trouvé que NixOS apportait un gain d’efficacité supplémentaire si important.