- Pour gérer les services du homelab, j’ai ajouté l’accès Git à OpenCode Web UI et mis en place un flux où l’IA propose des changements, puis GitOps les déploie après revue de PR
- Environ 12 stacks docker compose ont été migrées vers Arcane et sont gérées via GitOps, avec des outils d’IA utilisés pour la maintenance des services
- Lors des mises à jour de conteneurs, il fallait auparavant passer des heures à lire les release notes, vérifier les breaking changes et faire des contrôles manuels, mais il est désormais possible de lire un résumé des release notes en quelques minutes, ce qui rend les montées de version plus simples et plus sûres
- OpenCode s’exécute en serveur et fournit un terminal, un explorateur de fichiers, un Git diff et git worktree, tout en synchronisant des sessions de code persistantes entre plusieurs appareils
- L’IA ne peut pas accéder directement aux services en production et ne peut pousser que vers des branches Git, ce qui empêche le déploiement de code non revu
Flux de gestion du homelab
- J’ai facilité la gestion du homelab en donnant à OpenCode Web UI l’accès à Git ; quand OpenCode pousse des changements dans Git, un humain approuve la PR puis GitOps déploie les modifications
- OpenCode s’exécute comme serveur, et les sessions de code persistantes sont synchronisées entre plusieurs appareils
- Les services gérés représentent environ 12 stacks docker compose ; ils ont récemment été migrés vers Arcane pour être administrés et déployés via GitOps
- Le premier cas d’usage des outils d’IA a été la mise à jour des conteneurs
- Avant, il fallait trouver les release notes de chaque service, vérifier les breaking changes, lancer la mise à jour, puis contrôler manuellement les problèmes éventuels sur chaque service
- Ce processus prenait plusieurs heures, mais il est maintenant possible de lire des résumés des release notes en quelques minutes, ce qui rend les montées de version plus simples et plus sûres
- L’IA a aussi servi à ajouter des healthchecks à la plupart des conteneurs, ce qui permet de détecter les problèmes plus rapidement
OpenCode
- J’utilisais surtout Claude Code, mais comme les fournisseurs d’IA réduisent la valeur apportée aux clients avec des limitations de tokens, j’ai commencé à regarder d’autres options
- L’outil recherché devait offrir un environnement de développement pris en charge par les principaux plugins, sans dépendre d’un fournisseur particulier
- Après avoir essayé plusieurs environnements de développement, j’ai retenu OpenCode, qui était l’outil que j’ai préféré parmi toutes les options testées
- La présence d’un serveur web intégré et d’une interface web dans OpenCode a été le point de départ de l’idée d’une plateforme de développement IA pour le homelab
Plateforme de développement IA
- J’ai créé sur l’hôte Truenas une VM simple avec les outils de développement de base, puis ajouté le serveur web OpenCode comme unité systemd
- Cet environnement fournit un terminal intégré, un explorateur de fichiers, Git diff et la prise en charge de git worktree, ce qui permet de gérer plusieurs sessions de développement en parallèle
- L’interface web mobile d’OpenCode m’a particulièrement plu pour ses fenêtres pop-up de questions-réponses
- Sur le serveur Git, j’ai créé un utilisateur dédié à OpenCode avec une clé SSH dédiée
- OpenCode peut cloner les projets et pousser des branches
- Il ne peut pas pousser directement vers la branche de déploiement
- Le workflow place l’IA avant la revue de PR : OpenCode prépare les changements, puis un humain fusionne directement via la PR
- Cette structure évite que du code non revu soit déployé
- La VM peut accéder à Internet et au serveur Git, mais pas aux services réels
- Comme le périmètre d’impact est réduit, j’ai jugé acceptable de donner à OpenCode les droits root sur la VM lorsqu’il faut installer des outils de build ou des dépendances de test
- Cette architecture pourrait évoluer vers une plateforme de développement en production sous forme de conteneurs temporaires pour les développeurs, avec des outils préinstallés, des garde-fous d’accès et des journaux d’audit
- La configuration actuelle fournit les fonctions nécessaires sans accumuler trop de composants
Workflow
- Le flux de travail de base commence par une phase de planification d’une fonctionnalité ou d’une amélioration dans OpenCode
- Le plan inclut les spécifications, le plan d’implémentation et une auto-revue
- Quand c’est possible, les changements sont testés ou validés
- Si certains points ne me conviennent pas, je les retravaille de manière itérative avec OpenCode
- OpenCode pousse ensuite les changements sur une branche de fonctionnalité
- J’ouvre une PR depuis cette branche et, si le résultat me satisfait, je fusionne la PR
- Après la fusion, GitOps prend le relais pour le déploiement
- Les changements sur les services docker sont gérés par Arcane
- Les changements de configuration Home Assistant sont gérés par le plugin GitOps
- Les changements sur le blog sont gérés par le worker Cloudflare Pages
Combinaison Arcane GitOps + OpenCode
- J’ai déplacé les services de Truenas vers un projet Arcane GitOps, avec comme objectif principal de gérer dans un dépôt basé sur Git toutes les stacks docker compose qui tournaient sur Truenas
- En y ajoutant OpenCode, cette approche a mieux fonctionné que prévu
- Je peux mettre à jour le networking de tous les conteneurs depuis mon téléphone, ce qui simplifie nettement la gestion d’une configuration dispersée
- Avant, il fallait plusieurs heures pour passer en revue toutes les stacks compose et suivre les connexions réseau
- Maintenant, il suffit d’indiquer à OpenCode la base de code et l’objectif, puis de vérifier les changements générés dans la PR avant de fusionner
Limites restantes et contrôle d’accès
- Le plus gros manque reste le feedback CI
- Sur GitHub, les agents de code peuvent consulter les logs Actions pour diagnostiquer les tests en échec, les erreurs de linter, les stack traces et les changements dans les plans IaC
- Cette approche aide à conserver une boucle de feedback rapide, même pour des changements que les tests unitaires ne couvrent pas
- Sur Forgejo, ce flux est plus difficile
- Forgejo Actions n’expose pas les logs des jobs via une API publique
- Il existe bien une API non documentée, mais je ne veux pas construire cette architecture sur cette base
- La configuration actuelle permet à l’IA de produire des changements pour l’infrastructure domestique depuis n’importe quel appareil, sans accès direct aux services concernés
- Je peux commencer une modification sur mon ordinateur, relire la PR sur mon téléphone, puis laisser GitOps gérer le déploiement
1 commentaires
Commentaires sur Hacker News
Je cherche encore une façon d’intégrer l’IA adaptée à mon environnement. Pour l’instant, il n’y a pas d’interaction entre Forgejo et l’agent de code, et j’ai aussi testé le runner Forgejo Actions, mais la gestion du contexte restait floue
On peut récupérer ce qui est dans les issues ou les PR, mais dès qu’il y a plusieurs allers-retours ou que la discussion passe de l’issue à la PR, ça devient vite confus
Je fais quelque chose de similaire, mais au lieu d’un serveur opencode permanent, j’utilise un workflow qui exécute opencode dans un runner d’actions Forgejo : https://codeberg.org/dragonfyre13/forgejo-opencode
C’est encore en cours d’ajustement, mais l’idée est d’invoquer Opencode avec
/ocdans une issue Forgejo pour qu’il revienne avec une PR à relireJ’ai parfois l’impression que dans la tech, beaucoup de gens vivent indépendamment presque la même chose au même moment, mais que peu prennent le temps de l’écrire ou de la partager
Je construis moi aussi un système similaire, donc lire le billet et les commentaires m’a fait plaisir en voyant que tout le monde passe par les mêmes étapes
Le problème, c’est qu’on passe 99 % du temps à bidouiller des trucs cool et seulement 1 % à en parler. Il faut en parler davantage
Je parlais avec un avocat et, alors que le temps touchait presque à sa fin, j’ai voulu poser “juste une dernière question”. Il m’a répondu : “réservez 30 minutes de plus et on en parle”. C’est une façon de faire équitable
Je cherchais une motivation pour écrire sur mon lab IA, et ce billet m’a donné exactement l’impulsion qu’il me fallait
Ma configuration repose sur une idée similaire, mais avec n8n/git/argo/k3s, surtout pour des workflows d’automatisation que Qwen ou Gemma4 peuvent gérer
Je me demande si quelqu’un sait pourquoi ce domaine est bloqué par le résolveur Quad9. Quad9 filtre le domaine, donc impossible d’ouvrir le site web
Le résultat de
dig @9.9.9.9 rsgm.dev NScontientEDE: 17 (Filtered)Il y a deux raisons principales pour lesquelles je n’utilise pas encore cette configuration : les ressources qu’il faut donner à la VM qui exécute opencode pour compiler le projet, et des tests plus rapides
Je fais tourner mon agent de code pi directement sur mon Mac, ainsi que tout l’ensemble logiciel avec redis, postgres, kratos, etc. Quand l’agent tourne sur la machine de développement principale, je peux compiler plus vite et vérifier les changements plus rapidement en recompilant seulement le backend, en le redémarrant, puis en testant immédiatement depuis le client UI
Je fais moi aussi quelque chose de très proche. J’exécute OpenCode dans un LXC Proxmox, avec une couche Kimaki par-dessus pour ajouter une intégration Discord
Qu’on aime ou non, pouvoir discuter avec la base de code est assez génial, et si ça vous plaît, il y a même les messages vocaux
Excellent. Le home lab IA a l’air de pouvoir devenir extrêmement amusant
En ce moment, je fais en sorte que Claude administre mon home lab sur l’ensemble de mes équipements, et l’installation ainsi que la maintenance du home lab sont passées de “piège fascinant pendant des années, sans jamais vraiment bien marcher et qui mange du temps” à “bonne idée concrète qui étend réellement mes capacités”
Pour des tâches très étroitement définies comme “fais-moi un fichier docker compose” ou “donne-moi une config NSD”, ça va, mais même dans ce cas, il faut déjà savoir quelles technologies sous-jacentes sont nécessaires et quoi demander
Ajouter l’accès Git à l’interface web d’OpenCode pour simplifier la gestion du home lab, puis laisser OpenCode pousser sur Git, me faire approuver la PR et laisser GitOps déployer les changements, ça semble être une assez bonne configuration
Mais avant de lire, je me demande si, pour faire quelque chose de similaire, il faut dépenser plusieurs milliers de dollars en RAM et GPU
Nous faisons aussi quelque chose de similaire, mais en laissant l’agent ouvrir lui-même les PR, et nous suivons les métadonnées de release ainsi que les sessions d’agent avec le système ReARM
Récemment, l’agent a aussi lancé une option pour suivre les déploiements basés sur Helm via ReARM : https://docs.rearmhq.com/workflows/devops.html
Malheureusement, Forgejo n’a pas de CLI comme GitHub