agentos.guide › blog
A Hermes Agent backend is the layer that does the work behind the chat, and the main one is the terminal backend, which decides where the agent's shell commands run.
The official docs list seven terminal backends, which are local, Docker, SSH, Modal, Daytona, Vercel Sandbox and Singularity.
The same word also covers the model provider, the web search provider, the browser provider, the memory provider, and Hermes itself running as a backend for other apps.
Everything here comes from the official Hermes docs and the read-only help output on my own install, which is version 0.21.4.
Here is the full map first, then a seven-step quick-start and where each backend sits in an Agent OS.
Hermes Agent is the free, open-source AI agent from Nous Research, and it is released under the MIT licence.
The docs use the word "backend" for six different layers, which is why the term confuses people.
Here is every layer in one table, with the options the docs list and the command that sets each one.
| Backend type | What it decides | Documented options | How you set it |
|---|---|---|---|
| Terminal | It decides where shell commands run. | The options are local, docker, ssh, modal, daytona, vercel_sandbox and singularity. | You run hermes config set terminal.backend docker. |
| Model | It decides which model does the thinking. | The options include Nous Portal, OpenRouter, Anthropic, OpenAI, Bedrock, Ollama, LM Studio and custom endpoints. | You run hermes model. |
| Web | It decides who serves search and page extraction. | The options include Firecrawl, SearXNG, Brave, DuckDuckGo, Exa, Parallel, Tavily and Perplexity. | You run hermes tools or set web.backend. |
| Browser | It decides which browser the agent drives. | The options include Browser Use, Browserbase, Firecrawl, Camofox, Lightpanda and local Chromium. | You run hermes tools and open Browser Automation. |
| Memory | It decides where extra long-term memory lives. | The options include Honcho, OpenViking, Mem0, Holographic, RetainDB, ByteRover and Supermemory. | You run hermes memory setup. |
| Hermes as a backend | It decides how other apps reach your agent. | The options are the API server, ACP, MCP serve and hermes serve. | You run the matching command. |
The terminal backend is the one most people mean, so the quick-start begins there.
These seven steps take a new install from the default to a sandboxed setup.
| Step | What you type | What you get |
|---|---|---|
| 1 | Run hermes config get terminal.backend. | You see the backend you're on, which is local on a new install. |
| 2 | Run docker version. | You confirm Docker is running before you switch. |
| 3 | Run hermes config set terminal.backend docker. | Commands now run inside one hardened container. |
| 4 | Run hermes model. | You pick the provider and model that do the thinking. |
| 5 | Run hermes tools. | You pick the web and browser providers. |
| 6 | Run hermes memory setup. | You add one external memory provider, if you want one. |
| 7 | Run hermes doctor. | You see anything that's missing. |
The terminal setting is stored under terminal.backend in ./.hermes/config.yaml, so you can also edit the file by hand.
If the new backend fails, you set the value back to local and test again.
My own config is set to local, which is the default.
The docs say each terminal backend determines where the agent's shell commands actually execute.
| Backend | Where commands run | Isolation | What it needs | The docs say it's best for |
|---|---|---|---|---|
local | They run on your machine. | There is none. | It needs nothing. | It's best for development and personal use. |
docker | They run in one persistent container. | It is full, with dropped capabilities. | It needs Docker or Podman. | It's best for safe sandboxing and CI/CD. |
ssh | They run on a remote server. | It is a network boundary. | It needs TERMINAL_SSH_HOST and TERMINAL_SSH_USER. | It's best for remote dev and powerful hardware. |
modal | They run in a Modal sandbox. | It is a cloud VM. | It needs Modal tokens. | It's best for ephemeral cloud compute. |
daytona | They run in a Daytona workspace. | It is a cloud container. | It needs DAYTONA_API_KEY. | It's best for managed cloud dev environments. |
vercel_sandbox | They run in a Vercel microVM. | It is a cloud microVM. | It needs a Vercel token, project ID and team ID. | It's best for cloud execution with snapshots. |
singularity | They run in an Apptainer container. | It uses namespaces. | It needs the apptainer binary. | It's best for HPC clusters. |
The local backend uses your real home folder, so tools like git and npm find the logins they already have.
The Docker backend starts one long-lived container and sends every terminal, file and code call into it.
A package the agent installs once is still there on the next command and after a restart.
You get a fresh container for every chat when you set container_persistent: false.
You cut the container off from the internet when you set docker_network: false.
The SSH backend keeps one shell alive on the remote host, so the working directory survives between commands.
The three cloud sandboxes save your files between sessions, and the docs say they don't save running processes.
If you want a server for the SSH route, I've ranked hosts in the best Hermes Agent VPS.
🔥 Want the exact Hermes backends in the Agent OS setup I run inside my Agent OS?
Inside the AI Profit Boardroom you get the installable Agent OS, step-by-step video tutorials, four coaching calls a week and 3,400+ members building real automations.
The second meaning of a Hermes Agent backend is the provider that does the thinking.
You add a provider with hermes model in your terminal, and you switch between providers you've already added with /model inside a chat.
| Provider backend | How you set it | Where it fits in an Agent OS |
|---|---|---|
| Nous Portal | You run hermes setup --portal. | It suits one login that covers models and tools. |
| OpenRouter | You add OPENROUTER_API_KEY to ~/.hermes/.env. | It suits profiles that try many models on one key. |
| Anthropic | You pick it in hermes model. | It suits a profile for long, careful work. |
| OpenAI API | You add OPENAI_API_KEY. | It suits teams with an existing OpenAI account. |
| AWS Bedrock | You pick AWS Bedrock in hermes model. | It suits companies that buy through AWS. |
| Ollama | You choose Custom endpoint and enter http://localhost:11434/v1. | It suits a private, offline profile. |
| LM Studio | You pick LM Studio in hermes model. | It suits local models with a desktop app. |
| Custom endpoint | You set provider: custom and a base_url. | It suits any OpenAI-compatible server you run. |
The docs call Nous Portal the recommended way to run Hermes, because one login covers 300+ models and the Tool Gateway.
The docs also warn that Ollama starts with a small context window, so you set context_length in the config for a local model.
You can add a backup chain with hermes fallback, which moves to another provider when the main model fails.
The provider list in the docs is far longer than my table, and it includes Google Gemini, DeepSeek, xAI, Vertex AI and Azure AI Foundry.
Bedrock has enough moving parts that it gets its own guide, Hermes Agent on Bedrock.
Hermes has two web tools, which are web_search and web_extract.
Firecrawl is the default web backend, and the docs also list SearXNG, Brave Search, DuckDuckGo, Exa, Parallel, Tavily, Perplexity, Keenable, xAI and OpenAI Native.
A fresh install works with no key, because requests rotate across the free tiers of Exa, Parallel, Firecrawl and Keenable.
You can split the job with web.search_backend and web.extract_backend, so a free search provider sits next to a different extract provider.
The browser toolset has its own backends, which are Browser Use, Browserbase, Firecrawl, Camofox, Lightpanda, your own Chrome over CDP and a local Chromium.
You choose one in hermes tools under Browser Automation, and the choice is stored as browser.cloud_provider.
The full toolset is covered in the Hermes Agent browser guide.
Memory has a built-in layer in MEMORY.md and USER.md, and that layer is always on.
You can add one external memory provider with hermes memory setup, and only one can be active at a time.
My ranked list of those providers is in the best Hermes Agent memory.
The last meaning flips the direction, because Hermes becomes the backend for something else.
| Mode | How you start it | What connects to it |
|---|---|---|
| API server | You set API_SERVER_ENABLED=true and API_SERVER_KEY in ~/.hermes/.env, then run hermes gateway. | Any OpenAI-compatible frontend connects on port 8642. |
| ACP server | You run hermes acp. | Editors such as VS Code, Zed and JetBrains connect over stdio. |
| MCP server | You run hermes mcp serve. | Other agents such as Claude Code and Cursor connect over stdio. |
| Backend server | You run hermes serve. | The Hermes desktop app and remote clients connect on port 9119. |
| Subscription proxy | You run hermes proxy start. | Apps that only need the raw model connect to it. |
The API server listens on http://127.0.0.1:8642 and speaks the OpenAI Chat Completions and Responses formats.
The docs name Open WebUI, LobeChat, LibreChat, NextChat and ChatBox as frontends that can connect to it.
The agent answers with its full toolset, so a chat app gets terminal, files, web search, memory and skills behind it.
The docs say hermes mcp serve is stdio-only today.
The hermes serve command binds to 127.0.0.1 by default, and a public bind always requires an auth provider.
The docs draw a clear line between two of these: you use the API server when you want the agent, and you use the proxy when you only want the model.
🔥 Want the exact Hermes backends in the Agent OS setup I run inside my Agent OS?
Inside the AI Profit Boardroom you get the installable Agent OS, step-by-step video tutorials, four coaching calls a week and 3,400+ members building real automations.
An Agent OS is one dashboard over the same agent, so every room in it leans on one of these backends.
| Agent OS layer | Backend behind it | What I'd choose and why |
|---|---|---|
| Chat on my own machine | Terminal backend | I'd use local, because I'm the only one typing. |
| Phone and team messages | Terminal backend | I'd use docker, because other people's messages can trigger commands. |
| An always-on server | Terminal backend | I'd use ssh or run Hermes on the server itself. |
| One profile per model | Model backend | I'd give each Hermes profile its own provider and model. |
| Research jobs | Web backend | I'd start on the free default and add a keyed provider when the work matters. |
| Click-and-type jobs | Browser backend | I'd pick a local browser first and a cloud browser for blocked sites. |
| Shared memory | Memory backend | I'd keep the built-in files on and add one provider at most. |
| Other apps and editors | Hermes as a backend | I'd switch on the API server for chat apps and ACP for editors. |
Hermes profiles make this easy, because each profile is its own isolated Hermes with its own config.
That means one profile can run a local Ollama model while another runs a cloud model.
My default profile points at a local model, and I keep separate profiles for other models.
Herald OS shows the same idea in a settings page, where you choose where agents run tasks, including Docker.
This is the choice that matters most.
| Backend | Isolation | Dangerous command check |
|---|---|---|
| local | It has none, because it runs on the host. | The check is on. |
| ssh | It is a remote machine. | The check is on. |
| docker | It is a container. | The check is skipped, because the container is the boundary. |
| singularity | It is a container. | The check is skipped. |
| modal, daytona, vercel_sandbox | They are cloud sandboxes. | The check is skipped. |
On local, the docs say the agent has the same filesystem access as your user account.
Hermes offsets that by checking commands against a list of dangerous patterns and asking you before it runs a match.
On Docker, the container starts with all Linux capabilities dropped, no privilege escalation and a limit of 256 processes.
The docs recommend docker, modal, daytona or vercel_sandbox for production gateway deployments.
A prompt only protects you when a human is there to read it, and a container protects you when nobody is watching.
There is one catch with Docker, which is that any secret you list in docker_forward_env can be read by code inside the container.
The docs also warn that slow shell startup files add delay to every command, because the agent starts many shells.
Hermes is free, and local, Docker, SSH and Singularity cost nothing beyond your own hardware or server.
Modal, Daytona and Vercel Sandbox are paid cloud services with their own pricing, so check each one before you commit.
Your model provider bills separately, unless you run a local model.
Once the backend is settled, Hermes Agent background tasks shows how to keep the agent working after you close the window.
/model, and that job belongs to hermes model.It most often means the terminal backend, which decides where the agent's shell commands run. The docs list seven: local, docker, ssh, modal, daytona, vercel_sandbox and singularity. The word also covers the model provider, web provider, browser provider and memory provider.
Run hermes config set terminal.backend followed by a name such as docker. The value is saved under terminal.backend in ~/.hermes/config.yaml. Run hermes model for the provider, hermes tools for web and browser, and hermes memory setup for memory.
Yes. On local the agent has the same file access as your user account. On Docker, commands run in a container with all capabilities dropped, no privilege escalation and a 256 process limit.
Yes. Choose Custom endpoint in hermes model and enter http://localhost:11434/v1 for Ollama, or pick LM Studio. The docs advise setting context_length, because Ollama starts with a small context window.
Yes. The API server exposes Hermes as an OpenAI-compatible endpoint on port 8642 for frontends such as Open WebUI. Hermes also runs as an ACP server with hermes acp and as an MCP server with hermes mcp serve.
No. Every backend here is set from the Hermes terminal. An Agent OS puts the same agent behind one dashboard, so the backend you choose applies to every room in it.
Start on local, switch to Docker the day another person can message your agent, and give each profile the model it needs.
Do those three things and you'll have the right Hermes Agent backend under your whole Agent OS.
About Julian
I'm Julian Goldie, an AI entrepreneur, SEO expert and the founder of the AI Profit Boardroom, which has 3,400+ members.
I help business owners scale with AI agents, automation and SEO.
My YouTube channel has 400,000+ subscribers, and I run Goldie Agency, a seven-figure SEO agency.
→ Herald OS: The Free Hermes Agent OS
The installable system behind every guide on this site — dashboard, agents, memory and pipelines — updated as new tools land, with 3,400+ members and four coaching calls a week.
Join the AI Profit Boardroom →📺 Video notes + links to the tools 👉
🎥 Learn how I make these videos 👉