"Multica sur Hetzner : Journal de déploiement des Claude Agents auto-hébergés"

"## J'ai auto-hébergé Multica sur un VPS Hetzner. Voici le journal de déploiement.\n\nLa notification de facture de Claude Managed Agents est arrivée dans ma boîte mail à 23 h 03 un samedi. Trois sessions qui avaient tourné plus longtemps que prévu pendant un sprint client — l'une d'elles était restée « inactive mais techniquement en cours d'exécution » pendant une période que moi, dans mon infinie sagesse, je n'avais pas mise en pause. La facture n'était pas catastrophique. Elle était néanmoins suffisante pour me faire m'arrêter et poser une question que j'évitais depuis deux semaines : si je vais utiliser des agents de code comme coéquipiers, ai-je vraiment besoin du cloud d'Anthropic pour ça ?\n\nUne rapide note sur le nom avant de continuer. Le résumé vidéo avec lequel je travaillais appelait cet outil Multimodal. Le vrai projet sur GitHub, celui que j'ai installé, s'appelle Multica — le dépôt est multica-ai/multica, le binaire CLI est multica et le daemon est multica daemon. Pour le reste de cet article, j'utilise son vrai nom pour que les commandes de ce journal soient copiables plutôt qu'aspirationnelles.\n\nMultica se présente comme une plateforme d'agents gérés open-source : une couche qui transforme les agents de codage en terminal comme Claude Code, Codex CLI et OpenCode en coéquipiers collaboratifs auxquels on peut assigner des issues, avec lesquels on peut chatter directement et pour lesquels on peut planifier des tâches récurrentes. Le tout est auto-hébergeable. Le tout tourne sous Docker. Et le tout, une fois que je l'ai mis en route, a remplacé environ 80 % de ce que je payais au runtime géré d'Anthropic — au prix d'un VPS à 4,49 € et d'un contournement d'authentification légèrement pénible.\n\nVoici le journal de déploiement. Le serveur Hetzner que j'ai choisi, le démarrage Docker Compose, la modification exacte du fichier env qui m'a permis de dépasser l'écran de connexion cassé, l'invocation de multica daemon, le premier agent que j'ai créé, le cron Autopilot que j'ai configuré pour remplacer une Claude Routine, et la comparaison honnête à la fin. Si quelque chose sur ma machine s'est comporté différemment de ce que la documentation promettait, je le signale plutôt que de prétendre que le chemin a été sans embûches.\n\n## Pourquoi j'ai cessé de faire confiance à la facture Managed Agents\n\nClaude Managed Agents est entré en bêta publique le 8 avril 2026. Deux semaines plus tard, j'avais quatre routines qui tournaient selon un planning, un agent répondant à des webhooks et une ligne de facturation en heures de session qui se comportait très différemment d'une charge API classique. Managed Agents facture selon deux dimensions — les tarifs de tokens standard plus 0,08 $ par heure de session de temps d'exécution actif — et la seconde est celle qui vous surprend. Les tokens Sonnet 4.6 coûtent 3 $ en entrée / 15 $ en sortie par million. C'est prévisible. Une session qui reste en « running » pendant qu'un agent attend un git clone lent — c'est un compteur que je ne vois pas tourner.\n\nRien de tout cela n'est un scandale. Anthropic est transparent sur les tarifs et le compteur de runtime se met en pause quand la session ne travaille pas activement. Le problème n'est pas l'équité. Le problème, c'est le contrôle. Je voulais savoir, au watt près, ce que mes agents coûtaient et faisaient. Je voulais pouvoir en laisser un tourner six heures sans surveiller un tableau de bord. Je voulais le pointer sur un dépôt privé sans accorder l'accès à un cloud géré. Et je voulais pouvoir changer le modèle sous-jacent — Claude, GLM-4.6, quel que soit le modèle furtif de la semaine d'Open Code Zen — sans changer de forfait.\n\nMultica résout les quatre. On fait tourner la plateforme sur son propre hardware. On installe les CLIs d'agents de code sur ce hardware. On donne à Multica les clés API. Il assigne nos issues aux agents. On regarde travailler. La facture, c'est le coût du modèle sous-jacent plus le VPS.\n\n## Pourquoi Hetzner — et quelle machine j'ai choisie\n\nJ'ai essayé de faire tourner ce type de charge de travail sur des hébergeurs moins chers auparavant. Le droplet à 4 $/mois que j'utilisais l'automne dernier pour un daemon Claude Code n'avait pas assez de RAM pour faire tourner trois conteneurs Docker plus un agent lançant un workspace Node. La stack par défaut de Multica compte trois conteneurs — un backend Go, un frontend Next.js/TypeScript et une instance Postgres pour le stockage des sessions — et quand une tâche est assignée à un agent, le daemon lance le processus CLI sur cette même machine. La question de dimensionnement n'est donc pas « peut-il démarrer la stack ? » mais « peut-il démarrer la stack et en plus faire construire une application React par Claude Code sans que quoi que ce soit soit tué par OOM ? ».\n\nJ'ai choisi Hetzner pour deux raisons. Premièrement, le rapport qualité-prix en 2026 est toujours absurde. Deuxièmement, les nouvelles machines vCPU partagées du plan CX tournent sur silicon ARM Ampere Altra et les grands frères Intel/AMD côté x86, ce qui me permettait de choisir selon ma chaîne d'outils. Après l'ajustement tarifaire de Hetzner du 1er avril 2026, le CX22 est passé de 3,29 € à 4,49 €/mois — toujours 2 vCPU, 4 Go RAM, 40 Go NVMe, 20 To de trafic — et le palier supérieur, CPX21 sur AMD dédié, est autour de 7,99 €/mois. J'ai commencé sur le CX22 juste pour voir si la machine la moins chère réaliste pouvait effectivement tenir la stack.\n\nRéponse courte : oui, pour un ou deux agents simultanés. Si vous prévoyez de faire tourner quatre sessions Claude Code en parallèle, passez au CPX21 ou supérieur. Le CX22 a très bien fonctionné pour un seul agent de récupération tirant depuis un dépôt GitHub privé, mais lors d'une deuxième tâche simultanée, il a commencé à paginer sur le swap.\n\nAvant de déployer quoi que ce soit, j'ai fait ce que j'oublie toujours et que je regrette ensuite : j'ai verrouillé SSH. Authentification par clé uniquement, login par mot de passe root désactivé, ufw n'autorisant que les ports 22, 80, 443 et celui que le frontend de Multica allait exposer. J'ai aussi installé Docker Engine 27.x (LTS actuel en avril 2026) avec le script de commodité officiel, pas la version du dépôt Ubuntu, car le fichier compose de Multica utilise une syntaxe de healthcheck plus récente.\n\n## Le démarrage : trois conteneurs, un fichier env, un écran de connexion cassé\n\nLe README de Multica propose deux chemins d'installation. Le premier est celui prévu — installer la CLI localement, la pointer vers l'interface hébergée de Multica Cloud et les laisser gérer le backend. C'est le chemin sans douleur. Ce n'est pas non plus le chemin pour lequel j'étais là.\n\nLe second est le self-hosting complet. On clone le dépôt, on personnalise un fichier env et on lance toute la stack avec Docker Compose.\n\nbash\ngit clone https://github.com/multica-ai/multica.git\ncd multica\ncp .env.example .env\ndocker compose config\ndocker compose up -d\n\n\nLes trois services : db (Postgres 16), backend (API Go, port 8080), frontend (Next.js, port 3000). Les healthchecks les enchaînent correctement.\n\nLe premier démarrage a pris environ quatre-vingt-dix secondes. docker compose ps a montré les trois en bonne santé. J'ai ouvert le frontend sur http://<vps-ip>:3000 et obtenu un écran de connexion.\n\nC'est là que j'ai heurté un mur. Le flux d'authentification par défaut de Multica envoie un « code récent » via le service cloud. Quand on est en self-hosting complet, ce code n'arrive jamais. On fixe un champ de saisie à six chiffres qui ne se résoudra jamais.\n\nLe contournement : ouvrir .env et définir deux valeurs :\n\nbash\nAPP_ENV=development\nRECENT_API_KEY=\n\n\nAPP_ENV=development dit au backend de sauter la vérification du code cloud et d'accepter n'importe quel code à six chiffres. Vider RECENT_API_KEY supprime la credential cloud. Ensemble, ils vous placent dans un mode de connexion développement où le premier e-mail crée un compte et n'importe quel code à six chiffres fonctionne.\n\nAprès la sauvegarde : docker compose down && docker compose up -d. J'ai tapé 123456 et j'étais connecté.\n\nÇa mérite d'être dit explicitement : APP_ENV=development n'est pas un mode d'auth pour la production. C'est bien quand le VPS est sur un réseau VPN Tailscale sans trafic public atteignant le port 3000. Ce n'est pas bien quand le frontend est exposé à l'Internet ouvert.\n\n## Enregistrer le daemon et les runtimes\n\nAvec l'interface en marche, l'étape suivante est de brancher la couche de travail réelle. L'interface est l'endroit où l'on définit les agents et les issues ; un processus daemon séparé récupère le travail et exécute les CLIs des agents de codage.\n\nbash\ncd /opt/multica\nsudo cp ./bin/multica /usr/local/bin/\nmultica --version\nmultica auth login --server http://localhost:8080 --token <API_TOKEN>\nmultica daemon\n\n\nAu premier démarrage, le daemon détecte automatiquement quelles CLIs d'agents sont installées. Supportées : claude, codex, openclaw, opencode, hermes, gemini, pi, cursor-agent. J'ai installé Claude Code et OpenCode. Les deux sont apparus comme « connected » en cinq secondes.\n\nLe modèle de token API permet de faire tourner le daemon sur plusieurs machines contre une seule interface — une vraie flotte d'agents multi-machines sans toucher au cloud de personne.\n\nJ'ai enveloppé le daemon dans une unité systemd :\n\nini\n[Unit]\nDescription=Multica agent daemon\nAfter=docker.service\nRequires=docker.service\n\n[Service]\nType=simple\nUser=mejba\nWorkingDirectory=/home/mejba\nExecStart=/usr/local/bin/multica daemon\nRestart=always\nRestartSec=5\n\n[Install]\nWantedBy=multi-user.target\n\n\nbash\nsudo systemctl daemon-reload\nsudo systemctl enable --now multica-daemon\n\n\n## Mon premier agent : un bot de récupération pour mes propres notes\n\nJ'ai construit un NotesBot — un agent ayant accès à mon dépôt de notes Obsidian privé qui répond aux questions sans que j'aie à fouiller dans des fichiers Markdown.\n\nCréer un agent ne demande que deux champs : un nom et un system prompt.\n\n\nYou are NotesBot, a focused retrieval agent working against a cloned\ncopy of my private notes repository located at /workspaces/notes.\n\nWhen I assign you an issue, treat the issue body as a question. Your\njob is to:\n\n1. Grep the repo for the most relevant notes (use ripgrep, not find).\n2. Read the top 3-5 candidate files in full before answering.\n3. Respond with: a direct answer, the filenames you used as sources\n (as relative paths from the repo root), and a \"confidence\" line\n that is one of: high / medium / low.\n4. If you can't find anything relevant, say so explicitly and suggest\n three adjacent queries I might try instead.\n\nNever modify files. Never create new notes. You are read-only.\nUse opencode with the zen big-pickle model unless told otherwise.\n\n\nPour NotesBot, je l'ai dirigé vers OpenCode avec GLM-4.6 (contexte 200K, gratuit pendant sa fenêtre actuelle), configuré avec l'identifiant de modèle zen/big-pickle. Le daemon résout cela en quelque chose comme :\n\nbash\nopencode run --model zen/big-pickle --non-interactive \\\n --workspace /workspaces/notes-<task-id> \\\n --prompt-file /tmp/multica-<task-id>-prompt.txt\n\n\nMultica n'est pas un nouveau runtime — c'est un orchestrateur qui délègue aux runtimes que vous connaissez déjà.\n\nMa première issue : « Lesquelles de mes notes traitent de la distinction entre "open loops" et "pattern interrupts" dans la structure d'un article ? » L'agent l'a prise en charge en quatre secondes, et vingt-deux secondes plus tard NotesBot a posté sa réponse avec trois noms de fichiers sources et un marqueur de confiance « high ».\n\n## Configurer Autopilot : l'équivalent open-source de Claude Routines\n\nClaude Routines (lancé le 9 avril 2026) exécute des prompts planifiés sur l'infrastructure d'Anthropic — toutes les heures, quotidiennement, en semaine, hebdomadairement ou sur des événements webhook/GitHub. Limité à 5/15/25 exécutions par jour pour Pro/Max/Team.\n\nLa réponse de Multica est Autopilot — un planificateur de tâches récurrentes connecté au système d'issues.\n\nMa configuration :\n- Agent : NotesBot\n- Prompt : Scan notes modified in the last 24 hours. List any tool or product name mentioned for the first time in my notes history. For each, give a one-line context of where it appeared.\n- Cadence : 0 9 * * * (quotidien à 9 h)\n- Fuseau horaire : Europe/London\n\nSoyons honnêtes sur ce qu'Autopilot n'a pas : uniquement des déclencheurs planifiés. Pas de déclencheur webhook API, pas de déclencheur d'événement GitHub. Et les agents déplacent les tâches vers In Review mais pas vers Done — l'humain doit finaliser.\n\n## Comparaison honnête : Multica self-host vs Claude Managed Agents\n\nCoût : Le self-host gagne nettement. VPS à 4,49 €/mois, pas de compteur à 0,08 $/heure de session. À mon niveau d'utilisation, le VPS s'amortit dès la première semaine.\n\nContrôle : Le self-host gagne. Je peux mettre le daemon en pause, inspecter la table de sessions Postgres, lire les logs du daemon ligne par ligne et intervenir sur des tâches bloquées. Pas d'accès tiers aux dépôts privés.\n\nSurface de déclencheurs : Claude Managed Agents gagne. Les Routines supportent planning + webhook + déclencheurs GitHub. Multica Autopilot ne supporte que le planning.\n\nFinition UX : L'interface de Claude est plus soignée. Multica semble encore à un stade précoce.\n\nMulti-agent / multi-machine : Le self-host gagne par conception. On pointe plusieurs daemons VPS vers une seule interface Multica.\n\nFiabilité : Le runtime de Claude est le runtime d'Anthropic — un uptime que je ne peux pas égaler sur un CX22.\n\nOù j'utiliserais chacun : Claude Managed Agents pour les workflows d'événements GitHub. Multica self-host pour le coût, le contrôle et les scénarios avec des données privées.\n\n## Sécurité : la seule chose à faire correctement\n\nAPP_ENV=development sur l'Internet ouvert accepte n'importe quel code à six chiffres. C'est pire que pas d'authentification du tout.\n\nVoie 1 : VPN mesh Tailscale. Installer Tailscale (curl -fsSL https://tailscale.com/install.sh | sh), configurer ufw pour que les ports 3000/8080/SSH ne soient accessibles que via tailscale0. Le frontend sur http://100.x.y.z:3000 n'est accessible que depuis vos propres appareils.\n\nVoie 2 : complètement local. Faire tourner toute la stack sur un laptop ou un serveur domestique qui ne touche jamais l'Internet public.\n\nQuelle que soit la voie choisie : garder les images Docker à jour, garder le noyau hôte patché et traiter APP_ENV=development comme exclusif aux réseaux privés.\n\n## Ce que je construirais ensuite\n\n(1) Connecter la CI à l'API de création d'issues de Multica pour que les builds échoués génèrent automatiquement des issues de débogage. (2) Faire tourner un second daemon VPS dédié à un agent « relecteur » avec un modèle différent pour des passes de deuxième avis sur les PRs des agents.\n\nLa facture Claude Managed Agents a baissé de 60 % depuis que j'ai déplacé la récupération et le travail de prompts planifiés vers Multica. Le compteur d'heures de session est une ligne de facturation bien plus modeste.\n\nSi vous vous êtes posé la même question que moi ce samedi soir — ai-je vraiment besoin de ce cloud pour faire ce travail ? — la réponse, pour au moins 80 % du travail, est non. Il vous faut un VPS, Docker, Tailscale et environ deux heures.\n\nLe terminal vous attend.\n\n## Travaillons ensemble\n\nVous souhaitez construire des systèmes IA, automatiser des workflows ou faire évoluer votre infrastructure tech ? Je serais ravi de vous aider.\n\n* Fiverr (développements sur mesure & intégrations) : fiverr.com/s/EgxYmWD\n* Portfolio : mejba.me\n* Ramlit Limited (solutions entreprise) : ramlit.com\n* ColorPark (design & identité visuelle) : colorpark.io\n* xCyberSecurity (services de sécurité) : xcybersecurity.io"