Pourquoi j’ai décidé de construire un Homelab
Au départ, mon objectif était assez simple : je voulais mieux comprendre Docker et pouvoir héberger moi-même quelques services. Mais, à mesure que j’avançais, ce projet est devenu beaucoup plus qu’une installation technique. Mon Homelab est aujourd’hui un véritable espace d’apprentissage, de création et d’expérimentation.
Je voulais disposer d’un environnement dans lequel je pouvais tester librement une application, me tromper, recommencer et documenter ce que j’avais appris. Je souhaitais également éviter de dépendre entièrement de services externes pour mes projets personnels. Héberger moi-même certaines applications me permet de comprendre ce qui se passe réellement derrière une interface web : les conteneurs, les volumes, les réseaux, les ports, le reverse proxy, les certificats et les sauvegardes.
Mon Homelab s’est donc construit autour de deux environnements complémentaires : un ordinateur local sous Fedora Silverblue et un VPS sous Ubuntu Server. Le premier me sert d’atelier privé. Le second héberge les services et les sites qui doivent rester accessibles en permanence.
Cette séparation est devenue l’une des idées centrales du projet : je développe et je teste en local, puis je déploie sur le VPS lorsque le résultat est suffisamment stable.
Les objectifs du projet NVSD
Je n’ai pas construit cette infrastructure uniquement pour accumuler des conteneurs. Chaque service doit avoir une fonction claire.
Mon premier objectif est pédagogique. Je veux apprendre à administrer un environnement Docker de manière structurée, sans masquer les aspects techniques importants. Utiliser une interface graphique peut simplifier certaines opérations, mais je souhaite aussi comprendre les fichiers Compose, les volumes persistants et les réseaux utilisés par les applications.
Mon deuxième objectif est pratique. Mon Homelab doit me permettre d’héberger mes sites, de tester de nouvelles applications et de disposer d’outils utilisables au quotidien. Le site NVSD, le projet Villa, le site consacré au Homelab et l’expérience artistique Concerto à l’Infini font partie de ces réalisations.
Mon troisième objectif concerne l’intelligence artificielle locale. Avec Ollama et Open WebUI, je peux exécuter des modèles sur mon propre ordinateur, expérimenter avec l’assistance au code et préparer du contenu sans envoyer systématiquement toutes mes données vers un service distant.
Enfin, je veux documenter le parcours complet. Les réussites sont importantes, mais les erreurs le sont tout autant : port déjà occupé, permission refusée, volume mal monté, réseau Docker incomplet ou configuration Nginx incorrecte. Ces incidents font partie de l’apprentissage et serviront de base aux prochains articles.
Deux environnements aux rôles différents
Mon laboratoire local sous Fedora Silverblue
Mon environnement local fonctionne sous Fedora Silverblue. Cette distribution possède une approche particulière : le système de base est immuable, tandis que les applications et les outils peuvent être isolés à l’aide de Flatpak, Toolbox ou de conteneurs.
Docker y constitue la base de mon Homelab. J’organise mes stacks dans le répertoire suivant :
/srv/homelabCet emplacement contient notamment les stacks Docker, les données, les sauvegardes, les configurations, les scripts, la documentation et mes projets. Cette organisation me donne un point de repère stable. Au lieu d’éparpiller les fichiers sur le système, je sais où chercher lorsqu’une stack doit être modifiée, sauvegardée ou déplacée.
Le poste local accueille notamment Dockge, Nginx Proxy Manager pour mes essais internes, Open WebUI, Ollama et plusieurs projets de développement. Il me permet de tester une nouvelle stack sans affecter les services publics.
Mon VPS sous Ubuntu Server
Le second environnement est un VPS sous Ubuntu Server. Son rôle est différent : il doit rester disponible et héberger les services publics.
Sur ce serveur, mes fichiers sont regroupés sous :
/opt/homelabJ’y retrouve la même logique générale qu’en local, avec les stacks de Dockge, Nginx Proxy Manager et mes différents sites. Cette cohérence entre /srv/homelab en local et /opt/homelab sur le VPS simplifie beaucoup le passage d’un environnement à l’autre.
Le VPS héberge actuellement plusieurs sites statiques et applications web. Nginx Proxy Manager reçoit les requêtes publiques, associe chaque sous-domaine au bon conteneur et gère les connexions HTTPS.
L’architecture générale : du local vers le VPS
Mon architecture peut être résumée ainsi :
PC Fedora local
↓ développement et validation
Internet / DNS / HTTPS
↓ publication
VPS Ubuntu + DockerEn local, je construis l’application et je vérifie son fonctionnement. Chaque projet possède son propre fichier Compose, ses variables d’environnement et ses volumes. Lorsque le projet est prêt, je prépare son déploiement sur le VPS.
Sur le serveur, les services publics rejoignent un réseau Docker commun utilisé par le reverse proxy. Nginx Proxy Manager peut alors joindre les conteneurs par leur nom, sans exposer inutilement tous leurs ports sur Internet. Le domaine ou le sous-domaine pointe vers l’adresse publique du VPS, puis le reverse proxy transmet la requête au bon service.
Cette architecture me permet de séparer trois responsabilités :
- le développement et les tests restent sur mon poste local ;
- l’accès public est centralisé par Nginx Proxy Manager ;
- les données importantes sont conservées dans des volumes et intégrées à une stratégie de sauvegarde.
Cette séparation n’est pas parfaite ni définitive. Elle évolue avec mes besoins, mais elle constitue désormais une base suffisamment claire pour ajouter de nouveaux projets sans reconstruire toute l’infrastructure.
Les principaux services de mon Homelab
Docker Compose
Docker Compose est le socle de l’ensemble. Chaque application est décrite dans un fichier YAML : image utilisée, ports, volumes, variables d’environnement, dépendances et réseaux. Cette méthode rend une stack beaucoup plus facile à comprendre et à reproduire qu’une longue suite de commandes lancées manuellement.
Dockge
J’ai choisi Dockge comme interface principale pour gérer mes stacks. Il me permet de visualiser leur état, de consulter les journaux, de démarrer ou d’arrêter les services et de modifier les fichiers Compose depuis une interface claire.
Je conserve néanmoins les commandes Docker dans mon apprentissage. L’interface facilite l’administration quotidienne, tandis que le terminal reste indispensable pour diagnostiquer précisément une erreur.
Nginx Proxy Manager
Nginx Proxy Manager assure le lien entre mes noms de domaine et mes conteneurs. Plutôt que de mémoriser une série de ports, je peux utiliser des adresses comme nvsd.ch, villa.nvsd.ch ou d’autres sous-domaines réservés à mes projets.
Il centralise également la gestion des certificats TLS. Pour un site public, ce rôle est essentiel : une application peut fonctionner parfaitement dans son conteneur tout en restant inaccessible si son réseau, son proxy ou son certificat est mal configuré.
Ollama et Open WebUI
Ollama me permet d’exécuter des modèles d’intelligence artificielle en local. Open WebUI ajoute une interface web pour dialoguer avec eux. Cet ensemble constitue mon atelier IA privé.
Je l’utilise pour expérimenter, préparer du contenu et tester l’assistance au développement. Les capacités restent liées au matériel disponible, notamment à la mémoire de la carte graphique, mais cette contrainte m’aide aussi à choisir des modèles adaptés au lieu de chercher systématiquement le plus volumineux.
Mes sites et projets
Le Homelab accueille aussi mes propres réalisations. Le site NVSD constitue ma présence principale. Le site Villa est un autre projet déjà déployé. Concerto à l’Infini explore quant à lui le lien entre nombres premiers, musique, images et fractales.
Ces projets donnent une utilité concrète à l’infrastructure. Ils m’obligent à dépasser le simple test technique : un service public doit être accessible, compréhensible, sauvegardé et maintenable.
Une organisation de fichiers pensée pour durer
L’un de mes premiers apprentissages a été l’importance de la structure des répertoires. Une stack peut fonctionner avec des fichiers placés presque n’importe où, mais cette liberté devient rapidement un problème lorsque le nombre de services augmente.
J’ai donc retenu une organisation commune :
homelab/
├── stacks/
├── data/
├── backups/
├── configs/
├── scripts/
├── docs/
└── projects/Les stacks contiennent les fichiers Compose. Les données persistantes sont séparées lorsque cela est pertinent. Les scripts regroupent les opérations répétitives, comme les sauvegardes. La documentation conserve les informations qui seront indispensables plusieurs mois plus tard : ports, réseaux, chemins, dépendances et procédures de restauration.
Cette organisation n’est pas seulement esthétique. Elle réduit les erreurs et facilite les migrations. Lorsque je dois déplacer une stack du poste local vers le VPS, je peux identifier plus rapidement ce qui relève du code, de la configuration ou des données persistantes.
Les premières difficultés rencontrées
Mon parcours n’a pas été linéaire. Plusieurs problèmes sont revenus régulièrement.
Le premier concerne les ports. Deux conteneurs ne peuvent pas publier le même port sur la même machine. J’ai par exemple rencontré un conflit lorsqu’un service utilisait déjà le port prévu pour WordPress. La solution n’était pas de supprimer la stack existante, mais d’attribuer un autre port au nouveau service.
Le deuxième concerne les permissions. Fedora Silverblue utilise SELinux, qui ajoute une protection importante mais demande parfois d’adapter les montages de volumes. Sur le VPS, certains fichiers créés par des conteneurs appartiennent à des utilisateurs différents. Une application peut donc démarrer tout en étant incapable d’écrire dans son dossier de sortie.
Le troisième concerne les réseaux Docker. Un reverse proxy ne peut joindre un service que s’ils partagent un réseau adapté. J’ai appris à vérifier les réseaux réels d’un conteneur, à tester la connexion depuis un conteneur temporaire et à ne pas supposer qu’un port publié suffit à tout résoudre.
Enfin, les sauvegardes demandent une vraie méthode. Créer une archive ne suffit pas : il faut pouvoir lire les fichiers protégés, chiffrer les données sensibles, envoyer la copie vers un stockage distant et, surtout, vérifier qu’une restauration serait possible.
Ce que mon Homelab me permet aujourd’hui
Aujourd’hui, je dispose d’une base fonctionnelle. Je peux lancer et administrer des stacks Docker en local, tester mes projets, utiliser des modèles d’IA sur ma propre machine et déployer des sites sur mon VPS.
J’ai également mis en place une organisation plus cohérente entre mes deux environnements. Dockge me donne une vue simple des stacks, Nginx Proxy Manager dirige les visiteurs vers les bons services et mes sauvegardes peuvent être externalisées de manière chiffrée.
Tout n’est pas terminé. Le site Homelab lui-même doit encore évoluer, le thème WordPress sera affiné au fil des vrais articles et certaines procédures devront être automatisées. Mais l’infrastructure a atteint un point important : elle ne constitue plus une succession de tests isolés. Elle forme désormais un ensemble que je peux expliquer, maintenir et faire progresser.
La suite de cette série
Ce premier article présente la vision générale. Les prochains entreront progressivement dans la pratique, avec les commandes, les fichiers Compose, les contrôles et les erreurs rencontrées.
Je commencerai par la préparation de Fedora Silverblue et la création de la structure /srv/homelab. Je détaillerai ensuite l’installation de Docker, la mise en place de Dockge, l’organisation des réseaux, l’installation de Nginx Proxy Manager, le déploiement sur le VPS et la stratégie de sauvegarde.
Mon objectif n’est pas de proposer une architecture universelle. Je veux documenter une construction réelle, avec ses choix, ses ajustements et ses limites. Si cette série peut aider quelqu’un à comprendre Docker, à éviter une erreur que j’ai rencontrée ou simplement à commencer son propre Homelab, elle aura pleinement rempli son rôle.