Home Lab | Antoine Weill--Duflos

GitOps auto-heberge a la maison : gerer 30+ services avec Komodo et un cluster Proxmox

Mon, 13 Apr 2026 00:00:00 +0000

Faire tourner une poignee de services auto-heberges, c’est facile. Un seul docker-compose up et c’est regle. Mais a un moment, “une poignee” devient 30+ stacks repartis sur plusieurs serveurs, et la il faut une vraie solution pour tout gerer. C’est la ou j’en suis aujourd’hui, et la partie la plus interessante n’est pas un service en particulier, mais la couche d’orchestration qui relie tout ensemble.

Le probleme

Je fais tourner beaucoup de services chez moi. Gestion de photos, domotique, synchronisation de fichiers, NVR avec detection IA, un CRM personnel, lecteur RSS, gestion documentaire, gestionnaire de mots de passe, analytics, un serveur Matrix, inference LLM… la liste continue. Chacun est un stack Docker Compose. Chacun doit etre deploye, mis a jour, surveille, et occasionnellement debogue.

Pendant un moment, je gerais tout manuellement : SSH sur un serveur, cd dans le bon repertoire, docker compose pull && docker compose up -d, verifier les logs. Ca marche, mais ca ne passe pas a l’echelle. Quand on gere des services sur six hotes differents, on passe plus de temps sur la logistique que sur l’utilisation reelle des outils qu’on a construits.

J’avais besoin d’un plan de controle.

Le materiel : un cluster Proxmox

Tout tourne sur un cluster Proxmox VE construit a partir de materiel d’entreprise recycle :

Noeud	CPU	RAM	Role
Principal	Xeon E5-2640 (12 coeurs @ 2.5 GHz)	32 Go	Charges principales
Secondaire	Xeon E5-2430 (12 coeurs @ 2.2 GHz)	24 Go	Charges secondaires

Ce sont de vieux serveurs, le genre qu’on trouve pour presque rien. Ils sont bruyants, consomment de l’electricite, et ont plus de puissance de calcul que je n’en aurai jamais besoin. Parfait pour un homelab.

Le cluster fait tourner environ 40 conteneurs LXC. Les conteneurs LXC sont le vrai cheval de bataille : ils sont plus legers que des VMs, demarrent en quelques secondes, et offrent une isolation correcte sans le surcout de la virtualisation complete. La plupart de mes hotes Docker sont des conteneurs LXC avec quelques Go de RAM chacun.

Les serveurs : qui fait quoi

Tous les conteneurs LXC ne font pas tourner Docker. Certains hebergent des services standalone (DNS, monitoring, reverse proxy, authentification). Mais les hotes Docker sont regroupes logiquement dans Komodo comme “serveurs”, chacun etant un conteneur LXC leger dedie a un ensemble de stacks lies. Komodo voit six serveurs au total : quelques hotes Docker generalistes, une instance Home Assistant dediee, un hote de gestion de photos, un conteneur d’alertes, et le vault.

Le vault est le plus interessant. C’est en fait un NAS sous OpenMediaVault avec un GPU Intel Arc B580 installe. Cette seule carte gere le decodage video materiel pour les flux cameras de Frigate, la detection d’objets par IA, et l’inference LLM via Ollama, le tout en meme temps. J’ai ecrit sur le volet Frigate dans un article precedent.

Komodo entre en scene

Komodo est un gestionnaire de deploiement auto-heberge. Pensez-y comme une alternative legere a Portainer ou Coolify, mais axe sur la gestion de stacks Docker Compose a travers plusieurs serveurs. Pourquoi je l’ai choisi :

Gestion multi-serveur depuis un seul tableau de bord. Une seule interface pour voir et controler chaque stack sur chaque serveur.
Deploiements bases sur Git. Les stacks peuvent tirer leurs fichiers compose depuis un depot Git. Poussez un changement, et Komodo le deploie.
Mises a jour declenchees par webhook. Mon instance Gitea auto-hebergee envoie des webhooks a Komodo a chaque push. Le stack se redeploie automatiquement.
Mise a jour automatique des images. Komodo peut verifier les nouvelles images et mettre a jour les conteneurs sans intervention manuelle.
Gestion des variables d’environnement. Les secrets et la config vivent dans Komodo, pas dans le depot Git.

L’architecture est la suivante : une instance centrale Komodo Core tourne sur un serveur, et un agent leger Komodo Periphery tourne sur chaque hote distant. Le core communique avec les agents peripheriques pour deployer et gerer les stacks. C’est simple, fiable, et ne necessite pas Kubernetes.

Le workflow GitOps

C’est la que ca devient interessant. Environ la moitie de mes stacks sont geres via des depots Git sur mon instance Gitea auto-hebergee. Le workflow :

Je modifie un docker-compose.yml dans un depot Gitea
Je pousse le changement
Gitea envoie un webhook a Komodo
Komodo tire le fichier compose mis a jour
Komodo redeploie le stack sur le serveur cible

Pour les stacks qui n’ont pas besoin de fichiers compose versiones (services plus simples), Komodo gere les fichiers directement sur l’hote. Je peux quand meme les modifier via l’interface Komodo, mais ils ne sont pas sauvegardes dans Git.

La separation est intentionnelle. Les stacks complexes avec plusieurs services, des configs personnalisees, ou des changements frequents vivent dans Git. Les services simples a conteneur unique sont geres en ligne. Cela evite le surcout de Git pour ce qui n’en a pas besoin, tout en me donnant un historique complet et la possibilite de rollback pour ce qui en a besoin.

Home Assistant : un cas particulier

Home Assistant merite une mention car il est gere differemment. Toute sa configuration est dans un depot Gitea, et Komodo le surveille avec du polling et des webhooks. Quand je pousse un changement de config, Home Assistant recoit la mise a jour automatiquement. Plus besoin de SSH pour editer configuration.yaml.

Le reseau : OPNsense et VLANs

Faire tourner des dizaines de services sur un reseau plat serait un cauchemar de securite. J’utilise OPNsense comme pare-feu/routeur avec plusieurs VLANs :

Segment reseau	Fonction
Principal	Serveurs et appareils de confiance
IoT	Appareils domotiques (cameras, capteurs, ESPHome)
Lab	VMs et conteneurs experimentaux
WireGuard	Acces VPN depuis l’exterieur

Les appareils IoT ne peuvent pas communiquer entre eux ni avec le reseau principal directement : ils ne peuvent atteindre que les services dont ils ont besoin (Home Assistant, Frigate). Le reseau lab est isole pour les tests. WireGuard me donne un acces distant securise a tout.

DNS : Unbound + Technitium

Le DNS est gere par deux couches qui travaillent ensemble :

Unbound tourne directement sur OPNsense comme resolveur recursif principal. Il gere la resolution DNS en amont avec validation DNSSEC, et il est rapide, car la plupart des requetes sont servies depuis le cache.
Technitium DNS (dans deux conteneurs LXC pour la redondance) gere les zones DNS internes, pour que je puisse atteindre les services par nom au lieu de memoriser des IPs. Il fournit aussi du split-horizon DNS pour les services qui ont besoin de reponses differentes en interne et en externe.

NTP : temps GPS avec Chrony

Un detail dont je suis particulierement content : la source de temps du reseau est un recepteur GPS USB (BN-808, chipset u-blox M8N) connecte a un conteneur LXC dedie faisant tourner Chrony. Le GPS fournit un temps Stratum 1 a tout le reseau.

L’installation n’est pas parfaite : le GPS USB ne supporte pas le PPS (Pulse Per Second), donc la precision est limitee a environ 40ms a cause de la latence USB. Chrony compense avec une correction manuelle d’offset et bascule sur des serveurs NTP internet (Cloudflare, pools publics) si necessaire. OPNsense distribue ensuite le temps a tous les clients du reseau.

C’est surdimensionne pour un homelab, mais il y a quelque chose de satisfaisant a avoir sa propre source de temps disciplinee par GPS plutot que de dependre entierement de pools NTP externes.

Authelia fournit le single sign-on avec authentification a deux facteurs devant tous les services web, avec Traefik comme reverse proxy.

Stockage : le NAS vault

Le serveur “vault” est un NAS OpenMediaVault qui fait double emploi comme noeud de calcul. Il dispose de 8 disques (un NVMe pour l’OS et 7 HDD allant de 2 To a 16 To) :

Disque	Modele	Capacite
NVMe	WD BLACK SN770	500 Go (boot)
HDD 1	Seagate IronWolf	10 To
HDD 2	WD	10 To
HDD 3	WD	12 To
HDD 4	WD Green	2 To
HDD 5	WD Red	2 To
HDD 6	Seagate IronWolf Pro	16 To
HDD 7	HGST Deskstar NAS	6 To

Un melange de disques achetes au fil du temps ou en promo. La beaute de mon architecture de stockage, c’est qu’elle se fiche de l’uniformite.

L’architecture mergerfs imbriquee

Le stockage est organise en couches avec des pools mergerfs :

Un pool protege par parite : un pool mergerfs combinant 3 disques formates en btrfs. Ces disques sont proteges par la parite SnapRAID (le Seagate 16 To sert de disque de parite).
Un pool principal : un super-pool qui fusionne le pool protege par parite avec un disque supplementaire en un seul espace. C’est la qu’Immich stocke les photos, Kavita les livres, et Frigate les clips video.
Un pool photos en lecture seule : une vue mergerfs qui regroupe tous mes repertoires de photos (photos personnelles, imports DCIM) en un seul point de montage pour un acces facile.

SnapRAID effectue les syncs de parite de maniere programmee (pas en temps reel comme le RAID traditionnel), ce qui signifie :

Pas de penalite en ecriture, car les ecritures vont directement sur les disques btrfs
Si un disque tombe en panne, on peut recuperer son contenu grace a la parite + les disques restants
Les disques peuvent etre de tailles differentes (et ils le sont largement)
Chaque disque est un systeme de fichiers standard lisible individuellement en cas d’urgence

Le compromis : les donnees ecrites entre deux syncs de parite ne sont pas protegees. Pour un homelab qui stocke des photos et des medias, c’est un risque acceptable.

Proxmox Backup Server tourne aussi dans Docker sur ce meme NAS, assurant les sauvegardes de VMs et conteneurs depuis le cluster Proxmox. Les deux noeuds Proxmox montent le stockage PBS du vault directement.

Surveillance et alertes

On ne peut pas gerer ce qu’on ne voit pas. La stack de monitoring :

Outil	Role
Prometheus	Collecte de metriques
Grafana	Tableaux de bord et visualisation
Uptime Kuma	Surveillance de disponibilite
cAdvisor	Metriques de ressources des conteneurs
NetAlertX	Surveillance des appareils reseau
ntfy	Notifications push sur mon telephone

Komodo lui-meme s’integre avec ntfy pour les alertes de deploiement. Si un stack echoue a se deployer ou qu’un conteneur devient unhealthy, je recois une notification push immediatement. Le stack ntfy-alerter fait correspondre la severite des alertes Komodo aux niveaux de priorite ntfy : une alerte critique obtient un push haute priorite qui passe outre le mode Ne Pas Deranger.

L’ensemble tourne 24h/24, se gere en grande partie tout seul, et ne coute rien au-dela de l’electricite et de l’investissement materiel initial. Quand quelque chose a besoin d’attention, Komodo et ntfy s’assurent que je le sais, et le workflow GitOps fait que je peux regler la plupart des choses avec un git push depuis mon telephone.

Si vous faites tourner plus qu’une poignee de services auto-heberges et que vous les gerez encore manuellement, jetez un oeil a Komodo. Ca a transforme mon homelab d’une collection d’hotes Docker en une vraie plateforme geree.

Adieu les caméras cloud : vidéosurveillance auto-hébergée avec Frigate, Tapo et un Intel Arc B580

Sun, 12 Apr 2026 00:00:00 +0000

J’habite au Canada. À un moment j’ai commencé à remarquer des signes de passage dans mon jardin. Animal ? Personne ? Impossible à dire. Du coup j’ai décidé de mettre des caméras. Ce qui devait être un simple achat s’est transformé en un vrai setup auto-hébergé avec détection par IA. Voici l’histoire.

Le point de départ : Amazon Blink

J’ai commencé par des caméras Amazon Blink. Pas cher, sur batterie, déclenchement par mouvement, et ça tient bien le climat canadien. Pas de câblage, pas de réseau à configurer. On les colle au mur et c’est parti.

Le problème ? Les faux positifs. En permanence. Une branche qui bouge dans le vent, une ombre, de la neige qui tombe… tout déclenche une alerte. Au bout de quelques semaines, soit on finit par ignorer toutes les notifications (ce qui rend les caméras inutiles), soit on perd du temps à regarder des clips de rien du tout. Pas idéal.

C’est là que j’ai commencé à lire sur Frigate et les caméras RTSP, et les choses sont devenues intéressantes.

Le nouveau setup

Caméras Tapo

J’ai remplacé les Blink par des caméras Tapo. L’intérêt principal : elles supportent le streaming RTSP nativement et ont un slot carte micro SD pour l’enregistrement local. Concrètement :

Un backup local sur la carte SD même si le réseau tombe
Un flux vidéo direct en WiFi vers le NVR, sans passer par le cloud
Des caméras qui fonctionnent à 100% sur le réseau local, sans compte ni abonnement

Frigate

Frigate est un NVR (enregistreur vidéo réseau) open source qui a vraiment beaucoup évolué. Il offre :

Un tableau de bord unique avec les vues en direct de toutes les caméras
La détection de mouvement comme premier filtre
La détection d’objets par IA qui identifie ce qui a bougé (personne, animal, voiture…)
Des descriptions de scènes complètes qui expliquent ce qui se passe réellement dans le clip

C’est ce dernier point qui change tout. Au lieu de recevoir « mouvement détecté », on obtient quelque chose comme :

Une personne ramasse une roue de vélo Une personne entre dans le cadre par le bas à droite et marche vers le centre de la zone où une roue de vélo est posée au sol. La personne se penche, ramasse la roue de vélo et se relève en la tenant. L’individu se retourne ensuite et repart vers la caméra, sortant du cadre par le bas.

Avec ce niveau de détail, je ne suis notifié que quand il se passe vraiment quelque chose.

Le matériel : Intel Arc B580

J’ai ajouté une Intel Arc B580 (Battlemage) dans mon serveur. Cette carte fait le double travail :

Décodage vidéo : décodage matériel accéléré de tous les flux RTSP
Inférence IA : exécution des modèles de détection et de description de scènes

Le support de la B580 dans Frigate est franchement correct. Les deux charges tournent sur le GPU en même temps, ce qui laisse le CPU tranquille. Les descriptions ne sont pas toujours parfaites mais elles sont largement suffisantes pour filtrer le bruit et n’alerter que sur des événements réels.

Une seule carte, une conso raisonnable, pas besoin d’une machine dédiée au ML. Ça fait le job.

Le modele de description de scenes : llama.cpp + Vulkan

Les descriptions IA ne viennent pas du cloud non plus. Je fais tourner un serveur LLM local avec llama.cpp et le backend Vulkan sur la B580. Frigate lui envoie des captures via une API compatible OpenAI, et le modele renvoie des descriptions de scene.

Voici le docker-compose du serveur d’inference :

version: "3.9"
services:
  llama-server-intel:
    image: ghcr.io/ggml-org/llama.cpp:server-vulkan
    container_name: llama-server-intel
    restart: unless-stopped
    devices:
      - /dev/dri:/dev/dri
    volumes:
      - /var/models:/models
    ports:
      - 4040:8080
    environment:
      # Workaround pour un bug fp16 du driver Mesa ANV sur les iGPU Intel.
      # Sans risque sur les dGPU (B580), ignore si pas necessaire.
      - GGML_VK_DISABLE_F16=${GGML_VK_DISABLE_F16:-0}
    command: >
      --model /models/Qwen3.5-9B-UD-Q4_K_XL.gguf
      --mmproj /models/mmproj/mmproj9B-BF16.gguf
      --n-gpu-layers 99
      --ctx-size ${LLAMA_CTX_SIZE:-131072}
      --host 0.0.0.0
      --port 8080

Le modele utilise est Qwen3.5-9B avec un projecteur de vision, quantifie pour tenir dans les 12 Go de VRAM de la B580. Vulkan est 30-60% plus rapide que SYCL sur les GPU Intel Arc, c’est donc le bon backend pour cette carte.

Docker-compose pour Frigate

Voici la config docker-compose de Frigate :

version: "3.9"
services:
  frigate:
    container_name: frigate
    privileged: true
    restart: unless-stopped
    image: ghcr.io/blakeblackshear/frigate:stable
    shm_size: 512mb
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./config:/config
      - ./model:/model
      - ./storage:/media/frigate
      - /dev/dri/renderD128:/dev/dri/renderD128
      - type: tmpfs
        target: /tmp/cache
        tmpfs:
          size: 1000000000
    ports:
      - 5005:5000
      - 8971:8971
      - 8554:8554 # Flux RTSP
      - 8555:8555/tcp # WebRTC over tcp
      - 8555:8555/udp # WebRTC over udp
      - 1984:1984
    environment:
      PLUS_API_KEY: ${PLUS_API_KEY} # optionnel, pour Frigate+
      FRIGATE_RTSP_PASSWORD: ${FRIGATE_RTSP_PASSWORD}
      OPENAI_BASE_URL: http://llama-server-intel:8080/v1 # pointe vers le LLM local

Quelques notes :

/dev/dri/renderD128 donne a Frigate l’acces a la B580 pour le decodage video materiel
Le montage tmpfs sert de cache rapide pour les clips en cours de traitement
shm_size depend du nombre de flux camera (512 Mo suffit pour quelques cameras)
OPENAI_BASE_URL pointe vers le serveur llama.cpp pour les descriptions de scenes. Frigate utilise l’API compatible OpenAI, donc n’importe quel serveur local qui parle ce protocole fonctionne
Mettez vos secrets dans un fichier .env a cote du docker-compose, pas dans le YAML

Home Assistant

Tout se branche sur Home Assistant :

Les flux caméra et les événements Frigate apparaissent sur le dashboard HA
Les notifications passent par le moteur d’automatisation de HA
L’accès à distance se fait via la connexion sécurisée intégrée à HA

Les caméras détectent, Frigate analyse, Home Assistant notifie. Tout en local.

Pourquoi auto-héberger ses caméras ?

Vos données restent chez vous. Aucune image ne quitte votre réseau. Aucun fournisseur cloud ne stocke ou traite vos flux vidéo
Pas d’abonnement. Les caméras cloud adorent facturer au mois pour des fonctions “premium” comme la détection de personnes. Ici, zéro coût récurrent après le matériel
Beaucoup moins de faux positifs. La détection IA vs. la simple détection de mouvement, c’est le jour et la nuit
Des alertes vraiment utiles. Vous savez ce qui s’est passé, pas juste qu’il y a eu du mouvement
Fonctionne hors ligne. Le backup sur carte SD + NVR local fait que le système continue d’enregistrer même sans Internet

Résumé

Composant	Ce qu’il fait
Caméras Tapo	Flux RTSP + enregistrement local sur carte SD
Frigate	NVR open source avec détection d’objets par IA
Intel Arc B580	Décodage vidéo + inférence IA sur une seule carte
Home Assistant	Dashboard, notifications, accès distant
Serveur local	Fait tourner Frigate et Home Assistant

Pour conclure

Ça m’a pris un peu de temps à mettre en place, mais je suis vraiment content du résultat. Plus de dépendance au cloud, pas d’abonnement, et le problème des faux positifs est réglé. Les descriptions IA sont étonnamment bonnes et la B580 gère tout sans broncher.

Si vous en avez marre de recevoir des notifications pour des branches d’arbre, jetez un œil à Frigate. Le projet a beaucoup mûri et avec Home Assistant ça fait un système solide et fiable.

Et surtout : je peux enfin arrêter de vérifier mon téléphone à chaque coup de vent.