Pendant longtemps, j'ai voulu faire tourner mon propre serveur, mais le coût et la complexité me faisaient hésiter. Puis je suis tombé sur Proxmox VE — et avec le recul, je me demande pourquoi je ne l'ai pas fait plus tôt. Proxmox est une plateforme de virtualisation gratuite et open source basée sur Debian : KVM pour de vraies VM, LXC pour des conteneurs légers, et une interface web qui facilite vraiment le quotidien.
Le plus appréciable, c'est qu'on n'a pas besoin d'un serveur coûteux. J'ai commencé avec un mini-PC d'occasion (un Dell OptiPlex Micro) avec de la RAM ajoutée et un SSD NVMe — silencieux, économe en énergie et largement suffisant pour 10 à 15 conteneurs plus quelques VM. Vu le prix de l'électricité chez nous, un mini-PC qui consomme 10 à 15 watts au repos fait une énorme différence par rapport à un serveur en rack.
Après l'installation, la première chose que j'ai faite a été de désactiver le dépôt enterprise et de configurer les dépôts community, de sécuriser la connexion SSH par clé et d'installer Fail2ban. Sont ensuite venus les premiers services : Pi-hole comme bloqueur de publicités pour tout le réseau, Nginx Proxy Manager et Portainer. Cet ordre a fait ses preuves — commencer petit, ne pas lancer vingt conteneurs d'un coup.
Mon conseil le plus important, que j'ai moi-même appris à mes dépens : mettez en place les sauvegardes avant d'installer le premier service. Selon la règle 3-2-1 — et les sauvegardes par snapshot intégrées à Proxmox rendent cela presque trop simple. Au passage, le RAID n'est pas une sauvegarde — ça aussi, il m'a fallu du temps pour le comprendre.
Lancez-vous, tout simplement. Un conteneur, un service, et vous en apprendrez plus sur l'infrastructure que dans n'importe quel cours en ligne. Et si vous voulez d'abord juste essayer, un serveur cloud bon marché fait aussi très bien l'affaire pour apprendre.
Source : Homelab Guide
Selon IT之家, le NAS à quatre baies Qu405-N150-8G de QNAP est désormais en vente sur JD.com. Il est équipé de 8 Go de mémoire et bénéficie d'une garantie standard de deux ans. Le modèle seul coûte 2599 yuans, et le lot accompagné d'un disque dur Seagate IronWolf de 4 To coûte 3599 yuans.
Le design est sobre. Le châssis mesure 165 mm x 168 mm x 217 mm pour un poids net de 2,15 kg. Le processeur est un Intel N150 à 4 cœurs et 4 threads. Selon le fabricant, il peut transcoder de la vidéo en 4K et faire tourner des machines virtuelles et des conteneurs Docker, un argument de poids pour ceux qui aiment bidouiller un serveur à la maison. La mémoire SODIMM DDR4 de 8 Go livrée en standard peut être portée à 16 Go.
Le stockage repose sur quatre baies pour disques SATA de 3,5 ou 2,5 pouces. On trouve aussi à l'intérieur deux emplacements M.2 2280 NVMe PCIe Gen 3 x1, utilisables pour le cache ou pour stocker le système et les données des conteneurs. La connectique comprend deux ports réseau 2.5GbE, deux USB-A 3.2 Gen 2, un USB-C 3.2 Gen 2 et une sortie HDMI 2.1.
Je trouve que la combinaison du double 2,5G avec un N150 est devenue, ces deux dernières années, une configuration courante pour les NAS domestiques d'entrée de gamme. Elle fait tourner Docker sans consommer beaucoup d'électricité, et le prix reste assez raisonnable. Cela dit, l'article ne donne que des spécifications, sans mesures réelles. Si vous hésitez à l'acheter, mieux vaut vérifier le bruit, la consommation et l'expérience logicielle dans des tests indépendants.
Source : IT之家
Synology a annoncé pour l'Allemagne sa nouvelle gamme neo+, composée des DS725neo+, DS925neo+, DS1525neo+ et DS1825neo+. ComputerBase les décrit comme des variantes moins chères des modèles Plus, pour lesquelles seule la configuration mémoire a changé.
Selon le rapport, le « neo » signifie « option Non-ECC ». Ces appareils utilisent de la mémoire standard sans ECC, et toujours 4 Go seulement. Les DS725+ et DS925+ disposent de 4 Go de mémoire ECC, tandis que les DS1525+ et DS1825+ en ont 8 Go : les versions neo+ en ont donc moins. Pour le reste, l'équipement, les fonctionnalités et l'extensibilité sont identiques à ceux des modèles Plus, et le système DSM avec ses applications est le même.
Dans le prix de vente public recommandé, l'écart est d'environ 200 euros : le DS725neo+ est affiché à 549 euros HT, le DS725+ à 748 euros HT. Dans le commerce, la différence est toutefois moins nette : le DS725+ est actuellement disponible à partir de 663 euros, le DS725neo+ à partir de 629 euros. La mémoire peut ensuite être facilement remplacée par de la mémoire ECC.
Synology invoque la situation actuelle du marché de la mémoire, à savoir les fortes hausses de prix qui ont aussi touché les modèles Plus.
Pour un serveur domestique, je trouve ce compromis intéressant. Celui qui utilise son NAS surtout pour des sauvegardes, des médias et quelques conteneurs s'en sortira probablement avec 4 Go sans ECC. Celui qui tient à l'intégrité des données doit regarder de près ce que lui apporte le surcoût.
Source : ComputerBase
Hardware.com.br met en avant un homelab qui se distingue par sa taille réduite. Un utilisateur de Reddit a publié sur r/HomeServer un petit rack de 10 pouces comprenant un pare-feu, trois mini-PC, un NAS et toute l'infrastructure réseau nécessaire pour faire tourner des dizaines de services à la maison.
Le calcul est assuré par trois mini-PC, chacun équipé d'un processeur 8 cœurs / 16 threads et de 32 Go de RAM, soit au total 24 cœurs, 48 threads et 96 Go pour la virtualisation. Il utilise Proxmox pour créer des machines virtuelles et des conteneurs LXC. Parmi les charges de travail, on trouve une VM pour Jellyfin, la « stack arr » qui tourne sous Docker, un autre hôte Docker avec Portainer, Pi-hole et des tableaux de bord comme Homer et Homepage, ainsi que des serveurs de jeux comme Terraria et Core Keeper.
Le stockage repose sur un HP ProLiant MicroServer avec quatre disques durs de 4 To en RAIDZ1 ZFS, ce qui permet de continuer à accéder aux données même si un disque tombe en panne. On dispose de 16 To bruts, avec un espace utile plus faible à cause de la parité. Le réseau est géré par un Fortinet FortiGate, qui s'occupe du routage, des VLAN et du VPN SSL, et un onduleur APC Back-UPS 850 protège des coupures de courant.
Le plus intéressant, à mon avis, se passe hors de la maison : le propriétaire conserve deux VPS sous Debian dans des centres de données externes, reliés au homelab par un réseau WireGuard en configuration hub-and-spoke. Ils forment la couche publique de l'infrastructure, avec Traefik comme reverse proxy.
C'est un bon exemple : un homelab n'a pas besoin d'un rack gigantesque. Avec de la planification, de petits boîtiers et une bonne organisation, on peut faire tourner beaucoup de choses sur un petit espace.
Source : Hardware.com.br
Quand un même serveur héberge plusieurs projets, on finit tôt ou tard par se heurter aux ports 80 et 443, que un seul processus peut écouter. Un article de Habr issu du blog Selectel montre pas à pas comment résoudre ce problème avec Nginx Proxy Manager.
L'auteur commence par expliquer le problème : les ports privilégiés, la règle d'un seul écouteur par port, les soucis de CORS quand le frontend et le backend sont séparés par des ports, et l'absence de HTTPS. Un proxy inverse résout cela en servant d'intermédiaire et en répartissant le trafic selon le domaine et le chemin. Autre avantage : le pare-feu n'a besoin que des ports 22, 80 et 443.
L'environnement de test est un VDS avec 2 vCPU, 2 Go de RAM et 40 Go de NVMe, sous Ubuntu 24.04 avec Docker installé depuis le dépôt officiel. Le réseau est créé avec docker network create proxy, puis le conteneur jc21/nginx-proxy-manager démarre avec des volumes pour les données et les certificats. J'ai apprécié que l'interface d'administration sur le port 81 ne soit liée qu'à 127.0.0.1 et qu'on y accède via un tunnel SSH.
Ensuite, un hôte proxy est configuré : le Forward Hostname reçoit le nom du conteneur, et le certificat SSL se rattache dans l'onglet SSL. whoami de traefik sert aux tests. Le cas où l'application tourne directement sur l'hôte est aussi traité : l'adresse de passerelle du réseau Docker s'obtient avec docker network inspect, et le pare-feu est configuré pour empêcher d'atteindre l'application en contournant le proxy.
Il y a aussi quelques réserves. Les exemples mélangent des domaines différents et l'image utilise le tag latest, ce qui peut nuire à la reproductibilité avec le temps. Malgré cela, c'est un bon point de départ pour qui veut faire tourner plusieurs services à la maison ou sur un VDS sans éditer à la main les configurations nginx.
Source : Habr (blog Selectel)
Le Self-Host Weekly de cette semaine, publié par selfh.st, rassemble des actualités que les passionnés de homelab voudront connaître. J'apprécie ce type de revue, qui fait gagner beaucoup de temps de lecture de flux.
L'histoire principale est confuse : une nouvelle suite d'alternatives open source à Adobe a été dénoncée comme une copie de projets existants, notamment du populaire Photopea, dont le développeur a été l'un des premiers à tirer la sonnette d'alarme. Les deux projets au centre de l'affaire, PhotoSuite et PhotoCraft, semblent liés, et la chronologie est difficile à suivre. La revue conseille de s'en tenir à distance tant qu'ils n'auront pas prouvé qu'ils sont plus que des œuvres dérivées.
D'autres points méritent d'être signalés. Let's Encrypt annonce qu'à partir de février 2027, la durée de vie des certificats SSL gratuits passera de 90 à 64 jours, ce qui rend le renouvellement automatique encore plus important pour quiconque fait tourner un reverse proxy à la maison. Nabu Casa renomme Home Assistant Cloud en Home Assistant Link, à cause de la connotation négative que le mot « cloud » a aujourd'hui. Le projet de partage de secrets chiffrés Hemmelig a été archivé sur GitHub, et la NVIDIA Shield TV, un boîtier de streaming âgé de sept ans très apprécié des homelabs, a vu son prix augmenter de 100 dollars, une hausse attribuée à l'inflation des composants liée à l'IA.
L'auteur a aussi lancé l'enquête 2026 sur les utilisateurs de Self-Host, avec 45 questions portant sur le matériel, les logiciels, les systèmes d'exploitation, les données démographiques et l'IA. L'enquête de l'an dernier avait recueilli un peu plus de 4 000 réponses, et celle de cette année en compte déjà 2 000 en deux jours. Elle reste ouverte jusqu'au 31 octobre, et les résultats sont attendus début novembre.
Personnellement, c'est le changement sur les certificats qui me semble le plus utile : si votre configuration de renouvellement est un peu fragile, c'est le moment de la tester.
Source : selfh.st
RedesZone répond à une question très courante chez ceux qui montent un serveur à la maison : faut-il redémarrer le NAS de temps en temps, ou peut-on le laisser allumé en permanence ?
La réponse courte est oui, il peut rester allumé 24 heures sur 24. Un NAS est conçu pour fonctionner en continu, il utilise des disques de stockage prévus pour cela, et il sert aux sauvegardes, à libérer de l'espace sur d'autres appareils ou à partager de gros fichiers. Il consomme bien sûr de l'électricité, comme un routeur ou une caméra de surveillance. Cependant, ces appareils sont conçus pour consommer très peu au repos. Même après des mois d'utilisation continue, rien n'oblige à le redémarrer, en dehors d'une volonté d'économiser de l'énergie ou du fait qu'on n'en a simplement pas besoin.
Il existe toutefois des situations où un redémarrage est recommandé : après une mise à jour du système d'exploitation, du micrologiciel ou de certains paquets, même si l'appareil ne le demande pas ; en cas de problème logiciel, comme une application qui ne fonctionne plus, un service lent, une interface web qui se comporte mal ou des erreurs dans une section. Après un changement de matériel, et après toute modification importante de son fonctionnement. Il arrive qu'un processus soit bloqué ou qu'un programme ne se soit pas fermé correctement, et un redémarrage remet tout en ordre.
C'est un conseil raisonnable et sans dramatisation. Pour un laboratoire domestique, la règle pratique consiste à laisser le NAS travailler et à le redémarrer de manière réfléchie, après une mise à jour ou lorsque quelque chose se comporte bizarrement, plutôt que par habitude.
Source : RedesZone
Lorsqu'on fait tourner des applications open source sur un serveur à domicile, il faut souvent envoyer des e-mails pour les inscriptions ou la réinitialisation des mots de passe. Mais envoyer du courrier directement depuis chez soi demande de mettre en place un serveur SMTP et de configurer un domaine d'envoi, ce qui prend plus de temps qu'on ne le croit. Cet article trouvé sur Qiita règle le problème de façon pragmatique, avec Mailpit et Discord.
Mailpit est à l'origine un outil de test d'envoi de courriers. Il peut faire office de serveur SMTP et dispose d'une API de test. Avec un webhook configuré, il peut appeler une application externe dès qu'un message arrive. L'article exploite cette fonction pour construire un système qui transmet le contenu des e-mails reçus vers Discord.
L'architecture est simple : deux conteneurs lancés avec Docker Compose, Mailpit et un webhook-handler. Ce dernier est une petite application Python écrite avec FastAPI. Il reçoit les webhooks de Mailpit, met en forme l'expéditeur et le destinataire, puis les transmet à un webhook Discord. La notification peut aussi contenir un lien vers l'interface web de Mailpit pour consulter le message au besoin. Les paramètres, comme l'URL du webhook, sont placés dans un fichier .env séparé.
Même sans envoyer le moindre courriel vers l'extérieur, savoir immédiatement qu'un e-mail de réinitialisation de mot de passe est arrivé est très pratique. Pour qui fait tourner plusieurs applications dans un homelab, centraliser le courrier en un seul endroit doit grandement simplifier la gestion. L'article date d'août 2026.
Source : Qiita
Une petite histoire, mais qui mérite réflexion pour quiconque gère son propre réseau domestique. Selon GenK, un utilisateur de X nommé @NomadsGalaxy vérifiait le Wi-Fi de ses parents lorsqu'il a constaté qu'une machine à café Keurig avait généré environ 1 To d'envoi et près de 10 Go de téléchargement en seulement dix jours.
Il l'a découvert en consultant le système réseau UniFi de la maison de ses parents. Ce volume anormal a surchargé l'un des points d'accès Wi-Fi. Plutôt que d'en chercher la cause, il a débranché la machine et offert à ses parents un autre produit. Selon l'article, l'essentiel du trafic semblait rester dans le réseau interne sans sortir vers Internet ; rien ne prouve donc pour l'instant que l'appareil ait envoyé les données de la famille vers des serveurs externes. La cause la plus probable est un bogue logiciel ou une erreur de communication sur le réseau, et un redémarrage aurait pu suffire à régler le problème.
L'article évoque aussi le tableau plus large de la maison connectée : plus il y a d'appareils en réseau, plus les risques de dysfonctionnements, de failles de sécurité ou d'interruptions de service augmentent. Les objets IoT peuvent devenir une porte d'entrée pour des attaques si le fabricant ne met pas régulièrement à jour leur logiciel, et certains produits perdent l'essentiel de leurs fonctions lorsque la société ferme ses serveurs.
Pour moi, la leçon pratique est de disposer d'un outil qui surveille le trafic par appareil sur le réseau domestique, et d'envisager de séparer les objets connectés sur un réseau distinct. Sans chiffres, il est très difficile de remarquer ce que fait une machine à café.
Source : GenK
Quiconque gère un réseau domestique ou un petit homelab connaît bien le suffixe .lan : on le voit dans les interfaces des routeurs, sur les serveurs DNS internes et dans les adresses que l'on utilise pour joindre des appareils sans nom de domaine enregistré. IlSoftware.it signale qu'une candidature déposée auprès de l'ICANN pourrait en faire un domaine Internet accessible dans le monde entier.
La demande concernant le TLD .lan a été déposée par Coffee Danger, une société américaine, et elle est encore en phase de Pre-Evaluation Processing. Cela signifie que le domaine n'est pas approuvé et ne peut pas encore servir à enregistrer des adresses publiques. Cette candidature s'inscrit dans la nouvelle vague d'attribution de domaines de premier niveau lancée par l'ICANN en 2026, qui concerne des centaines d'entreprises : parmi les candidats figurent Google avec .browser, OpenAI avec .openai et .chatgpt, Meta avec .facebook, et l'italienne Aruba avec des domaines comme .pec, .vps, .lab, .roma et .ciao. Toutes les demandes restent soumises à évaluation.
Le point délicat, c'est que .lan n'est pas un nom comme les autres. De nombreux techniciens l'utilisent depuis longtemps, par exemple nas.lan, router.lan ou camera.lan. Si un nom considéré comme interne entre dans le DNS public, on risque des dysfonctionnements, des requêtes DNS qui sortent du réseau et des communications qui pourraient atteindre des destinations différentes de celles prévues.
Passionné de réseaux domestiques, je trouve cette nouvelle utile comme rappel : pour les noms internes, mieux vaut utiliser des suffixes pensés pour cet usage plutôt que de s'appuyer sur des conventions de fait. Pour l'instant, aucune décision n'a été prise, mais cela mérite d'être suivi.
Source : IlSoftware.it
Korben revient sur une commande de Cloudflare que beaucoup de développeurs utilisent déjà : cloudflared tunnel --url. Elle publie un serveur qui tourne sur votre machine à une adresse en trycloudflare.com, sans compte, sans nom de domaine et surtout sans ouvrir le moindre port sur la box. Pour qui héberge des services à la maison, c'est une façon simple de montrer un projet à quelqu'un, le temps d'un test.
La nouveauté de ces derniers jours est l'option --allowed-mail. Avant, toute personne possédant le lien pouvait se connecter au service. Désormais, l'accès peut être réservé à quelques adresses e-mail que l'on définit, avec un code à usage unique envoyé via Cloudflare Access.
Le tutoriel part d'un petit serveur web local sur le port 8080, avec une page de test servie par Python. cloudflared est le connecteur open source qui établit la connexion sortante vers le réseau de Cloudflare. Sur Mac, l'installation passe par Homebrew. Sous Debian ou Ubuntu, il faut utiliser le dépôt officiel de Cloudflare, dont la clé de signature a changé récemment : l'auteur conseille de reprendre les commandes actuelles plutôt que celles de vieux tutos.
Un dernier point m'a semblé intéressant : si vous faites travailler des agents IA avec cet outil, Cloudflare recommande un hook PreToolUse qui bloque toute commande sans --allowed-mail, afin d'éviter qu'un agent expose un tunnel public par erreur.
Pour un homelab, c'est une alternative légère à l'ouverture de ports ou à un VPN, à condition de se rappeler qu'un tunnel public reste une exposition sur Internet, même temporaire.
Source : Korben
