Ekko Studio: a self-hosted web console for Hermes Agent and four other runtimes

What Ekko Studio adds on top of Hermes Agent

Hermes Agent is a runtime. Ekko Studio is the surface around it. The README states the project is "the shared product platform, not a sixth agent," and that framing decides almost everything else. It coordinates five runtimes grouped into three families: Hermes (profiles, providers, models, skills, plugins, memory, jobs, Kanban, channels, MCP, terminal), Ekko (execution, approvals, clarifications, memory, MCP), and a coding family of Claude Code, Codex and Pi. Studio owns what those runtimes share: single chat, group chat, global-agent orchestration, workflows, webhooks, sessions, file uploads, TTS/STT, media, themes, devices, networking, logs, usage, authentication and App connectivity.

The audience is narrow but real. If you run Hermes Agent headless and manage its config files by hand, Ekko Studio gives you a browser UI for the same state. The channel page alone covers ten platforms (Telegram, Discord, Slack, WhatsApp, Matrix, Feishu, DingTalk, QQBot, WeChat, WeCom), and the README is explicit about where those settings land: credentials are written to `~/.hermes/.env`, channel behaviour to `~/.hermes/config.yaml`. That is the project's real value proposition. It is not a new agent, it is an operations console for agents you already have installed.

The boundary is enforced in the HTTP layer, which is a design decision worth noting. Studio-owned APIs live under `/api/studio/*`; Hermes-owned control-plane APIs live under `/api/hermes/*`. Released mobile App paths go through one centralized compatibility layer rather than duplicated legacy controllers. If you plan to script against the dashboard, that split tells you which routes survive a Studio upgrade.

How the runtime adapters and session storage actually work

Chat is not a thin proxy. The README says real-time streaming runs over Socket.IO on the `/chat-run` namespace, and Studio dispatches each run to Hermes, Ekko, Claude Code, Codex or Pi through runtime adapters. One session, five possible backends. Tool calls are rendered with expandable arguments and results, and generated files get inline previews for HTML, PDF, DOCX, PPTX, XLSX, CSV, images, Markdown and source files.

The storage split is the part people get wrong. Ekko Studio keeps a self-built session database in local SQLite for Studio sessions. Hermes' own `state.db` stays a read-only source for Hermes history APIs. The README states plainly that Ctrl+K session search covers the Studio local session database and that read-only Hermes history sessions are not included. So the same chat can appear in one view and not the other. Budget for that: if your team expects one search box over all history, it does not exist yet.

Everything else follows the same pattern of Studio owning the shared layer. Scheduled jobs are cron entries you can create, edit, pause, resume, delete or trigger immediately, with expression presets. Usage analytics breaks tokens into input and output, adds session count with a daily average, estimated cost, cache hit rate, a model distribution chart and a 30-day trend with a bar chart and data table. Visual workflows run on a Vue Flow canvas that can target all five runtimes. Kanban is profile-aware and shares the same local Studio state and authentication model as the rest of the dashboard.

Installing Ekko Studio from npm and running a first session

The README gives the npm path directly in its header: install the package globally, then start it. Node.js 23.0.0 or newer is required according to the `engines` field in package.json, so check that first.

npm install -g hermes-web-ui && hermes-web-ui start

After `start`, the console is served by the bundled server. The development script binds Vite to port 8648 (`vite --host --port 8648`), while the split dev setup runs the backend on 8647 and the client on 8649. For a first real use, open the chat view, create a session, and pick a runtime. The README describes the model selector as profile-aware: it discovers models available to the signed-in account through authorized Hermes profiles, so the list you see depends on which Hermes profiles exist on the machine.

If you prefer containers, the repository ships a `docker-compose.yml` that builds from the included Dockerfile, which itself starts from `nousresearch/hermes-agent:latest`. The compose file maps the data directory and sets the environment:

services:
  hermes-webui:
    ports:
      - "${PORT:-6060}:${PORT:-6060}"
    volumes:
      - ${HERMES_DATA_DIR:-./hermes_data}:/home/agent/.hermes
    environment:
      - HERMES_HOME=/home/agent/.hermes
      - HERMES_WEB_UI_MANAGED_GATEWAY=1
      - HERMES_APP_ENTITLEMENT_REQUIRED=${HERMES_APP_ENTITLEMENT_REQUIRED:-true}

The container listens on port 6060 by default and mounts your Hermes data directory, so channels, profiles and jobs configured in the browser persist outside the container. Two environment variables deserve attention before you start: `HERMES_APP_ENTITLEMENT_REQUIRED` defaults to `true`, and `HERMES_WEB_UI_AUTH_JWT_EXPIRES_IN` defaults to `30d`. The README does not document what happens when entitlement checking is left on without a public key supplied, so verify that in your own environment rather than assuming it fails open.

Where Ekko Studio is the wrong tool

The clearest limitation is structural. Ekko Studio depends on Hermes Agent. The Dockerfile builds `FROM nousresearch/hermes-agent:latest` and sets `HERMES_BIN=/opt/hermes/.venv/bin/hermes`. If you do not run Hermes, most of the control plane has nothing to control. The README does not describe a mode where Studio operates standalone against a remote agent, and the split between `/api/studio/*` and `/api/hermes/*` suggests the two are meant to live together.

Second, the session search boundary is a real workflow constraint, not a footnote. Ctrl+K searches the Studio SQLite database only. Hermes history sessions are read-only and excluded. Anyone migrating from the Hermes CLI to the dashboard will find that older conversations do not surface in the search they reach for first.

Third, the licence is not permissive in the way the repository metadata suggests. The GitHub licence field reads NOASSERTION, while package.json declares `"license": "BSL-1.1"`. Business Source License terms typically restrict production use for a period, and the README does not summarise the grant, the change date or the change licence. If you are deploying this inside a company, read the LICENSE file at the repository root before you build an image around it. That is a factual gap in the documentation, and it is the one I would resolve first.

Finally, the build is heavy. The Dockerfile installs ffmpeg, make and g++, downloads Node.js 24.15.0, sets `NODE_OPTIONS=--max-old-space-size=4096` to avoid OOM during the build, runs `npm ci --ignore-scripts` followed by `npm rebuild node-pty`, then builds and prunes. That is a multi-stage compile for what is, at the user's end, a dashboard.

Ekko Studio versus the Hermes Agent CLI

The honest alternative is not another dashboard. It is running Hermes Agent directly and skipping Studio entirely. Hermes Agent owns profiles, providers, models, memory, skills, plugins, jobs, Kanban, channels, MCP and the terminal. Every one of those is a Hermes-owned capability that Studio merely exposes. A team comfortable editing `~/.hermes/config.yaml` and `~/.hermes/.env` by hand gets the same underlying behaviour without the Node.js 23 runtime, the SQLite session store, the Socket.IO layer or the BSL-1.1 question.

What you give up is the parts that only exist in Studio: the shared chat and group chat across runtimes, the workflow canvas, the usage charts, the file browser, voice input and output, device discovery, and the ten-platform channel page in one view. The trade is a heavier stack for a broader surface. If your work is a single Hermes profile driving one chat interface, the CLI is the smaller commitment. If you are coordinating Hermes, Ekko and a coding agent in the same workspace, hand-editing config stops scaling and the dashboard starts earning its footprint.

A second comparison sits inside the project itself. Ekko Studio ships as a desktop app for Windows, macOS and Linux, an npm CLI package, and a Docker image. The desktop build and the Docker build are not identical in operation: the compose file sets `HERMES_WEB_UI_MANAGED_GATEWAY=1` and `HERMES_ALLOW_ROOT_GATEWAY=1`, which the README does not explain in the excerpt available. Choose the Docker path only if you intend to run the managed gateway.

Maintenance, upgrade surface and licence cost

The repository is not archived, and the last push was on 2026-09-09. Releases in the weeks before that were frequent: v0.7.17 on 2026-09-04, v0.7.18 on 2026-09-06, then v1.0.2 on 2026-09-09. The npm package version in package.json is 0.7.21, which sits below the v1.0.2 release tag, so the published package and the GitHub release are not the same number. Confirm which version your install resolves before you plan an upgrade.

Upgrade cost is concentrated in three places. The Node.js floor is 23.0.0, so older hosts need a runtime change before any upgrade. The Docker image pins Node.js 24.15.0 and installs runtime coding-agent CLIs into `NPM_CONFIG_PREFIX=/home/agent/.hermes-web-ui/coding-agent/npm`, which is deliberately inside the Studio data volume so those CLIs survive container replacement. And the API split between `/api/studio/*` and `/api/hermes/*` gives you a rough signal of what a Studio release can change without touching Hermes behaviour.

On licence: package.json declares BSL-1.1 and the GitHub metadata says NOASSERTION. I am not going to interpret the terms for you. Read the LICENSE file at the repository root and decide whether the grant covers your deployment. What I can say is that a Business Source License is not an open source licence in the OSI sense, and the README does not state the change date or the change licence, so the file is the only authority.

Editorial conclusion

Adopt Ekko Studio if you already run Hermes Agent and want one dashboard for its profiles, channels, cron jobs and token usage, or if you want a self-hosted front end for several coding agents behind a single login. Do not adopt it as a lighter substitute for Hermes Agent itself: the README states Studio is the shared product platform, not a sixth agent, and its control-plane APIs depend on a Hermes install. Before rollout, check that Node.js 23.0.0 or newer is available, that the BSL-1.1 terms fit your use, and whether the Docker path's HERMES_APP_ENTITLEMENT_REQUIRED default of true will block your deployment.

Frequently asked questions

Official sources

1. EKKOLearnAI/hermes-studio on GitHub
2. Issues
3. Project website
4. README
5. Releases