Backend Docker Hermes : comprendre ce qui persiste pendant une session

Tu lances Hermes avec un backend Docker. Tu fais un pip install dans le terminal. Tu crées un fichier. Tu changes de répertoire. Et puis tu te demandes : est-ce que tout ça va tenir au prochain appel ?

La réponse est simple, mais elle a un piège. Le backend Docker d’Hermes utilise un seul conteneur longue durée pour tout le processus. Pas un conteneur frais par commande. Pas une VM jetable. Un conteneur qui vit, respire et accumule pendant toute ta session.

Ça change tout dans la façon de travailler. Et ça crée aussi des attentes qu’il faut cadrer.

Communauté Kavyro

Le vrai sujet n’est pas d’ajouter un agent de plus.

Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.

Cas concrets
Arbitrages utiles
Questions réelles
Accès gratuit

Rejoindre la communauté

Tu arrives avec ton sujet, tu repars avec plus de clarté.

Le modèle : un conteneur unique pour tout le processus

Quand tu actives le backend Docker dans ta config Hermes, voici ce qui se passe sous le capot.

Au premier appel terminal, Hermes lance un conteneur avec docker run -d ... sleep 2h. Un seul. Il ne le détruit pas entre deux commandes. Chaque appel suivant — terminal, read_file, patch, execute_code — passe par docker exec dans ce même conteneur.

Ça veut dire que le conteneur se comporte comme une VM persistante, pas comme une série de bacs à sable indépendants. Si tu fais un pip install requests une fois, le paquet est installé pour le reste de la session. Si tu fais un cd /workspace/mon-projet, les appels suivants voient ce répertoire.

C’est un choix d’architecture délibéré. Hermes n’est pas un orchestrateur de conteneurs éphémères. C’est un agent qui travaille dans un environnement stable le temps de ta session.

Ce qui persiste concrètement

Voici ce qui survit d’un appel à l’autre, tant que le processus Hermes tourne :

• Les paquets installés. pip install, apt-get, npm install : tout reste en place.
• Les fichiers créés ou modifiés. Tout ce que tu écris dans /workspace ou ailleurs dans le conteneur persiste.
• Les variables d’environnement. Un export posé dans un appel terminal est visible dans les appels suivants.
• Le répertoire de travail. Le cwd évolue et se maintient.
• Les processus lancés en arrière-plan. Un serveur démarré avec background=true continue de tourner.

Même les sous-agents lancés via delegate_task partagent ce conteneur. Et les commandes /new ou /reset ne recréent pas un conteneur frais : elles réinitialisent le contexte de conversation, pas l’environnement d’exécution.

Ce qui persiste	Périmètre	Condition
Paquets installés	Toute la session	Processus Hermes actif
Fichiers dans /workspace	Toute la session	Processus Hermes actif
Variables d’environnement	Toute la session	Processus Hermes actif
Répertoire de travail (cwd)	Toute la session	Processus Hermes actif
Processus background	Toute la session	Processus Hermes actif
/workspace et /root entre redémarrages	Multi-session	container_persistent: true

Ne pas supposer : ce qui ne persiste PAS

Le piège classique, c’est de confondre persistance de session et persistance entre redémarrages.

Par défaut, quand le processus Hermes s’arrête, le conteneur est stoppé et supprimé. Tout ce qui était dedans disparaît. Tes paquets installés, tes fichiers temporaires, tes variables d’environnement : tout est perdu.

Il y a bien un flag container_persistent dans la configuration. Si tu le passes à true, les volumes /workspace et /root survivent aux redémarrages d’Hermes. Mais c’est une option explicite, pas le comportement par défaut pour le cycle de vie du conteneur lui-même.

Autre point : la persistance ne couvre que ce qui est dans le conteneur. Si tu écris un fichier sur ta machine hôte via un volume monté, ce fichier survit quoi qu’il arrive. Mais ce n’est pas le backend Docker qui le gère, c’est Docker lui-même.

Test : vérifie par toi-même en 3 commandes

Le moyen le plus fiable de comprendre le comportement, c’est de le tester. Voici un test simple que tu peux faire en deux minutes.

Ouvre une session Hermes avec le backend Docker activé. Dans le terminal, tape :

echo "test-persistence" > /workspace/demo.txt
cat /workspace/demo.txt

Puis, dans un deuxième appel terminal, relance :

cat /workspace/demo.txt

Le fichier est toujours là. Le conteneur n’a pas été recréé entre les deux appels.

Maintenant, arrête Hermes, relance-le, et refais le cat. Si container_persistent n’est pas activé, le fichier a disparu. Si le flag est à true, il est encore là.

Ce test en trois étapes te donne une intuition plus fiable que n’importe quelle explication théorique. Tu vois exactement où passe la frontière entre session et redémarrage.

Garde-fou : les bonnes pratiques

Quand tu utilises le backend Docker pour du travail réel, quelques réflexes évitent les mauvaises surprises.

Ne compte pas sur la persistance entre redémarrages sans l’avoir configurée. Si ton workflow dépend de fichiers ou de paquets qui doivent survivre à un arrêt d’Hermes, active container_persistent: true et vérifie que ça fonctionne avant de t’engager.

Traite le conteneur comme un environnement de session, pas comme un stockage. C’est un espace de travail vivant le temps d’une session, pas un backup. Si tu produis un fichier important, copie-le ou commit-le ailleurs avant d’éteindre.

Teste sur un environnement non critique d’abord. La configuration Docker d’Hermes est puissante mais elle a des subtilités. Avant de l’utiliser sur un projet qui compte, valide ton setup sur un projet jetable. Tu verras tout de suite si container_persistent fait ce que tu attends, si les volumes sont bien montés, et si les droits d’accès sont corrects.

Documente tes dépendances. Si ton workflow installe des paquets pendant la session, garde une trace de ce qui a été installé. Un pip freeze > requirements.txt dans /workspace prend dix secondes et t’évite de reconstruire l’environnement de tête au prochain redémarrage.

Le backend Docker d’Hermes est un outil précis. Il ne fait pas semblant d’être une solution de sauvegarde. Il te donne un bac à sable cohérent pour la durée de ta session, avec une option explicite pour étendre cette durée si tu en as besoin. La différence entre les deux est une ligne de config. Mais la comprendre, c’est ce qui t’évite de perdre du travail.

Si tu veux approfondir le diagnostic et la configuration d’Hermes, j’ai deux ressources qui complètent ce sujet : la page debug et dépannage Hermes Agent couvre les pannes courantes, et la formation Hermes Agent t’accompagne pas à pas pour maîtriser l’outil. Tu peux aussi faire une demande d’accès directement sur la page de la formation.