Hermes Studio: a self-hosted web dashboard for Hermes Agent

What Hermes Studio is, and who it is actually for

Hermes Agent, maintained by NousResearch, is a command-line agent. Hermes Studio is the browser layer on top of it. The README describes the project as a self-hosted web dashboard that connects directly to the Hermes gateway and streams agent output over SSE, and it is explicit that this is not a chat wrapper: the pitch is multi-agent crews, execution approvals, a visual knowledge graph over memory, skill management and a cron scheduler, all in one interface. The stated audience is "power users running Hermes Agent locally", which is a narrower group than the feature list first suggests.

If you have never installed Hermes Agent, Hermes Studio gives you nothing to look at. The UI is a client. The agent process, the model credentials and the tool execution all live elsewhere. That distinction matters when you evaluate the project, because most of the hard operational work stays on the Hermes side.

How the dashboard talks to the Hermes gateway

The architecture is two processes. The Hermes Agent gateway exposes an HTTP API, and the Studio server (server-entry.js, started with node server-entry.js) serves the built React front end and proxies to that gateway. The default gateway URL is http://127.0.0.1:8642, and the Docker Compose file wires the two containers together so the Studio reaches the agent at http://hermes-agent:8642.

One detail in .env.example is easy to miss and will cost you an afternoon: the Hermes gateway HTTP API server is opt-in. The comment states that you must add API_SERVER_ENABLED=true to ~/.hermes/.env and restart the gateway, because without it the gateway serves messaging platforms but not port 8642. So a working Hermes install does not imply a reachable API. The Compose healthcheck polls http://localhost:8642/health, which is the quickest way to confirm the gateway is actually listening.

State is split across three places. Session persistence can go to Redis via REDIS_URL, with a documented fallback: if Redis is unavailable on startup, the Studio retries for roughly 30 seconds and then falls back to the container file system. MCP server definitions are written to ~/.hermes/config.yaml and trigger a live reload. Logs are read from ~/.hermes/logs/, with the /logs screen pulling the last 500 lines. That file-based coupling to the Hermes home directory is the project's real integration surface.

Installing Hermes Studio with Docker Compose

The README's Docker path is the shortest route. Copy the environment template, put an Anthropic key in it, and bring the stack up. The Compose file's header gives exactly these steps, and it notes that ANTHROPIC_API_KEY is required for the agent gateway.

cp .env.example .env
# edit .env and set ANTHROPIC_API_KEY
docker compose up

After the containers start, open http://localhost:3000. The agent container publishes port 8642 and the Studio serves on 3000. If you want sessions to survive a container restart, add Redis and use the redis profile instead:

# in .env
REDIS_URL=redis://redis:6379

docker compose --profile redis up

Builds track the Hermes Agent main branch by default. The Compose header documents pinning, either on the command line or through .env, which is the difference between a reproducible deployment and one that changes under you:

HERMES_AGENT_VERSION=0.18.0 docker compose up

For a non-Docker install, package.json defines the scripts. npm run dev serves Vite on port 3000, npm run build produces the bundle, and npm start runs server-entry.js. The Dockerfile builds on node:22-alpine and runs the server as a non-root hermes user, and the README badge states Node >=22.0.0. The README also documents installing the Studio as a PWA, which is how the project expects mobile access to work, typically over Tailscale.

Cron jobs, approvals and the parts that need the gateway

The feature the README leads with is the cron job manager: create, edit, pause, trigger and monitor scheduled agent tasks from the UI, with manual triggers streaming live tool events into the job card over SSE. Execution approvals are the second half of that story. Shell commands the agent wants to run surface in the browser for approve, deny or always-allow, and the README says resolved receipts are shown inline. Both features depend entirely on the gateway connection being live.

Other pieces follow the same pattern. Multi-agent crews let you define named groups of specialised agents and dispatch work to all or selected members. Profile-scoped workspaces give each crew member an isolated file system view through per-profile workspace roots. The knowledge graph is a force-directed view of wiki-link relationships in agent memory. MCP servers are added and removed from the Settings UI, saved to ~/.hermes/config.yaml, and reloaded without editing the file by hand. Cost tracking reports per-crew input and output tokens with a model-aware price table, which is an estimate, not a bill.

None of this is a sandbox. The README claims auth middleware on API routes, CSP headers, path traversal guards and exec approval prompts, but the approval prompt is a control on agent-initiated shell commands, not a container boundary around the Studio itself.

Where Hermes Studio is the wrong tool

The clearest failure mode is a missing gateway. If API_SERVER_ENABLED is not set in ~/.hermes/.env, the agent serves its messaging platforms and nothing on port 8642. The Studio will start, the front end will load, and every meaningful action will fail because there is no API behind it. The .env.example comment is the only place this is spelled out, and it is the single most common way a first install goes wrong.

A second boundary is scope. If you want a general chat interface for OpenAI, Anthropic or Ollama without an agent runtime, this is the wrong layer: the model backends are reached through Hermes, and the Studio's value is in the agent-specific surfaces (memory, skills, approvals, crews) that a plain chat client does not have. The README's own framing, "built for power users running Hermes Agent locally", is a fair warning rather than marketing.

Third, the repository's licence metadata is listed as NOASSERTION while package.json declares MIT and the README badge links to a LICENSE file. The README does not explain the discrepancy. If licence terms matter to your organisation, read the LICENSE file itself rather than the metadata field. Finally, the README documents a one-click backup and restore of Hermes data but does not document rollback for a restore, so treat that button as a one-way operation until you have verified it against your own data.

Hermes Studio compared with hermes-workspace

The README contains a section titled "What's different from hermes-workspace", so the project positions itself against another Hermes front end rather than against generic chat UIs. The stated difference is the scheduler: Hermes Studio is described as "the only Hermes web UI with a built-in cron job manager", and the feature list adds that no other Hermes UI offers the same set of 30+ features. The README does not enumerate what hermes-workspace does provide, so the comparison is one-sided and you should check that project directly if scheduling is not your priority.

Against a plain terminal session with Hermes Agent, the trade is straightforward. The terminal gives you the agent without an extra Node process, a Redis dependency or a web server exposed on your network. The Studio gives you approvals you can read before clicking, a visual memory graph, cost estimates per crew and a scheduler that survives your laptop closing. Whether that is worth running two services depends on whether you actually use those surfaces. If you mostly type prompts and read output, the terminal is the smaller system.

Editorial conclusion

Adopt Hermes Studio if you already run Hermes Agent and want its memory, skills, approvals and multi-agent crews in a browser instead of a terminal, and you can accept that the gateway HTTP API is opt-in and must be enabled separately. Do not adopt it as a standalone chatbot: without a Hermes Agent process on port 8642 there is nothing for the UI to talk to, and the README does not document rollback for its backup and restore feature. Verify first that your Hermes gateway has API_SERVER_ENABLED=true in ~/.hermes/.env, that Docker Compose can reach port 8642, and that the NOASSERTION licence field on the repository matches the MIT text in the LICENSE file before you depend on it.

Frequently asked questions

Official sources

1. Issues
2. JPeetz/Hermes-Studio on GitHub
3. Project website
4. README
5. Releases