Every Hermes Agent install has a sandbox setting that decides where shell commands actually execute. The choice is consequential: it determines what blast radius a bad command has, how fast the agent feels, and how much you pay per active hour.
Hermes ships seven backends. The README enumerates them: local, docker, ssh, singularity, modal, daytona, vercel. v0.14.0 added Vercel Sandbox to round out the lineup. Here is the decision tree.
The 7 backends, in one table
| Backend | Isolation | Latency | Cost | Persistence | Best for |
|---|---|---|---|---|---|
| local | None | <10 ms | Free | Yes (your disk) | Solo dev on a throwaway VM |
| Docker | Container | ~50 ms | Free | Per-container | Default for any dev box |
| SSH | Whatever the remote is | Remote latency | Remote cost | Yes | Running on someone else's box |
| Singularity | HPC container | ~100 ms | Free | Per-container | HPC clusters, scientific compute |
| Modal | Serverless container | ~200 ms cold | Pay per second active | Snapshot-able | Bursty compute, GPU work |
| Daytona | Serverless workspace | ~300 ms cold | Pay-per-second active | Hibernates when idle | Long-lived agent envs, near-zero idle cost |
| Vercel Sandbox | Serverless container | ~200 ms cold | Pay per second active | Ephemeral | Web tooling, JS-heavy workflows |
local and docker are free and on your machine. The other five run elsewhere — paid in latency, paid in dollars, but bought you something in exchange.
When to pick each
local — "I trust this agent on this machine"
The agent runs commands directly on your filesystem with your user permissions. Zero isolation. If the agent decides to rm -rf ~/code, it does. If a prompt injection lands in tool output, the injected command runs.
When this is the right call: you're hacking on a throwaway VM, the agent is doing things you'd do yourself with the same blast radius, and the latency-to-zero matters more than the safety margin.
When this is the wrong call: pretty much any other time.
docker — the right default
A container on your machine, isolated by Linux namespaces. The agent's filesystem view is the container's view; your real /home is hidden unless you mount it.
hermes config set sandbox docker and hermes setup will pull and configure the image. After that every shell tool call goes through the container.
This is the right default for ~80% of users. The latency overhead (~50 ms per command) is invisible in chat. The isolation is strong enough that an agent running rm -rf / only nukes the container's view, and the container is disposable. You can docker exec in if you need to debug.
ssh — "the agent lives on a different box"
The agent's shell tools execute over SSH on a remote host. Your local Hermes process is the client; the remote is where the work happens.
This is the right pick when the agent is doing infrastructure work that belongs on the remote — deploying to a server, debugging production logs, running migrations. You don't need a local sandbox because the host is the sandbox.
The remote needs to be a host you're OK with the agent having shell access to. Treat the SSH credentials like prod credentials, because they are.
singularity — HPC clusters
Singularity (now Apptainer) is the container runtime HPC clusters actually use, because Docker requires root on the host and HPC environments don't. If you're running Hermes on a research cluster — SLURM-scheduled, no Docker, lots of GPUs — this is the right pick.
If you don't recognize the words "HPC" or "Singularity," skip this one.
modal — bursty compute, especially GPUs
Modal is a serverless container platform. Hermes spins up a Modal container per command (or per session, with reuse), runs the command, and tears it down. You pay per second of active compute. GPU tiers are available.
When this beats Docker: the agent needs GPUs, or compute resources beyond your local box. When Modal beats other serverless: the cold start is ~200 ms, which is acceptable for chat-paced tool use, and the snapshotting is good enough that mid-session state survives reasonably well.
daytona — long-lived, near-zero-idle
Daytona's killer feature is hibernation. Your agent's environment goes to sleep when nothing's happening and wakes on demand in a few hundred ms. You pay for active seconds, not idle seconds.
Practical effect: you can have a "my Hermes" environment with your dotfiles, your skills, your in-progress work, that lives for months at near-zero cost because you're only paying when you're using it.
This is the right pick if you want an agent that "lives somewhere" without being on your laptop. The first request after a long idle takes ~300 ms to wake; subsequent requests are container-fast.
vercel — Vercel Sandbox (v0.14.0)
The newest backend, added in v0.14.0. Same serverless-container model as Modal, but on Vercel's infrastructure. If you already have Vercel as a deployment target, this is the lowest-friction choice for getting agent sandboxing on the same provider.
Best for: JS-heavy workflows where you want the agent's environment to mirror your production deploy environment.
How to switch
hermes config set sandbox docker
# or: local, ssh, singularity, modal, daytona, vercel
For backends that need credentials (ssh / modal / daytona / vercel), hermes setup will prompt you for them; or set them via hermes config set directly per the docs.
You can also override per-session if you need to: hermes --sandbox modal for a single run that needs a GPU, falling back to your default sandbox afterward.
What about no sandbox at all?
You can disable sandboxing entirely (local backend), but Hermes layers a command approval workflow on top: dangerous commands like rm -rf, curl | sh, or anything touching /etc will prompt for explicit approval before running. v0.14.0 hardened this layer with three dangerous-command bypass closures and a sudo brute-force block (#23736, #26829). So even local is not "nothing" — it's "lighter isolation but real prompts." See the security model post for layer-by-layer breakdown.
The actual recommendation
For most people, most of the time: Docker.
If you want the agent to live on a server that isn't your laptop: Daytona (the hibernate-when-idle property is genuinely magical and the cost math works).
If you have GPU workloads or the agent is doing real compute: Modal.
If you're a researcher on a cluster: Singularity.
Local only if you understand the tradeoff. SSH only when the work belongs on the remote. Vercel if you're already on Vercel.