How to Use the Hermes Agent Dashboard as a Private AI Agent Command Center

Steps

1. 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. 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. 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. 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. 5

   Check the operator tabs in order

   In WebUI, inspect Sessions, Analytics/usage, Logs, Cron Jobs, Skills, Config, and Gateway state before changing providers, bot tokens, or Docker/VPS settings. The goal is to identify which layer failed, not just confirm that the page loads.

6. 6

   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.

7. 7

   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.

8. 8

   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.

9. 9

   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.

10. 10

    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.

11. 11

    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.

12. 12

    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.

13. 13

    Use WebUI as a command center, not final proof

    After checking sessions, analytics, logs, cron jobs, MCP, skills, config, and gateway status, prove the actual workflow with one delivered Telegram/Discord message, cron report, or browser Chat response.

14. 14

    Choose the hosted path when access becomes the product

    If teammates need mobile/browser access and always-on connected channels, compare FlyHermes before exposing a self-hosted admin dashboard through public networking.

15. 15

    Run the dashboard-to-delivery proof loop

    After Web UI looks healthy, verify the exact output path: send one Telegram/Discord reply, trigger one cron report, or run one browser Chat response. Record that result as the success condition.

16. 16

    Decide self-hosted versus managed before exposing access

    If a teammate or phone needs access, choose SSH/VPN/authenticated HTTPS for the private dashboard or use FlyHermes for managed browser/mobile chat and channels. Do not publish the raw dashboard port.

Pro Tips

• 💡Fresh 2026 demand around agent dashboards is really about operational trust: multi-session visibility, long-running jobs, provider failures, and uptime. If those chores are the blocker, compare the managed FlyHermes path before widening self-hosted exposure.
• 💡Treat the dashboard as a control-plane check, not the success condition: if Telegram, Discord, cron, or browser Chat is the workflow, verify that exact workflow after the dashboard looks healthy.
• 💡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.
• 💡Weekly buyer-demand note (2026-06-22): recent GSC/dashboard searches, Reddit Claude Code monitor/cost threads, YouTube dashboard walkthroughs, and Discord gateway/support clusters all point to the same decision — self-host if you want control, but use FlyHermes when dashboard visibility, Telegram/Discord uptime, provider credits, and VPS maintenance are the work you do not want to own.
• 💡2026-06-29 GSC rank-up evidence: `hermes dashboard`, `hermes agent dashboard`, and `hermes web dashboard` already rank on the dashboard cluster, so this guide stays focused on commands, ports, server access, delivery proof, and FlyHermes boundary rather than creating a duplicate article.
• 💡Fresh source boundary: YouTube/Reddit/GSC are current; Discord dashboard examples are historical fallback evidence until the CDP refresh script is repaired.
• 💡Treat the dashboard as an admin surface, not a public landing page: keep it local, tunneled, VPN-protected, or otherwise authenticated.
• 💡Use the dashboard to find stale gateway/provider/config state, then verify real delivery by sending one Telegram or Discord message in the actual target chat or topic.
• 💡If teammates need access from phones or browsers without maintaining the host, route them to FlyHermes instead of exposing your self-hosted dashboard.
• 💡Use the profile switcher before editing Config, API Keys, Skills, MCP, Models, or Chat. The dashboard can manage multiple profiles, so the visible selected profile is part of the safety check.
• 💡Gateway processes are not magically absorbed by the profile switcher. Manage them explicitly with `hermes -p <name> gateway ...` and verify the exact Telegram or Discord target after dashboard checks pass.
• 💡Use `--isolated` only for deliberate per-profile dashboard servers. If you do not know why you need it, the unified machine dashboard is usually the safer default.
• 💡2026-07-06 evidence: dashboard queries already point to `/tools/hermes-web-ui`, so this guide supports that canonical page instead of creating duplicate dashboard content.
• 💡Fresh YouTube dashboard walkthroughs emphasize Sessions, Analytics, Logs, Cron Jobs, Skills, and Config; use those tabs as the default command-center checklist.
• 💡If you are comparing Hermes to Claude Code because you have too many terminal agents open, start in Web UI: inspect sessions, logs, cron jobs, skills, MCP, models, and gateway state before starting another shell.
• 💡If a teammate asks for Web UI because they want browser/mobile access and always-on channels, treat that as a FlyHermes decision rather than a reason to expose a self-hosted admin dashboard.
• 💡If the dashboard is being used to escape terminal-tab fatigue, name the goal first: which session, cron job, channel, provider, or MCP tool needs proof?
• 💡Dashboard data is strongest when paired with one external proof artifact: a delivered message, cron report, screenshot, or browser Chat response.

Troubleshooting

FAQ

Related setup and cost guides