The hermes agent backend is the terminal backend: the place where your agent's shell commands actually run. Per the Hermes docs, there are seven of them: local, docker, ssh, modal, daytona, vercel_sandbox and singularity. Local is the default.
📺 Watch: Hermes Jarvis is mind blowing...
🔥 Get the Agent OS as a free bonus: AI Profit Boardroom members get the full Agent OS zip, prompt libraries, daily tutorials and weekly live coaching calls. → Get inside
Pick the wrong one and your agent either can't do much or can do far too much to your own machine. Below you'll get what each backend is, a side-by-side comparison, how to set one up, and which one I'd pick. Everything technical comes from the Hermes docs.
Hermes Agent is the open-source, self-hosted AI agent built by Nous Research, MIT licensed, with persistent memory and self-written skills. I run it daily inside my own Agentic Operating System, with a separate profile per model.
What a Hermes agent backend does
When Hermes runs a command, it has to run somewhere. The terminal backend decides where: your laptop, a Docker container, a remote server over SSH, or a cloud sandbox from Modal, Daytona or Vercel. It also covers Singularity/Apptainer containers for HPC clusters.
You set it with one line in ~/.hermes/config.yaml under terminal, using the backend key. Other settings in the same block include cwd (the working directory for gateway and cron), timeout (180 seconds per command by default) and env_passthrough for environment variables you want forwarded into sandboxes.
If you want help choosing a setup for your business, the AI Profit Boardroom ($69/mo) has Hermes courses, my Agent OS zip, daily updates and four coaching calls a week.
The seven backends compared
This table combines the backend overview and the security comparison from the Hermes docs:
| Backend | Where commands run | Isolation | Dangerous command check | Best for |
|---|---|---|---|---|
| local | Your machine directly | None | Yes | Development, personal use |
| docker | One persistent Docker container | Full (namespaces, cap-drop) | Skipped (container is the boundary) | Safe sandboxing, CI/CD, production gateway |
| ssh | Remote server via SSH | Network boundary | Yes | Remote dev, powerful hardware |
| modal | Modal cloud sandbox | Full (cloud VM) | Skipped | Ephemeral cloud compute, evals |
| daytona | Daytona workspace | Full (cloud container) | Skipped | Managed cloud dev environments |
| vercel_sandbox | Vercel Sandbox | Full (cloud microVM) | Skipped | Cloud execution with snapshot-backed persistence |
| singularity | Singularity/Apptainer container | Namespaces (--containall) | Skipped | HPC clusters, shared machines |
Notice the dangerous command check. On local and ssh, Hermes still checks risky commands. On the container and cloud backends, it skips that check because the sandbox itself is the boundary.
📺 Watch: Hermes3D Is INSANE: AI Agents Now Have a 3D Office
Each backend in plain English
Local
The default. Commands run directly on your machine with no isolation and no setup. By default, local tool subprocesses keep your real HOME, so tools like git, ssh, gh, npm, Claude Code and Codex find the credentials they already use. It's fast and easy, but the agent has the same reach you do.
Docker
Per the docs, Hermes starts one long-lived container on first use and routes every terminal, file and execute_code call into it. Installed packages, files in /workspace and background processes carry over between calls, sessions and subagents. It runs with security hardening: all Linux capabilities dropped, no privilege escalation, and PID limits (256 processes).
Set container_persistent to false and you get one fresh container per session instead, with nothing carried over. You can also mount host folders with docker_volumes and air-gap the container by setting docker_network to false. One warning from the docs: anything you list in docker_forward_env is visible to code in the container, so treat it as exposed.
SSH
Runs commands on a remote server. The docs call it "recommended for security" because the agent can't modify its own code. You set TERMINAL_SSH_HOST and TERMINAL_SSH_USER in ~/.hermes/.env, plus optional TERMINAL_SSH_PORT (default 22) and TERMINAL_SSH_KEY. A persistent shell is on by default, so the working directory and env vars survive between commands.
Modal
Runs commands in a Modal cloud sandbox, where each task gets an isolated VM. You need MODAL_TOKEN_ID plus MODAL_TOKEN_SECRET, or a ~/.modal.toml file. With persistence on, the filesystem is snapshotted on cleanup and restored next session. That saves files, not running processes.
Daytona
Runs commands in a Daytona managed workspace. It needs DAYTONA_API_KEY. With persistence on, sandboxes are stopped rather than deleted, and resumed next session. Daytona enforces a 10 GiB disk maximum.
Vercel Sandbox
Runs commands in a Vercel cloud microVM. You authenticate with VERCEL_TOKEN, VERCEL_PROJECT_ID and VERCEL_TEAM_ID. The default image is vercel/sandbox/universal:latest. Persistence uses Vercel snapshots for the filesystem only. Leave container_disk at the shared default, because custom disk sizing isn't supported here.
Singularity/Apptainer
Built for HPC clusters and shared machines where Docker isn't available. You need the apptainer or singularity binary on your PATH. Docker image URLs are converted to SIF files and cached automatically.
📺 Watch: Hermes AI Agents Just Went Portable
How to configure your backend
The simplest way is hermes config set. Some examples straight from the docs:
- Singularity: hermes config set terminal.backend singularity, then hermes config set terminal.singularity_image with your image path
- Modal: install the Modal extra, run modal setup, then hermes config set terminal.backend modal
- Vercel: install the vercel extra, then hermes config set terminal.backend vercel_sandbox
- Back to safe defaults: hermes config set terminal.backend local
For container backends you can also set resources: container_cpu (default 1 core), container_memory (default 5120 MB), container_disk (default 51200 MB) and container_persistent (default true).
If commands fail straight away, the docs give a quick checklist:
- Docker: run docker version to check Docker works
- SSH: both TERMINAL_SSH_HOST and TERMINAL_SSH_USER must be set
- Modal: needs MODAL_TOKEN_ID or ~/.modal.toml; run hermes doctor to check
- Daytona: needs DAYTONA_API_KEY
- Singularity: needs apptainer or singularity on your PATH
When in doubt, the docs say to set the backend back to local and confirm commands run there first. And if commands hang right after working in your own terminal, your shell startup file is the first suspect.
Which hermes agent backend should you pick?
- Just starting out on your own machine: local. The docs call it the safest default when getting started, meaning fewest moving parts.
- Running a bot other people can message: docker. The security table lists it as best for a production gateway.
- Keeping the agent away from its own code: ssh to a separate server.
- Throwaway cloud compute or evals: modal.
- A persistent cloud dev workspace: daytona or vercel_sandbox.
- An HPC cluster: singularity.
Your backend also decides which tools behave safely, so it's worth pairing this with my best Hermes Agent tools list. If you want your agent and its sandbox on a server that never sleeps, see my pick of the best Hermes VPS options.
Want a second pair of eyes on your setup? Book a free AI strategy session.
Connecting the Desktop app to a remote backend
"Backend" means something slightly different in the desktop app. By default, the Hermes Desktop app starts and manages its own local backend. Per the install docs, there's no separate remote-only Desktop download. To use Desktop with Hermes on another machine, you install the normal package and connect from Settings, then Gateways.
The Connection mode there offers:
- Remote gateway: enter the URL of a hermes serve backend you run yourself, and sign in.
- Hermes Cloud: sign in once and pick from the agents on your account, with no URL to paste.
The registered gateways list can hold your local runtime, remote gateways, Hermes Cloud instances and SSH hosts together. Per the docs, the remote backend is a running hermes serve process, and the app doesn't start it for you. For anything reachable beyond your own machine, the docs prefer OAuth through Nous Portal for sign-in.
This is how I connect my desktop to agents running elsewhere. The Agent OS guide shows how that fits into the wider system, and I pick models for each machine using Goldie Bench.
FAQ
What is the default Hermes Agent backend?
Local is the default. Per the Hermes docs, commands run directly on your machine with no isolation and no special setup.
Which Hermes backend is the most secure?
The container and cloud backends (docker, modal, daytona, vercel_sandbox, singularity) give full or namespace isolation. The docs also recommend ssh for security because the agent can't modify its own code. Local has no isolation.
How do I change the terminal backend?
Set terminal.backend in ~/.hermes/config.yaml, or run hermes config set terminal.backend followed by the backend name. Add any credentials that backend needs, like DAYTONA_API_KEY or the SSH host and user.
Do background processes survive in cloud sandboxes?
Not across cleanup. Per the docs, persistence on Modal and Vercel saves filesystem state, not live processes. Docker's shared container does keep background processes running between calls.
Get the right hermes agent backend in place and everything else gets easier. For step-by-step Hermes training, join the AI Profit Boardroom, or book a free AI strategy session to map out your setup.
