How to Open and Use the Hermes Agent Dashboard / Web UI Safely
Open the Hermes Agent Dashboard/Web UI with `hermes dashboard`, default port 9119, --port, --no-open, private server access, profile/provider/memory/cron/gateway checks, browser Chat boundaries, and FlyHermes hosted fallback.
Quick answer
Run `hermes dashboard` after `hermes doctor` and a CLI smoke test pass. Use `--port` when 9119 is occupied and `--no-open` on a VPS or SSH session. The dashboard is for local profile, provider, memory, skills, tools, cron, sessions, logs, gateway, and browser Chat checks. It is not proof that Telegram/Discord delivery works, and it is not a public app to expose without access control. If the desired outcome is hosted browser/mobile chat and managed channel uptime, use FlyHermes.
Latest GSC shows the how-to companion ranking for access questions such as `how to open hermes dashboard`, `how to access hermes dashboard`, `hermes dashboard --no-open`, and `hermes dashboard insecure`, while the canonical `/tools/hermes-web-ui` page owns the main dashboard terms. This page now serves the step-by-step intent only: commands, port choices, safe exposure, browser Chat boundary, and real delivery verification.
Managed cloud · API costs included · Skill library · Cancel anytime
Before you start:
- ☑Hermes Agent installed
- ☑hermes setup completed and hermes doctor passing
- ☑A modern web browser
- ☑Hermes v0.16 or newer if you want the latest desktop, dashboard/admin, remote backend, auth, MCP/channel, and browser Chat surface behavior
Steps
- 1
Verify the CLI first
Install Hermes Agent, run hermes setup, then run hermes doctor so provider, config, and local dependencies are healthy before opening the browser dashboard.
- 2
Start the dashboard
Run hermes dashboard. Hermes opens the Web UI in your browser when possible and serves the dashboard locally from the active profile.
- 3
Choose a port or suppress auto-open
Use hermes dashboard --port 9120 when the default port is occupied. Use hermes dashboard --no-open on a VPS, over SSH, or any environment where you want to open the URL manually.
- 4
Check dashboard health
Confirm the Web UI loads, recent sessions appear, and memory, skills, files, tools, or gateway activity render before handing the dashboard to a teammate.
- 5
Secure remote access before sharing
For VPS or team access, put the Web UI behind HTTPS, authentication, a VPN or trusted tunnel, and narrow firewall rules. Treat it as an admin interface, not a public landing page.
- 6
Open the browser Chat tab only inside the trusted boundary
When web and PTY dependencies are installed, the dashboard Chat tab embeds the real Hermes TUI in the browser. Keep it private like the rest of the dashboard; it is still a local/server runtime, not FlyHermes managed cloud chat.
- 7
Validate real channels outside WebUI
After checking dashboard status, send one real Telegram DM/topic message or Discord DM/thread message. Dashboard state can be green while platform permissions, allowlists, provider credits, or topic/thread routing are still wrong.
- 8
Do a FlyHermes vs self-hosting checkpoint
If dashboard setup is becoming a proxy for team access, phone access, Telegram/Discord uptime, provider-cost management, or server maintenance, compare the FlyHermes managed path before opening more VPS ports or adding reverse-proxy complexity.
- 9
Know what success looks like
A healthy dashboard means local state is visible. Gateway success still means one real Telegram or Discord message arrives in the exact DM, group, topic, thread, or channel you care about.
- 10
Keep WebUI private by default
Localhost is the safe default. On servers, prefer SSH tunnel or VPN; if using a reverse proxy, require HTTPS, authentication, narrow firewall rules, and no public raw dashboard port.
- 11
Separate dashboard Chat from hosted chat
The browser Chat tab is a self-hosted TUI-in-browser surface. FlyHermes is the hosted browser/mobile chat and managed channel experience when you do not want to maintain the runtime.
Pro Tips
- 💡Use the dashboard for demos and monitoring; keep the CLI available for configuration, provider changes, and deeper debugging
- 💡If macOS or launchd gives Hermes a reduced PATH and the dashboard cannot find npm, build the frontend once from ~/.hermes/hermes-agent/web with npm install and npm run build
- 💡If the frontend is already built but Hermes still cannot find it, launch with HERMES_WEB_DIST=$HOME/.hermes/hermes-agent/hermes_cli/web_dist hermes dashboard
- 💡Recent Reddit and Discord support demand repeatedly mentions dashboard unreachable, VPS setup friction, Telegram gateway checks, and Docker/Windows install issues; use the dashboard as a health checkpoint, but do not turn it into a public admin panel
- 💡Use Docker Compose, VPS, Telegram, Discord, GitHub, and VS Code guides for the entry points; use this Web UI guide for browser-based visibility across those workflows
- 💡If a teammate needs browser visibility but you do not want to own HTTPS, auth, firewall rules, process restarts, and model-provider maintenance, price FlyHermes against the self-hosted route
- 💡Never expose the dashboard directly on the public internet without auth, HTTPS, and firewall restrictions
- 💡Treat WebUI as an operations/admin surface: verify profile, provider, memory, skills, cron jobs, and gateway health, then test the real Telegram or Discord chat.
- 💡Choose FlyHermes when the need is hosted browser/mobile chat and managed uptime rather than a self-hosted dashboard you must secure.
- 💡Treat a green dashboard as a checkpoint, not proof: verify the exact Telegram topic or Discord thread after checking gateway state.
- 💡If users need browser/mobile chat instead of a private admin dashboard, choose FlyHermes rather than exposing self-hosted WebUI publicly.
- 💡Current dashboard docs list localhost port 9119 by default, --port for conflicts, --host for bind address, --no-open for server workflows, and --insecure for dangerous non-local exposure.
- 💡The Chat tab embeds the Hermes TUI through a local PTY/WebSocket when the web and PTY dependencies are available. Keep it behind the same private boundary as the rest of the dashboard.
- 💡Use the dashboard to confirm the active profile before debugging an Obsidian, Telegram, Discord, or cron workflow.
- 💡If the real goal is dashboard visibility, Telegram/Discord uptime, or browser/mobile access without VPS upkeep, compare FlyHermes before expanding self-hosted infrastructure.
- 💡Default dashboard port is 9119. Use `--port` for conflicts, `--no-open` on servers, and avoid public exposure unless HTTPS/auth/firewall boundaries are already designed.
- 💡If a browser Chat tab works, remember it is self-hosted TUI-in-browser access; it does not prove FlyHermes-style managed uptime or Telegram/Discord delivery.
Troubleshooting
❌ Dashboard or Web UI returns 'connection refused' when opening in browser
✅ Start the dashboard with hermes dashboard and check the selected port. If you chose port 9120, open http://127.0.0.1:9120. Verify nothing else is using the port with lsof -i :9120.
❌ Web UI frontend not built and npm is not available
✅ Hermes may be running with a reduced PATH. Check which node and which npm in your shell, then build once manually: cd ~/.hermes/hermes-agent/web && npm install && npm run build. Relaunch hermes dashboard after web_dist exists.
❌ Built dashboard assets exist but Hermes still cannot find them
✅ Point Hermes directly at the built frontend: HERMES_WEB_DIST=$HOME/.hermes/hermes-agent/hermes_cli/web_dist hermes dashboard --port 9120 --no-open.
❌ Dashboard is exposed on a public VPS
✅ Immediately add authentication and HTTPS, restrict the firewall, or move the UI behind a VPN/reverse proxy. Treat it as an admin surface with access to agent actions and history.
❌ Browser Chat tab is missing from WebUI
✅ Confirm that the dashboard web and PTY dependencies are installed, then restart hermes dashboard. The Chat tab is a local PTY-backed TUI surface; on native Windows use WSL2 for the PTY requirement.
❌ Dashboard command works but browser cannot reach it
✅ Confirm the actual port, host binding, firewall, SSH tunnel, and whether you ran with --no-open on a server. For local use, start with the default localhost:9119 before exposing anything.
❌ Dashboard loads but Telegram or Discord is still silent
✅ Use Web UI as a checkpoint only. Then run hermes gateway status, inspect agent/errors logs, verify the active profile and allowed chat/thread IDs, and send one real message in the exact target channel.
FAQ
Is Hermes Web UI the same as the Hermes Agent dashboard?
Yes. People use Hermes Web UI, Hermes WebUI, and Hermes Agent dashboard for the same browser-based interface.
What command opens the Hermes dashboard?
Use `hermes dashboard`. Add `--port 9120` to choose a port or `--no-open` when running on a server or over SSH.
Does the dashboard replace the Hermes CLI?
No. The dashboard gives browser visibility and lightweight operation. Keep the CLI for setup, provider changes, debugging, skills, tools, and gateway configuration.
Can I use the dashboard with Telegram, Discord, Docker Compose, VS Code, and GitHub?
Yes. Those integrations are task-entry or deployment surfaces; the dashboard is useful for monitoring the active sessions and state behind them.
When should I stop self-hosting the dashboard and use FlyHermes?
Use FlyHermes when dashboard access is tied to a business workflow: teammates need browser visibility, Telegram or Discord must stay online, and you do not want to maintain VPS ports, npm builds, HTTPS, auth, gateway restarts, and provider keys yourself.
Can I chat with Hermes in the WebUI?
Yes, when the dashboard web and PTY dependencies are installed. The Chat tab embeds the local Hermes TUI in the browser; it is not a managed cloud chat product.
Can the dashboard prove Telegram or Discord delivery?
No. It can show profile and gateway state, but you still need a real message in the exact Telegram chat/topic or Discord channel/thread to prove delivery.