Jede Hermes-Agent-Installation hat eine Sandbox-Einstellung, die festlegt, wo Shell-Befehle tatsächlich ausgeführt werden. Die Wahl ist nicht egal: Sie bestimmt, wie groß der Blast-Radius eines schlechten Befehls ist, wie schnell sich der Agent anfühlt und wie viel du pro aktive Stunde zahlst.
Hermes bringt sieben Backends mit. Die README zählt sie auf: local, docker, ssh, singularity, modal, daytona, vercel. v0.14.0 hat Vercel Sandbox dazugepackt und damit das Set komplettiert. Hier ist der Entscheidungsbaum.
Die 7 Backends, in einer Tabelle
| Backend | Isolation | Latenz | Kosten | Persistenz | Wofür gedacht |
|---|---|---|---|---|---|
| local | Keine | <10 ms | Gratis | Ja (deine Platte) | Einzeldev auf einer Wegwerf-VM |
| Docker | Container | ~50 ms | Gratis | Pro Container | Default für jede Dev-Box |
| SSH | Was die Remote-Box hat | Remote-Latenz | Remote-Kosten | Ja | Agent läuft auf einer fremden Box |
| Singularity | HPC-Container | ~100 ms | Gratis | Pro Container | HPC-Cluster, wissenschaftliches Rechnen |
| Modal | Serverless-Container | ~200 ms kalt | Pay per aktiver Sekunde | Snapshot-fähig | Burst-Compute, GPU-Arbeit |
| Daytona | Serverless-Workspace | ~300 ms kalt | Pay per aktiver Sekunde | Schläft bei Idle | Langlebige Agent-Umgebungen, nahezu null Idle-Kosten |
| Vercel Sandbox | Serverless-Container | ~200 ms kalt | Pay per aktiver Sekunde | Ephemer | Web-Tooling, JS-lastige Workflows |
local und docker sind gratis und laufen auf deiner Maschine. Die anderen fünf laufen woanders — bezahlt in Latenz, bezahlt in Geld, dafür kriegst du was zurück.
Wann du was nimmst
local — „Ich vertraue diesem Agenten auf dieser Maschine"
Der Agent führt Befehle direkt auf deinem Filesystem mit deinen Benutzerrechten aus. Null Isolation. Wenn der Agent rm -rf ~/code beschließt, dann passiert das. Wenn eine Prompt Injection in einem Tool-Output landet, wird der eingeschleuste Befehl ausgeführt.
Wann das die richtige Wahl ist: du bastelst auf einer Wegwerf-VM, der Agent macht Sachen, die du eh mit demselben Blast-Radius selber machen würdest, und die Latenz auf null zählt für dich mehr als die Sicherheitsmarge.
Wann das die falsche Wahl ist: ziemlich jede andere Zeit.
docker — der richtige Default
Ein Container auf deiner Maschine, isoliert über Linux-Namespaces. Die Filesystem-Sicht des Agents ist die des Containers; dein echtes /home ist nicht zu sehen, solange du es nicht mountest.
hermes config set sandbox docker und hermes setup ziehen und konfigurieren das Image. Danach geht jeder Shell-Tool-Aufruf durch den Container.
Das ist für ~80 % der Nutzer der richtige Default. Der Latenz-Overhead (~50 ms pro Befehl) ist im Chat unsichtbar. Die Isolation ist stark genug, dass ein rm -rf / nur die Container-Sicht plattmacht, und der Container ist Einweg. Wenn du debuggen musst, kommst du mit docker exec rein.
ssh — „der Agent wohnt auf einer anderen Box"
Die Shell-Tools des Agents laufen via SSH auf einem Remote-Host. Dein lokaler Hermes-Prozess ist der Client; die Arbeit passiert remote.
Das passt, wenn die Arbeit des Agents dort hingehört — Deploys auf einen Server, Debuggen von Produktionslogs, Migrationen fahren. Eine lokale Sandbox brauchst du nicht, weil der Host die Sandbox ist.
Der Remote muss ein Host sein, bei dem du dem Agenten Shell-Zugriff geben magst. Behandle die SSH-Credentials wie Prod-Credentials — denn das sind sie.
singularity — HPC-Cluster
Singularity (heute Apptainer) ist die Container-Runtime, die HPC-Cluster wirklich nutzen, weil Docker auf dem Host Root braucht und HPC-Umgebungen das nicht hergeben. Wenn du Hermes auf einem Forschungs-Cluster fährst — SLURM-geplant, kein Docker, viele GPUs — passt das.
Wenn dir die Begriffe „HPC" oder „Singularity" nichts sagen, überspring den Punkt.
modal — Burst-Compute, vor allem GPUs
Modal ist eine Serverless-Container-Plattform. Hermes fährt pro Befehl (oder pro Session, mit Reuse) einen Modal-Container hoch, führt den Befehl aus, fährt ihn wieder runter. Du zahlst pro aktive Compute-Sekunde. GPU-Tarife gibt's.
Wann das Docker schlägt: Der Agent braucht GPUs oder Compute-Ressourcen, die deine lokale Box nicht hat. Wann das andere Serverless schlägt: Der Kaltstart liegt bei ~200 ms, was für Chat-Tempo-Tool-Use okay ist, und das Snapshotting ist gut genug, dass Zwischenstände einigermaßen überleben.
daytona — langlebig, nahezu null im Idle
Daytonas Killer-Feature ist die Hibernation. Die Agent-Umgebung schläft ein, wenn nichts passiert, und wacht in ein paar hundert ms wieder auf. Du zahlst aktive Sekunden, nicht Idle-Sekunden.
Praktischer Effekt: Du kannst eine „mein Hermes"-Umgebung mit deinen Dotfiles, deinen Skills, deinen halbfertigen Sachen für Monate zu nahezu null Kosten leben lassen, weil du nur zahlst, wenn du sie auch nutzt.
Das ist die Wahl, wenn du einen Agenten willst, der „irgendwo lebt", aber nicht auf deinem Laptop. Die erste Anfrage nach einem langen Idle braucht ~300 ms zum Aufwachen; die folgenden gehen mit Container-Tempo.
vercel — Vercel Sandbox (v0.14.0)
Das jüngste Backend, in v0.14.0 dazugekommen. Gleiches Serverless-Container-Modell wie Modal, nur auf Vercels Infrastruktur. Wenn du Vercel schon als Deployment-Ziel hast, ist das die reibungsärmste Wahl, um die Agent-Sandbox beim selben Provider zu halten.
Passt am besten zu JS-lastigen Workflows, in denen die Agent-Umgebung deine Produktions-Deploy-Umgebung spiegeln soll.
Wie du wechselst
hermes config set sandbox docker
# oder: local, ssh, singularity, modal, daytona, vercel
Für Backends, die Credentials brauchen (ssh / modal / daytona / vercel), fragt hermes setup danach; oder du setzt sie laut Doku direkt via hermes config set.
Pro Session lässt sich das auch überstimmen: hermes --sandbox modal für einen einzelnen Lauf, der GPU braucht, danach wieder zurück zur Default-Sandbox.
Was, wenn überhaupt keine Sandbox?
Du kannst Sandboxing komplett deaktivieren (Backend local), aber Hermes packt darüber einen Command-Approval-Workflow: gefährliche Befehle wie rm -rf, curl | sh oder alles, was /etc anfasst, lösen vor der Ausführung eine explizite Genehmigung aus. v0.14.0 hat diese Schicht gehärtet — mit drei geschlossenen Bypass-Routen für gefährliche Befehle und einer Sudo-Bruteforce-Sperre (#23736, #26829). Selbst local ist also nicht „nichts" — es ist „leichtere Isolation, aber echte Prompts". Eine schichtweise Aufschlüsselung findest du im Beitrag zum Security-Model.
Die ehrliche Empfehlung
Für die meisten, in den meisten Fällen: Docker.
Wenn der Agent auf einem Server wohnen soll, der nicht dein Laptop ist: Daytona (das Schlafen bei Idle ist echt magisch und die Mathematik geht auf).
GPU-Workloads oder echter Compute-Bedarf: Modal.
Forscher:in auf einem Cluster: Singularity.
Local nur, wenn dir die Trade-offs klar sind. SSH nur, wenn die Arbeit dort hingehört. Vercel, wenn du sowieso schon auf Vercel bist.