Elke Hermes Agent-installatie heeft een sandbox-setting die bepaalt waar shell-commando's echt uitgevoerd worden. De keuze heeft consequenties: hij bepaalt hoe groot de blast radius is van een slecht commando, hoe snel de agent voelt en hoeveel je per actief uur betaalt.
Hermes levert zeven backends. De README somt ze op: local, docker, ssh, singularity, modal, daytona, vercel. v0.14.0 voegde Vercel Sandbox toe om het rijtje compleet te maken. Hier de beslis-boom.
De 7 backends, in één tabel
| Backend | Isolatie | Latency | Kosten | Persistentie | Geschikt voor |
|---|---|---|---|---|---|
| local | Geen | <10 ms | Gratis | Ja (je schijf) | Solo-dev op een wegwerp-VM |
| Docker | Container | ~50 ms | Gratis | Per container | Default voor elke dev-box |
| SSH | Wat de remote ook heeft | Remote-latency | Remote-kosten | Ja | Draaien op iemand anders zijn box |
| Singularity | HPC-container | ~100 ms | Gratis | Per container | HPC-clusters, scientific compute |
| Modal | Serverless container | ~200 ms cold | Per actieve seconde | Snapshot-baar | Bursty compute, GPU-werk |
| Daytona | Serverless workspace | ~300 ms cold | Per actieve seconde | Hiberneert als idle | Langlevende agent-envs, near-zero idle-kosten |
| Vercel Sandbox | Serverless container | ~200 ms cold | Per actieve seconde | Ephemeraal | Web-tooling, JS-zware flows |
local en docker zijn gratis en op je eigen machine. De andere vijf draaien elders — betaald in latency, betaald in dollars, maar je krijgt er ook iets voor terug.
Wanneer welke kiezen
local — "ik vertrouw deze agent op deze machine"
De agent draait commando's direct op je filesystem met de rechten van jouw user. Nul isolatie. Besluit de agent rm -rf ~/code, dan gebeurt dat. Landt er een prompt injection in tool-output, dan draait het ingeworpen commando.
Wanneer dit de juiste keuze is: je hackt op een wegwerp-VM, de agent doet dingen die je zelf met dezelfde blast radius zou doen, en zero latency telt zwaarder dan de veiligheidsmarge.
Wanneer dit fout is: vrijwel elke andere keer.
docker — de juiste default
Een container op je machine, geïsoleerd door Linux-namespaces. De filesystem-view van de agent is die van de container; je echte /home blijft onzichtbaar tenzij je hem mount.
hermes config set sandbox docker en hermes setup trekken de image binnen en configureren hem. Daarna gaat elke shell-tool-call door de container.
Dit is de juiste default voor ~80% van de gebruikers. De latency-overhead (~50 ms per commando) is onzichtbaar in chat. De isolatie is sterk genoeg dat een agent die rm -rf / doet alleen de container-view aanvalt, en de container is wegwerp. Wil je debuggen, dan docker exec je naar binnen.
ssh — "de agent woont op een andere box"
De shell-tools van de agent draaien over SSH op een remote host. Je lokale Hermes-proces is de client; de remote is waar het werk gebeurt.
Dit is de juiste keuze als de agent infrastructuurwerk doet dat thuishoort op de remote — deployen naar een server, productie-logs debuggen, migraties draaien. Je hebt geen lokale sandbox nodig, want de host is de sandbox.
De remote moet een host zijn waar je akkoord bent dat de agent shell-toegang heeft. Behandel de SSH-credentials als prod-credentials, want dat zijn ze.
singularity — HPC-clusters
Singularity (nu Apptainer) is de container-runtime die HPC-clusters daadwerkelijk gebruiken, omdat Docker root op de host vereist en HPC-omgevingen die niet geven. Draai je Hermes op een onderzoekscluster — SLURM-gepland, geen Docker, veel GPU's — dan is dit de juiste pick.
Herken je de woorden "HPC" of "Singularity" niet, sla deze dan over.
modal — bursty compute, vooral GPU's
Modal is een serverless container-platform. Hermes spint per commando (of per sessie, met hergebruik) een Modal-container op, draait het commando, en breekt hem af. Je betaalt per seconde actieve compute. GPU-tiers beschikbaar.
Wanneer dit Docker verslaat: de agent heeft GPU's nodig, of compute-resources voorbij je lokale box. Wanneer Modal andere serverless verslaat: de cold start is ~200 ms — acceptabel voor chat-tempo tool-use, en het snapshotten is goed genoeg dat mid-session-state redelijk overleeft.
daytona — langlevend, near-zero-idle
De killer-feature van Daytona is hibernation. De omgeving van je agent gaat slapen als er niets gebeurt en wordt op aanvraag in een paar honderd ms wakker. Je betaalt voor actieve seconden, niet voor idle.
Praktisch effect: je kunt een "mijn Hermes"-omgeving hebben met je dotfiles, je skills, je halfafgemaakte werk, die maanden leeft tegen bijna nul kosten omdat je alleen betaalt wanneer je gebruikt.
Dit is de juiste pick als je wilt dat een agent "ergens woont" zonder dat hij op je laptop draait. De eerste request na lange idle kost ~300 ms om wakker te worden; daarna container-snel.
vercel — Vercel Sandbox (v0.14.0)
De nieuwste backend, toegevoegd in v0.14.0. Zelfde serverless-container-model als Modal, maar op de infrastructuur van Vercel. Heb je Vercel al als deploy-target, dan is dit de keuze met de minste wrijving om agent-sandboxing op dezelfde provider te krijgen.
Geschikt voor: JS-zware flows waar je wilt dat de omgeving van de agent je productie-deploy-omgeving spiegelt.
Hoe je wisselt
hermes config set sandbox docker
# of: local, ssh, singularity, modal, daytona, vercel
Voor backends die credentials nodig hebben (ssh / modal / daytona / vercel) vraagt hermes setup je ernaar; of zet ze direct via hermes config set zoals de docs aangeven.
Je kunt het ook per sessie overschrijven als dat moet: hermes --sandbox modal voor een eenmalige run die GPU vraagt, daarna terug naar je default-sandbox.
En helemaal geen sandbox?
Je kunt sandboxing helemaal uitzetten (local-backend), maar Hermes legt daar een command-approval-workflow overheen: gevaarlijke commando's zoals rm -rf, curl | sh of alles wat aan /etc zit, vragen om expliciete approval vóór ze draaien. v0.14.0 heeft die laag harder gemaakt met drie dangerous-command bypass-closures en een sudo brute-force-block (#23736, #26829). Dus zelfs local is niet "niets" — het is "lichtere isolatie maar echte prompts". Zie het security-model-stuk voor de laag-voor-laag-uitsplitsing.
De werkelijke aanbeveling
Voor de meeste mensen, de meeste tijd: Docker.
Wil je dat de agent op een server woont die niet je laptop is: Daytona (de hibernate-when-idle-eigenschap is echt magisch en de kosten-rekensom klopt).
Heb je GPU-workloads of doet de agent echt compute: Modal.
Ben je een onderzoeker op een cluster: Singularity.
local alleen als je de tradeoff begrijpt. SSH alleen wanneer het werk thuishoort op de remote. Vercel als je toch al op Vercel zit.