Auto-hébergement : services, infrastructure et pièges du DIY familial
Sommaire
En bref
- Un développeur documente son stack d'auto-hébergement (Jellyfin, Immich, Home Assistant, etc.) sur du matériel modeste.
- Le fil HN enrichit le sujet : débat sur la complexité réelle des *arrs, choix entre docker/k8s/natif, matériel occasion vs neuf, gestion des accès distants.
- Question centrale : comment maintenir durablement ces services, surtout si la famille en dépend ?
Ce que dit la source
L'auteur expose son approche personnelle de l'auto-hébergement : une sélection de services (télémétriques, médias, domotique, surveillance) déployés sur du matériel bas de gamme, avec accès distant sécurisé via Caddy et certificats LetsEncrypt. Le fil HN valide globalement cette démarche tout en signalant ses pièges : maintenance manuelle, absence de déclaration d'infrastructure, risque que la famille ne puisse plus accéder aux données critiques en cas de défaillance du mainteneur.
- Les *arrs (Sonarr, Radarr, Lidarr) consomment peu en idle (157–159 MB), contrairement à l'idée reçue de gourmandise ; leur frein réel est la complexité UX et les nombreuses dépendances à configurer.
- Débat récurrent : déployer en natif vs Docker vs Kubernetes (k3s). Plusieurs commentateurs défendent k8s sur NixOS pour la déclaration complète ; d'autres jugent cela overkill pour quelques services.
- Pour l'auto-hébergement, utiliser SQLite plutôt que Postgres/Redis par service simplifierait drastiquement la maintenance.
- Accès distant : Tailscale + Samba suffit pour un setup minimaliste, mais Tailscale impose un client sur mobile ; alternatives mentionnées (Pangolin) promettent l'accès public avec auth intégré sans VPN.
- Matériel : NUC d'occasion 8e génération offre bien meilleur rapport qualité/prix (110 €, 4,7 W idle, x86) qu'une Beelink N100 (risque de surchauffe, support médiocre).
Dans les commentaires
Débat équilibré et pratique. Peu de consensus, mais plusieurs angles utiles : acceptation des *arrs, divergence claire sur déploiement (natif vs conteneurs), remise en question de l'auto-hébergement familial comme lieu de données critiques.
- Tension constructeur : simple (docker-compose) vs robuste (k8s/NixOS). Un commentateur y voit de l'overkill ; un autre souligne que k8s simplifie effectivement les intégrations sur plusieurs services.
- Matériel : avertissement sur les Beelink N100 (surchauffe, BIOS incohérent) ; contreproposition : NUC d'occasion ou Macbook M1 cassé (250 € sur eBay, fanless, bon idle).
- Bus factor familial : si vous disparaissez, votre femme peut-elle récupérer les photos Immich ? Plusieurs commentateurs recommandent de réserver l'auto-hébergement aux données non critiques et de garder cloud (Ente Photos) pour la famille.
- Email : l'auteur ne mentionne pas sa stratégie ; un commentateur propose mbsync + Roundcube pour fédérer plusieurs inboxes sans héberger le serveur SMTP (compromis pratique).
Alternatives citées : Tailscale (VPN basé sur WireGuard, alternative intermédiaire à l'exposition publique) ; Ente Photos (cloud autohébergeable pour photos familiales) ; Samba (partage réseau léger en place de solutions cloud) ; NixOS + k3s (pour déclaration d'infrastructure) ; Foobar2000 + VLC (lecteurs légers en client).
Notre lecture
L'auto-hébergement est viable pour une personne technique, mais le fil rappelle que la durabilité dépend de trois choix : (1) une infrastructure déclarée et testée, pas du bricolage manuel ; (2) du matériel fiable et bas coût (occasion fiable > neuf exotique) ; (3) une séparation claire entre données personnelles (auto-hébergées) et données familiales critiques (cloud avec partage de mot de passe de secours). À surveiller surtout si la famille dépend du service : l'absence de plan de succession ou de documentation tue rapidement ces setups.