Chaque install de Hermes Agent a un réglage de sandbox qui décide où les commandes shell s'exécutent vraiment. Ce choix pèse : il fixe le rayon de souffle d'une mauvaise commande, la vitesse perçue de l'agent, et ce que tu paies par heure active.
Hermes embarque sept backends. Le README les énumère : local, docker, ssh, singularity, modal, daytona, vercel. v0.14.0 a ajouté Vercel Sandbox pour compléter la liste. Voici l'arbre de décision.
Les 7 backends, dans un tableau
| Backend | Isolation | Latence | Coût | Persistance | Pour qui / quoi |
|---|---|---|---|---|---|
| local | Aucune | <10 ms | Gratuit | Oui (ton disque) | Solo dev sur une VM jetable |
| Docker | Conteneur | ~50 ms | Gratuit | Par conteneur | Par défaut sur n'importe quelle box dev |
| SSH | Ce que le distant a | Latence distante | Coût distant | Oui | Quand l'agent vit sur la box de quelqu'un d'autre |
| Singularity | Conteneur HPC | ~100 ms | Gratuit | Par conteneur | Clusters HPC, calcul scientifique |
| Modal | Conteneur serverless | ~200 ms à froid | À la seconde active | Snapshot possible | Calcul en rafale, GPU |
| Daytona | Workspace serverless | ~300 ms à froid | À la seconde active | Hiberne au repos | Environnements d'agent qui durent, coût quasi nul au repos |
| Vercel Sandbox | Conteneur serverless | ~200 ms à froid | À la seconde active | Éphémère | Outillage web, workflows JS lourds |
local et docker sont gratuits et tournent sur ta machine. Les cinq autres tournent ailleurs — tu paies en latence, tu paies en dollars, mais en échange tu achètes quelque chose.
Quand prendre lequel
local — « je fais confiance à cet agent sur cette machine »
L'agent lance des commandes directement sur ton filesystem avec tes permissions utilisateur. Aucune isolation. Si l'agent décide rm -rf ~/code, ça part. Si une prompt injection arrive dans la sortie d'un outil, la commande injectée tourne.
Quand c'est le bon choix : tu bricoles sur une VM jetable, l'agent fait des choses que tu ferais toi-même avec le même rayon de souffle, et la latence à zéro compte plus pour toi que la marge de sécurité.
Quand c'est le mauvais choix : à peu près tout autre moment.
docker — le bon défaut
Un conteneur sur ta machine, isolé par des namespaces Linux. La vue filesystem de l'agent, c'est celle du conteneur ; ton vrai /home est invisible tant que tu ne le montes pas.
hermes config set sandbox docker et hermes setup tirent et configurent l'image. Après ça, chaque appel d'outil shell passe par le conteneur.
C'est le bon défaut pour environ 80 % des utilisateurs. Le surcoût de latence (~50 ms par commande) est invisible en chat. L'isolation est assez forte pour qu'un rm -rf / ne grille que la vue du conteneur, et le conteneur est jetable. Tu peux faire un docker exec si tu dois debugger.
ssh — « l'agent vit sur une autre box »
Les outils shell de l'agent s'exécutent par SSH sur un host distant. Ton processus Hermes local est le client ; le travail se passe sur le distant.
C'est le bon choix quand le travail de l'agent appartient au distant — déploiement sur un serveur, debug de logs de prod, lancement de migrations. Tu n'as pas besoin de sandbox locale parce que le host est la sandbox.
Le distant doit être une box à laquelle tu acceptes de donner un accès shell à l'agent. Traite les credentials SSH comme des credentials de prod, parce que c'est ce qu'elles sont.
singularity — clusters HPC
Singularity (maintenant Apptainer) est le runtime de conteneurs que les clusters HPC utilisent vraiment, parce que Docker demande root sur le host et que les environnements HPC ne le donnent pas. Si tu fais tourner Hermes sur un cluster de recherche — planifié par SLURM, sans Docker, beaucoup de GPUs — c'est le bon choix.
Si « HPC » ou « Singularity » ne te disent rien, saute ce point.
modal — calcul en rafale, surtout GPU
Modal est une plateforme de conteneurs serverless. Hermes lance un conteneur Modal par commande (ou par session, avec réutilisation), exécute la commande, puis le détruit. Tu paies à la seconde de calcul actif. Des paliers GPU sont disponibles.
Quand ça bat Docker : l'agent a besoin de GPUs ou de ressources de calcul que ta box locale n'a pas. Quand ça bat les autres serverless : le démarrage à froid est de ~200 ms, ce qui est acceptable pour de l'utilisation d'outils au rythme du chat, et le snapshotting est assez bon pour que l'état de milieu de session survive raisonnablement.
daytona — longue durée, quasi zéro au repos
L'argument-massue de Daytona, c'est l'hibernation. L'environnement de ton agent s'endort quand rien ne se passe et se réveille à la demande en quelques centaines de ms. Tu paies les secondes actives, pas les secondes de repos.
Effet pratique : tu peux avoir un environnement « mon Hermes » avec tes dotfiles, tes skills, ton travail en cours, qui vit pendant des mois à un coût quasi nul parce que tu ne paies que quand tu t'en sers.
C'est le bon choix si tu veux un agent qui « vit quelque part » sans être sur ton portable. La première requête après une longue inactivité met ~300 ms à réveiller ; les suivantes vont à la vitesse d'un conteneur.
vercel — Vercel Sandbox (v0.14.0)
Le backend le plus récent, ajouté en v0.14.0. Même modèle de conteneur serverless que Modal, mais sur l'infrastructure de Vercel. Si tu as déjà Vercel comme cible de déploiement, c'est le choix qui frotte le moins pour mettre aussi la sandbox d'agent chez le même provider.
À privilégier : les workflows JS lourds où tu veux que l'environnement de l'agent reflète ton environnement de déploiement prod.
Comment changer
hermes config set sandbox docker
# ou : local, ssh, singularity, modal, daytona, vercel
Pour les backends qui ont besoin de credentials (ssh / modal / daytona / vercel), hermes setup te les demande ; ou tu les mets via hermes config set directement, comme dans la doc.
Tu peux aussi outrepasser par session au besoin : hermes --sandbox modal pour un run isolé qui demande un GPU, en revenant à ta sandbox par défaut ensuite.
Et si pas de sandbox du tout ?
Tu peux désactiver complètement le sandboxing (backend local), mais Hermes pose dessus un workflow d'approbation de commandes : les commandes dangereuses comme rm -rf, curl | sh, ou tout ce qui touche /etc demandent une approbation explicite avant de tourner. v0.14.0 a durci cette couche avec trois fermetures de bypass de commandes dangereuses et un blocage de brute-force sudo (#23736, #26829). Donc même local, ce n'est pas « rien » — c'est « isolation plus légère, mais de vrais prompts ». Voir l'article sur le modèle de sécurité pour le détail couche par couche.
La recommandation honnête
Pour la plupart des gens, la plupart du temps : Docker.
Si tu veux que l'agent vive sur un serveur qui n'est pas ton portable : Daytona (l'hibernation au repos est vraiment magique, et les comptes sont bons).
Si tu as des workloads GPU ou que l'agent fait du vrai calcul : Modal.
Si tu es chercheur sur un cluster : Singularity.
Local uniquement si tu comprends le compromis. SSH uniquement quand le travail appartient au distant. Vercel si tu es déjà sur Vercel.