Homelab : 16 services sur un seul PC

Le problème

Je voulais héberger mes propres services : IA locale, gestion de photos, domotique, monitoring, media, et plus tard de l'infra de production pour mes projets clients. Sans dépendre du cloud, sans abonnements, en gardant le contrôle complet sur mes données et mes logs.

Le tout devait tourner sur un seul PC, avec un budget matériel minimal.

Update mai 2026 : ce post couvre l'état actuel après plusieurs vagues d'évolution. Le repo didoulab-homelab (privé) trace l'historique complet via CHANGELOG, runbooks et configs versionnées.

Le hardware

Pas de rack serveur, pas de matériel entreprise. Un PC de bureau reconditionné :

Coût total : ~350€ en reconditionné + la GTX 1070 Ti récupérée d'un ancien build.

L'hyperviseur : Proxmox VE

Proxmox VE 9.1 tourne en bare-metal sur le SSD. Kernel 6.17.4-2-pve.

Le choix de Proxmox plutôt qu'un Docker sur bare-metal est délibéré : l'isolation LXC permet de compartimenter chaque service (réseau, stockage, CPU), de faire des snapshots avant chaque mise à jour, et de redémarrer un service sans toucher aux autres.

Tout démarre automatiquement (onboot: 1). Après une coupure de courant, le homelab est de nouveau opérationnel en ~2 minutes sans intervention.

Les services

IA locale : Ollama + Open WebUI

Le service le plus gourmand. Un container LXC dédié (CT 101) avec :

• 6 GB de RAM, 4 cores, 80 GB de disque sur USB SSD
• Accès GPU via device passthrough NVIDIA (pas du VFIO classique : voir plus bas)
• Ollama 0.12.5 avec 6 modèles (23 GB total) :

• Open WebUI 0.6.33 comme interface : expérience similaire à ChatGPT, entièrement locale et privée.

Domotique : Home Assistant OS

Home Assistant tourne dans une vraie VM (pas un container) : c'est le seul service qui l'exige, pour le support des add-ons et de l'USB passthrough (Zigbee/Z-Wave). 4 GB de RAM, accès direct aux périphériques USB.

Photos : Immich

Alternative self-hosted à Google Photos. 4 GB de RAM, accès à l'iGPU Intel HD 530 pour le transcodage vidéo hardware et la reconnaissance faciale. Les photos sont stockées sur le HDD Hitachi.

Data pipeline : InfluxDB + Grafana

InfluxDB stocke les séries temporelles (données Oura Ring, métriques système) sur 68 GB de SSD USB pour les performances I/O. Grafana visualise le tout avec 512 MB de RAM, ce qui est largement suffisant pour le dashboard.

Grafana sert aussi de single pane of glass pour les logs centralisés (cf section Observabilité plus bas) et pour l'alerting Telegram.

Media : Servarr

Stack complète de gestion media avec accès GPU pour le transcodage et un tunnel VPN (device /dev/net/tun). 4 GB de RAM, 4 cores, données sur le SSD USB.

Coolify : PaaS pour mes apps perso et clients

VM 300 (Ubuntu 24.04, 8 GB RAM, 80 GB sur USB SSD) qui héberge Coolify v4. Pattern :

• Apps test localhost sur *.didoulab.com (LAN-only, derrière Traefik)
• Apps prod clients sur Hetzner CX23 distant via Cloudflare Tunnel (zero-trust, pas de port forward)
• Auto-deploy GitHub via webhook reçu sur tunnel CF (path-restricted bypass : coolify.didoulab.com/webhooks/* accessible publiquement, le reste de l'UI protégé par CF Access Email OTP + 2FA)

Mon portfolio dubus.pro tourne en prod sur le node Hetzner managé depuis ce Coolify local. Migration depuis Vercel terminée le 7 mai 2026.

Authentik : IdP self-hosted

VM 117 (Debian, 2 GB RAM) qui co-héberge Authentik (:443) et Uptime Kuma (:9000). Source de vérité unique pour les comptes utilisateurs et SSO sur les services internes qui le supportent.

Infrastructure réseau et reverse proxy

Migration de Nginx Proxy Manager vers Traefik faite début mai 2026 : 19 routes migrées dans 4 fichiers conf.d/ versionnés sur Git, avec auto-reload via watch des fichiers de config. Plus de clic dans une UI pour ajouter une route, juste un YAML committé.

Observabilité et sécurité (le mini-SOC)

C'est la grosse évolution depuis la version initiale du homelab. Trois LXC dédiés à la visibilité et la détection :

Détails complets dans le post dédié sur le mini-SOC avec les rules custom MITRE ATT&CK.

Le GPU partagé sans VFIO

C'est la partie la plus intéressante techniquement.

La méthode classique pour donner un GPU à une VM, c'est le VFIO passthrough : on détache le GPU du host avec vfio-pci et on le passe exclusivement à une VM. Problème : une seule VM peut utiliser le GPU à la fois.

J'ai opté pour une approche différente. Le driver NVIDIA reste sur le host, et les containers LXC accèdent au GPU via des device mounts :

# Dans la config du container LXC
lxc.cgroup2.devices.allow: c 195:* rwm    # nvidia devices
lxc.cgroup2.devices.allow: c 509:* rwm    # nvidia-uvm
lxc.mount.entry: /dev/nvidia0 dev/nvidia0 none bind,optional,create=file
lxc.mount.entry: /dev/nvidiactl dev/nvidiactl none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-uvm dev/nvidia-uvm none bind,optional,create=file

Avantage : le GPU est partagé entre plusieurs containers. Ollama (CT 101) et Servarr (CT 114) utilisent la même GTX 1070 Ti simultanément. Pas besoin de choisir lequel a le GPU.

Inconvénient : nvidia-smi ne fonctionne pas dans les containers (NVML bloqué), mais CUDA fonctionne directement. Ollama détecte et utilise le GPU sans problème.

L'iGPU Intel est passé à Immich (CT 106) de la même façon, via /dev/dri/renderD128.

Réseau et exposition

Tout le réseau est sur un bridge unique vmbr0 en 192.168.68.0/24. Chaque container a une IP statique. AdGuard sert de DNS pour tout le réseau local (résolution noms + blocage pub + rewrites internes pour *.didoulab.com).

Traefik expose les services en HTTPS avec un wildcard cert *.didoulab.com géré par DNS-01 challenge sur Cloudflare. Le cert se renouvelle tout seul tous les 90 jours, et un seul certificat couvre tous les sous-domaines.

Pour les apps qui doivent être publiquement accessibles (comme les webhooks GitHub Coolify, ou le portfolio prod sur Hetzner), c'est un Cloudflare Tunnel par usage, avec ingress strict (path filter) et CF Access Email OTP + 2FA quand pertinent.

Stockage : 4 tiers

La stratégie de stockage est pensée pour matcher les besoins I/O de chaque service :

Le LVM thin provisioning permet de sur-allouer : les disques des VMs/containers ne consomment que l'espace réellement utilisé. Un cron horaire surveille à la fois df sur les mounts ET le data% + metadata% du thinpool LVM, et alerte sur Telegram si on approche des seuils critiques. Sans monitoring du metadata% du thinpool, une saturation entraine une corruption non récupérable sans backup.

Backups

Deux jobs PVE sur les LXC et VMs :

• Daily à minuit : tous les workloads (vzdump --all) vers le HDD Hitachi, retention 5 daily + 2 weekly
• Weekly dimanche 04:00 : critical hosts (auth, traefik, immich, wazuh, coolify, etc.) vers le SSD backup dédié, retention 2 monthly

Stratégie 3-2-1 incomplete pour l'instant : tout est encore on-site. Phase 4 du roadmap = mise en place de Backblaze B2 chiffré pour la copie offsite des données critiques.

Consommation et bruit

Un des avantages d'un PC de bureau vs un serveur rack : le bruit est négligeable et la consommation tourne autour de 35W au repos (mesuré au wattmètre). Même sous charge IA + Wazuh indexer + builds Coolify, on dépasse rarement 180W.

Sur un an : ~350 kWh soit environ 70€ d'électricité pour 16 services 24/7. L'équivalent cloud (16 services managed) coûterait facilement 100-200€/mois.

Ce que j'ai appris

1. LXC vs VM : les containers LXC sont parfaits pour 90% des services. Réserver les VMs aux cas qui l'exigent (Home Assistant, Ubuntu cloud-init pour Coolify, OS où l'isolation kernel est critique).
2. GPU sharing via device mounts : plus flexible que VFIO, permet le partage entre containers tout en gardant le driver host.
3. Stratégie de stockage : séparer les tiers selon les besoins I/O change tout en performance. Le thinpool LVM exige sa propre supervision (data + metadata).
4. Automatisation : onboot: 1 + AdGuard DNS + Traefik + cron de monitoring = l'infra se reconstruit toute seule après une coupure et m'alerte si quelque chose part en sucette.
5. Observabilité avant d'avoir besoin : déployer Wazuh + Loki + alerting Telegram quand tout va bien fait gagner des heures de debug le jour où ça casse.
6. Le repo Git comme source de vérité : tous les configs (Traefik, Wazuh rules, Grafana dashboards, scripts) versionnés. Quand un service crash, je peux comparer l'état Git avec l'état déployé pour trouver ce qui a bougé.
7. Le coût : ~350€ de hardware + 70€/an d'électricité pour remplacer des centaines d'euros d'abonnements cloud, et une infrastructure que je comprends de bout en bout.

---

Ce projet fait partie de mon infrastructure personnelle qui sert aussi de showcase technique. Retrouvez l'ensemble de mes projets et compétences sur mon parcours technique, ou découvrez mes services de création web. Pour la partie sécurité observabilité spécifiquement, voir le deep-dive sur le mini-SOC homelab.