Hermes Agent : où Hermes exécute vraiment avec Docker et SSH

Le point important ici est simple :

quand Hermes lance une commande, elle part où, exactement ?

Sur ta machine. Dans un conteneur. Ou sur une autre machine.

Et ce détail change beaucoup plus que le confort de setup.

Il change les fichiers visibles.
Il change les permissions réelles.
Il change ce que l’agent peut casser.
Il change l’isolation.
Et il change la surface d’exécution d’Hermes.

Ce que tu auras à la fin
Une vision claire de ce que change un backend d’exécution, de la différence entre local, Docker et SSH, des cas où chacun a du sens, et des snippets de config qui comptent vraiment au début.

Ce que change vraiment un backend d’exécution

Un backend d’exécution, ce n’est pas une case de config pour faire joli.

C’est la réponse à cette question simple :

quand Hermes utilise le terminal, dans quel environnement la commande tourne-t-elle réellement ?

En local, la commande tourne directement avec les droits et la visibilité de ta session.

En Docker, Hermes reste sur ton hôte, mais les commandes partent dans un conteneur Docker.

En SSH, Hermes reste chez toi, mais les commandes partent sur une machine distante.

Donc le backend ne change pas juste la plomberie. Il change :

ce que l’agent peut voir
ce qu’il peut modifier
ce qu’il peut casser
les permissions réellement en jeu
la quantité de confiance que tu dois lui donner

Dit autrement : parler à Hermes ne suffit pas à savoir où il pose vraiment les mains.

Pourquoi ce sujet compte

Le sujet n’est pas “Docker contre SSH” au sens folklore admin.

Le sujet, c’est plus basique : où tourne l’action réelle.

Tant que tu réponds mal à cette question, tu peux croire qu’un backend protège tout, ou qu’un agent “agit comme en local” alors qu’il n’est déjà plus du tout dans le même terrain.

Local, Docker et SSH en clair

Local

Le backend local est le plus simple.

Hermes exécute les commandes sur ta machine, directement, sans isolation supplémentaire.

C’est pratique.
C’est rapide.
C’est très bien pour démarrer.

Mais c’est aussi le backend où tes erreurs et les siennes vivent au même endroit.

Le local n’est pas un mauvais choix.

C’est un choix qui suppose un contexte bien maîtrisé.

Docker

Le backend Docker change la scène.

Hermes tourne toujours sur ton hôte, mais les commandes terminal partent dans un conteneur Docker.

Ce n’est pas “Hermes disparaît dans Docker”.

C’est plutôt : Hermes pilote, Docker exécute.

Le gain concret, c’est l’isolation.

Tu sépares mieux le système qui héberge l’agent du système dans lequel les commandes tournent. Tu peux aussi viser un environnement plus reproductible, avec une image connue, un espace de travail borné, et des limites CPU, RAM et disque.

Mais Docker n’est pas une sécurité magique.

Si tu montes trop de volumes host, si tu forwardes des variables sensibles, ou si tu traites le conteneur comme un coffre-fort absolu, tu recrées tes problèmes autrement.

SSH

Le backend SSH déplace encore plus clairement l’action.

Hermes reste chez toi, mais les commandes sont exécutées sur une machine distante, via SSH.

L’intérêt n’est pas juste de faire du remote.

L’intérêt, c’est que le lieu d’exécution peut devenir le lieu naturel du travail.

Si la tâche vit sur un serveur, un VPS, une machine de build, une box dédiée ou une station plus puissante, alors SSH remet Hermes au bon endroit.

En échange, tu récupères d’autres contraintes :

accès SSH propre
permissions propres
clé propre
arborescence distante propre
habitudes de debug un peu moins confortables

SSH est souvent le bon choix quand tu veux séparer clairement la machine de dialogue de la machine d’action.

Trois cas concrets

Cas 1 — Rester en local quand le contexte est déjà maîtrisé

Tu bosses seul.

Tu utilises Hermes dans le terminal.
Pas de surface d’entrée supplémentaire.
Pas de tâches critiques.
Le repo est connu.
La machine est à toi.
Tu relis ce qu’il fait.

Dans ce cas, rester en local peut être le bon choix.

Tu gagnes la simplicité maximale.
Pas de conteneur à préparer.
Pas de serveur distant à maintenir.
Pas de friction inutile.

Le backend actuel suffit parce que ton contexte est déjà propre et ton périmètre déjà borné.

Ce que tu gagnes :

zéro complexité supplémentaire
itération rapide
débogage simple

Ce qu’il faut surveiller :

ne pas élargir les droits ou les outils sans raison
ne pas oublier qu’en local, Hermes agit chez toi, pour de vrai

Cas 2 — Passer à Docker pour un Hermes plus exposé

Cette fois, Hermes doit toucher des fichiers réels plus souvent, ou tu veux éviter de lui laisser le host sous les doigts dans le même cadre qu’avant.

Là, Docker commence à faire sens.

Le vrai gain n’est pas “c’est moderne”.

Le vrai gain, c’est la séparation entre ton hôte et l’environnement d’exécution des commandes.

Tu peux alors dire, en pratique :

“L’agent tourne ici, mais ce qu’il exécute part là-dedans.”

C’est beaucoup plus sain quand tu ne veux plus confondre machine de pilotage et machine d’action.

Ce que tu gagnes :

meilleure isolation
environnement plus prévisible
meilleure sérénité pour les tâches plus exposées
base plus propre pour un usage régulier

Ce qu’il faut surveiller :

les volumes montés depuis l’hôte
les variables d’environnement forwardées
le faux sentiment de sécurité
la discipline de permissions

Cas 3 — Passer à SSH quand Hermes doit agir ailleurs

Tu veux qu’Hermes travaille sur un serveur distant.

Ou sur une machine plus puissante.
Ou sur un environnement qui héberge déjà les fichiers, les dépendances ou les services concernés.
Ou simplement sur une machine séparée de ton poste principal.

Ici, Docker local n’est pas toujours la meilleure réponse.

Parce que le vrai besoin n’est pas seulement l’isolation.

Le vrai besoin, c’est déplacer le lieu d’exécution.

SSH est fait pour ça.

Tu parles à Hermes depuis ton poste.
Mais Hermes exécute là où le travail doit vivre.

Ce que tu gagnes :

séparation claire entre machine de dialogue et machine d’action
accès à d’autres ressources
bon choix pour les serveurs, VPS et environnements dédiés
meilleure cohérence quand les fichiers ne vivent pas chez toi

Ce qu’il faut surveiller :

qualité de la machine distante
clés SSH et permissions
sudo à distance
chemins réels sur le serveur
tentation de considérer “distant” comme “sans risque”

Les premières configs vraiment utiles

Si tu veux juste comprendre la bascule, commence petit.

Les snippets qui suivent sont des exemples de direction pour visualiser la bascule du backend, pas une config canonique à recopier telle quelle.

Basculer vers Docker

terminal:
  backend: docker
  cwd: "/root"

Si tu veux ajouter un cadre un peu plus propre, voilà un exemple un peu plus structuré :

terminal:
  backend: docker
  cwd: "/root"
  docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
  container_cpu: 1
  container_memory: 5120
  container_disk: 51200
  container_persistent: true
  env_passthrough: []

L’idée n’est pas d’optimiser au millimètre.

L’idée, c’est de rendre visible que tu changes d’environnement d’exécution, pas juste une option d’interface.

Basculer vers SSH

terminal:
  backend: ssh
  cwd: "/home/myuser/project"

Et côté .env, garde surtout la logique générale : exemple minimal à adapter à ta machine et à ta version, pas modèle universel :

TERMINAL_SSH_HOST=my-server.example.com
TERMINAL_SSH_USER=myuser
TERMINAL_SSH_PORT=22
TERMINAL_SSH_KEY=~/.ssh/id_rsa

Tu peux aussi garder en tête que le shell persistant existe, y compris côté SSH, mais ce n’est pas le premier sujet à régler. D’abord, clarifie où tu exécutes. Ensuite seulement, tu raffines le confort.

Le point que beaucoup ratent sur Docker

Il faut distinguer deux choses.

1. Faire tourner Hermes lui-même dans le conteneur officiel

Là, tu exécutes carrément Hermes via l’image Docker officielle. Le stockage principal passe par le volume de données Hermes.

C’est utile pour héberger proprement l’agent ou une installation portable.

2. Utiliser Docker comme terminal backend

Là, Hermes peut très bien vivre ailleurs, mais ses commandes terminal partent dans un conteneur sandboxé.

Ce n’est pas la même brique. Et mélanger les deux mène souvent à de mauvais raisonnements.

“Hermes tourne dans Docker” n’implique pas automatiquement “toutes ses actions terminal sont bien isolées de la façon que j’imagine”.

Le bon réflexe, c’est toujours de demander :

où tourne l’agent ?
et où tournent ses commandes ?

Ce que Docker ajoute vraiment, et ce qu’il n’ajoute pas

Docker ajoute une vraie couche d’isolation.

C’est utile. C’est concret. Et dans Hermes, ce n’est pas juste cosmétique.

Mais il faut rester lucide.

Docker ne remplace pas :

une bonne image de base
un périmètre de montage propre
une politique de secrets propre
une vraie discipline de permissions
un cadrage correct des tâches

Si tu forwardes un token sensible dans le conteneur, le conteneur peut le lire. Si tu montes trop du host, tu réouvres ta surface d’attaque. Si tu laisses croire que “container = sécurité absolue”, tu te racontes une histoire.

Docker est un meilleur garde-fou que le local sur des usages exposés. Pas un bouton “risque annulé”.

Ce que SSH ajoute vraiment, et ce qu’il n’ajoute pas

SSH apporte une séparation très forte du lieu d’exécution.

C’est souvent excellent quand tu veux que l’agent n’agisse pas sur sa propre machine, ou quand la tâche appartient déjà à un serveur.

Mais le distant ne rend pas le système automatiquement propre.

Si le serveur a des permissions trop larges, elles restent trop larges. Si le sudo est mal cadré, il reste mal cadré. Si l’arborescence distante est confuse, Hermes sera perdu au bon endroit au lieu d’être perdu au mauvais.

SSH ne supprime pas les erreurs de cadrage. Il les déplace.

Ce qu’il vaut mieux avoir stabilisé avant

Avant de passer sérieusement à Docker ou SSH, il vaut mieux avoir déjà stabilisé :

le périmètre des tâches confiées à Hermes
les repo ou dossiers où tu le laisses agir
les permissions réellement nécessaires
le niveau de supervision humaine
les outils activés

Si ton usage est encore flou, tu risques surtout d’ajouter une couche de confusion.

Erreurs fréquentes

La première, c’est de passer à Docker juste pour se sentir plus tranquille, sans regarder les volumes ni les secrets.

La deuxième, c’est de choisir SSH pour faire plus pro, alors que toute la tâche vit déjà proprement en local.

La troisième, c’est de croire que le backend règle un problème de discipline.

Le backend améliore le terrain. Il ne remplace pas le pilotage.

La quatrième, c’est d’oublier que Docker et SSH changent aussi le confort de debug. Le mieux isolé n’est pas toujours le plus agréable au quotidien.

Ce que tu ne dois pas faire

Ne passe pas en Docker si tu ne sais pas ce que tu montes depuis l’hôte.

Ne passe pas en SSH sans machine distante vraiment propre et vraiment utile.

Ne traite pas “distant” comme synonyme de “sûr”.

Ne traite pas “conteneur” comme synonyme de “impossible à casser”.

Ne choisis pas ton backend comme un gadget.

Choisis-le en fonction de l’endroit réel où l’action doit se passer.

Le vrai repère pour choisir

Si ton contexte est simple, maîtrisé, personnel, et que tu surveilles de près, local reste souvent le choix le plus cohérent.

Si tu veux garder Hermes sur ton hôte mais mieux borner l’environnement où partent ses commandes, Docker devient souvent le bon cran suivant.

Si le travail doit vivre ailleurs que sur ta machine, ou si tu veux séparer clairement la machine de dialogue de la machine d’action, SSH devient souvent le choix le plus logique.

Le sujet n’est donc pas “quel backend est le plus cool”.

Le sujet est :

où veux-tu vraiment qu’Hermes exécute ses commandes, avec quel niveau d’isolation, pour quel usage réel ?

Suite logique

Tu sais maintenant où Hermes agit réellement selon le backend, et pourquoi parler à l’agent ne suffit pas à savoir où l’action se passe.

Si ton sujet devient ensuite comment exposer Hermes comme brique pour d’autres clients ou d’autres interfaces, va au tuto dédié : Hermes Agent : quand Hermes devient une brique d’intégration.