Hermes Studio is now Ekko Studio: a multi-agent workspace whose coding agents run on the backend host
Web dashboard for Hermes Agent — multi-platform AI chat, session management, scheduled jobs, usage analytics
At a glance
- What is it?
- EKKOLearnAI/hermes-studio ships a desktop app, an npm CLI and a Docker image for chatting with Hermes Agent, Ekko Agent and 14 coding-agent CLIs. The rename, the split session stores and the host-bound coding agents shape how you should deploy it.
- Who is it for?
- Ekko Studio fits someone who already runs Hermes Agent or several coding CLIs on one machine and wants one console with sessions, workflows and platform channels on top. It does not fit anyone who wants coding agents to run on their own laptop while the console lives on a server, or who needs a permissive license.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on November 13, 2026, and from our analysis. They are not legal advice.
Star history
- EKKOLearnAI/hermes-studio11,764 ★ · +756
| Repository | 2026-09-10 | 2026-11-13 |
|---|---|---|
| EKKOLearnAI/hermes-studio | 11k | 11.8k |
756 Stars in the last 64 days, measured from the daily GitHub snapshot. Compare with other projects
Editorial analysis
The repository name no longer matches the product
Anyone searching for Hermes Studio lands on a project that now calls itself Ekko Studio. It was previously named Hermes Studio and, before that, Hermes Web UI. The GitHub repository is now `EKKOLearnAI/ekko-studio`, the primary npm package is `ekko-studio`, and the command it installs is `ekko-studio-web`. The older `hermes-web-ui` package and command are still supported and receive the same releases, so existing scripts keep working.
The rename leaks into everything below the surface. The `bin` map in package.json registers `hermes-web-ui`, `hermes-web-ui-mcp`, `hermes-studio-mcp`, `ekko-studio-mcp` and `ekko-studio-web`, and `ekko-studio-web` points at the same `./bin/hermes-web-ui.mjs` file as the legacy name. Environment variables follow both naming schemes: docker-compose.yml sets `EKKO_STUDIO_ACP_TIMEOUT_MS` next to `HERMES_ACP_TIMEOUT_MS`, with a comment that defaults are kept in Studio so an unset or invalid new name can fall back to its legacy alias. The repository metadata lists https://hermes-studio.ai as the homepage while package.json points to https://ekkostudio.xyz. If you are following an older tutorial, expect names to differ from what you see on screen.
Three install paths, and only two of them bring Hermes along
Ekko Studio ships as a desktop app for Windows, macOS and Linux, as an npm CLI package, and as a Docker image. The choice matters more than it looks, because the Hermes runtime is not handled the same way in each. Ekko Agent is built in everywhere. The desktop app and the Docker image bundle a Hermes runtime. An npm installation does not: it discovers an existing Hermes installation on the machine.
The npm route is a single line:
npm install -g ekko-studio && ekko-studio-web startThe package declares `"node": ">=23.0.0"` in its engines field, so a machine still on an older Node release has to upgrade before this works. The consequence for readers is direct: if you pick npm on a fresh machine without Hermes Agent, you get Ekko Agent and whatever coding CLIs you install, but no Hermes chat until you install Hermes separately from https://github.com/NousResearch/hermes-agent. The desktop installers are published on the releases page of `EKKOLearnAI/ekko-studio`.
The Docker image is built on an unpinned hermes-agent base
The Dockerfile starts from `ARG BASE_IMAGE=nousresearch/hermes-agent:latest`. Because the base tag is `latest`, two builds of the same Studio commit on different days can contain different Hermes versions. If reproducibility matters, override `BASE_IMAGE` with a fixed tag at build time.
On top of that base the build installs ca-certificates, curl, ffmpeg, make and g++, then downloads Node.js v24.22.1 for the host architecture, mapping `amd64` to `x64`. It runs `npm ci --ignore-scripts && npm rebuild node-pty`, which is the native module behind the web terminal, and sets `NODE_OPTIONS=--max-old-space-size=4096` with a comment that it prevents out-of-memory failures during the build. Plan for a build host with that much memory available to Node.
The runtime image sets `NPM_CONFIG_PREFIX=/home/agent/.hermes-web-ui/coding-agent/npm` and adds its `bin` directory to `PATH`. That is how coding-agent CLIs installed from inside the running container survive restarts: they land in the Studio data volume instead of the image layer. The entrypoint is `/app/bin/start-studio-all.sh`, which replaces the base image's own startup script.
docker-compose opens more ports than the web console needs
The bundled docker-compose.yml publishes four mappings. Port 6060 is the console itself, controlled by `PORT`. Port 8651 is mapped through `PREVIEW_FRONTEND_PORT`, port 56121 through `XAI_OAUTH_PORT` for the xAI OAuth callback, and a UDP range of 50000 to 50127 through `STUDIO_P2P_UDP_PORT_RANGE`. On a public server each of these is reachable unless you firewall it, so decide which ones you actually use before running the file unchanged.
Both `/home/agent/.hermes` and `/home/agent/.hermes-web-ui` are mounted from `HERMES_DATA_DIR`, defaulting to `./hermes_data`, so Hermes state and Studio state live side by side in one directory on the host. Back up that directory, not the container.
Two defaults deserve attention. `HERMES_WEB_UI_AUTH_JWT_EXPIRES_IN` defaults to `30d`, so a login token stays valid for a month unless you shorten it. `HERMES_APP_ENTITLEMENT_REQUIRED` defaults to `true`, alongside an empty `HERMES_APP_ENTITLEMENT_PUBLIC_KEY`. The compose file also sets `HERMES_WEB_UI_XAI_CALLBACK_BIND_HOST=0.0.0.0`, which binds the OAuth callback on all interfaces inside the container.
Coding agents execute where the backend runs, not where you sit
Single chat, group chat and workflows share one Agent catalog covering Claude Code, Codex, Pi, Grok, OpenCode, DeepSeek Harness, Qwen Code, Kimi Code, CodeBuddy, GitHub Copilot CLI, ZCode, Cursor, Qoder and Antigravity. Every one of them runs on the machine hosting the Studio backend, and its CLI must be installed there. If you host Studio on a VPS and open it from a laptop, the agent edits files on the VPS and uses the VPS's credentials.
Installation support is uneven. Claude Code, Codex, Pi, Grok, OpenCode and DSH can be installed and updated through Agent Manager. Qwen Code, Kimi Code, CodeBuddy and GitHub Copilot CLI support npm installation through Agent Manager, but ZCode requires manual installation, as do Cursor and Antigravity.
Each agent runs in one of two modes. Scoped mode uses isolated session configuration and, on supported runtimes, the provider and model you selected in Studio. Global mode reuses the CLI's existing configuration and sign-in. Cursor and Qoder only offer native global configuration, so Studio cannot swap their model from its own provider list. Available models, tools and context controls depend on each runtime, which means a feature you see for one agent may be missing for another.
Studio sessions and Hermes history live in separate stores
Chat runs stream over Socket.IO on the `/chat-run` namespace, and Studio dispatches each run to the adapter for the selected runtime. Conversations started in Studio are written to its own local SQLite database. Hermes keeps its own `state.db`, which Studio reads but never writes; it is exposed only through the Hermes history APIs.
The split has a visible cost. The Ctrl+K session search covers the Studio database only, and read-only Hermes history sessions are not included. If you have months of Hermes conversations from before installing Studio, you can browse them but cannot find them through the global search box.
Inside Studio itself, sessions can be created, renamed, deleted and grouped by source such as Telegram, Discord or Slack, with live sessions pinned to the top. Each turn reports token usage, cache hits, estimated cost and generation speed. File downloads resolve paths across local, Docker, SSH and Singularity backends, and generated HTML, PDF, DOCX, PPTX, XLSX, CSV, image, Markdown and source files get inline previews.
Ten platform channels configured from one page
Ekko Studio collects configuration for 10 messaging platforms on a single page. The options differ per platform. Telegram takes a bot token plus mention control, reactions and free-response chats. Discord adds auto-thread and channel allow and ignore lists on top of bot token, mention and reactions. Slack covers bot token, mention control and bot message handling. WhatsApp exposes an enable switch, mention control and mention patterns. Matrix needs an access token and homeserver and supports auto-thread and DM mention threads. Feishu (Lark) is also on the list.
The practical point is that these settings are not uniform. A rule you set for Discord channels has no direct equivalent on WhatsApp, so a bot that behaves politely in one room may answer every message in another. Sessions arriving from these channels show up grouped by source in the chat sidebar, which is where you check what each channel actually triggered.
A fast release cadence under a source-available license
The project is under heavy active development. The last push was on 2026-11-02, and three releases, v0.8.12, v0.8.13 and v0.8.14, were tagged between 2026-11-02 and 2026-11-03. The screenshots in the repository were captured from v0.7.33 on 2026-10-10, so the interface you install will not match them exactly. For a self-hosted deployment, pin the npm version or image tag and upgrade deliberately rather than pulling the newest build each time.
Licensing needs a closer look than the GitHub sidebar gives. GitHub reports the license as NOASSERTION, while package.json declares `BSL-1.1`, the Business Source License. That is a source-available license rather than an OSI open source license, so anyone planning to embed Ekko Studio in a commercial offering should read the LICENSE file in the repository before building on it.
Editorial conclusion
Ekko Studio fits someone who already runs Hermes Agent or several coding CLIs on one machine and wants one console with sessions, workflows and platform channels on top. It does not fit anyone who wants coding agents to run on their own laptop while the console lives on a server, or who needs a permissive license. Before deploying, read the BSL-1.1 terms, decide between desktop, npm and Docker based on whether you already have Hermes installed, and pin a release rather than tracking a project that shipped three versions in two days.
Frequently asked questions
What is Hermes Studio?
Hermes Studio is the former name of Ekko Studio, a local-first AI workspace for multi-agent chat, coding and visual workflows. It runs as a desktop app or a self-hosted web console and supports Hermes Agent, Ekko Agent and 14 coding-agent integrations.
How does Hermes Studio differ from Hermes Agent?
Hermes Agent is the agent runtime published at NousResearch/hermes-agent. Hermes Studio, now Ekko Studio, is the workspace around it: the desktop and Docker builds bundle a Hermes runtime, while the npm package discovers an existing Hermes installation.
Who is behind Hermes Studio and Hermes Agent?
Hermes Studio, now Ekko Studio, is published by EKKOLearnAI on GitHub. The Hermes Agent runtime it connects to lives in the NousResearch/hermes-agent repository.
How does the Hermes Studio system work?
The Studio backend streams chat over Socket.IO on /chat-run and dispatches each run to the adapter for the selected agent. Coding agents run on the machine hosting that backend, and Studio sessions are stored in a local SQLite database.
Official sources
Was this useful?