Tool
Hermes Agent Dashboard & Web UI: Setup, Remote Access, and Monitoring
Open and secure the Hermes Agent dashboard, manage profiles, sessions, logs, cron jobs, skills, MCP tools, providers, and gateways, and choose between self-hosted Web UI and managed FlyHermes.
Quick answer
Run `hermes doctor && hermes dashboard`, then open `http://127.0.0.1:9119`. Use `hermes dashboard` for the backend plus browser UI and `hermes serve` for a headless remote-Desktop backend; choose one per port. On Linux, keep the chosen process alive with a systemd user service under the same Hermes account, enable lingering for boot startup, and run the messaging gateway separately. A non-loopback bind requires authentication. Use FlyHermes when you want managed browser/mobile access and channel uptime rather than operating this control plane.
Hermes Web UI is the browser control plane for a self-hosted Hermes installation. Use it to see which profile, provider, sessions, logs, schedules, tools, and gateways are actually active. Start locally on port 9119, keep the admin surface private, and use an end-to-end message or job delivery as the final proof that an agent workflow works. If Desktop will not open, a remote backend will not connect, WSL shows different state, or settings appear to change the wrong profile, the browser dashboard is the fastest way to isolate the runtime from the client surface.
Hermes Agent Web UI Dashboard – All Features Explained — BoxminingAI
Ron from BoxminingAI walks through the Hermes Agent web dashboard feature-by-feature. He shows how to launch it with `hermes dashboard`, access it via SSH tunnel from a VPS on port 9119, and use every major section: Sessions (including system cron messages), Analytics (token usage and per-model breakdown), Logs (for debugging failed cron jobs), Cron Jobs (create schedules with delivery to Discord/Telegram/email), Skills (browse all installed skills by category), and Config (fallback providers, gateway timeout, smart routing, memory, display, and auxiliary sub-agent settings).
- 0:00Introduction – live web dashboard overview
- 0:47Launching: `hermes dashboard` and port 9119
- 1:10VPS access via SSH tunnel (not direct link)
- 2:30Sessions tab – chat and system cron messages
- 4:10Analytics – API calls, token usage, per-model breakdown
- 5:00Logs – debug failed cron jobs
- 5:50Cron Jobs – create schedules and delivery targets
- 7:40Skills – browse installed skills by category
- 9:10Config – fallback providers, timeout, memory, routing, auxiliary
Setup steps
- 1Run `hermes doctor` and a one-query CLI smoke test before opening Web UI.
- 2Start locally with `hermes dashboard`; the default URL is `http://127.0.0.1:9119`.
- 3Use `--port`, `--no-open`, or `--skip-build` only for the specific port, headless, or prebuilt-frontend problem they solve.
- 4For a private VPS, keep the dashboard on loopback and use an SSH tunnel or VPN.
- 5For a required non-loopback bind, configure Basic Auth, Nous OAuth, or OIDC first; startup now fails closed without an auth provider.
- 6Check the selected profile, sessions, analytics, logs, cron jobs, skills, MCP, config, and gateway state in that order.
- 7Finish with one real browser Chat response, Telegram/Discord message, or cron delivery; dashboard status alone is not end-to-end proof.
Command map
hermes doctor && hermes dashboardVerify the installation and open the local dashboard on port 9119.
Fix CLI/provider/config failures before diagnosing Web UI.
hermes dashboard --port 9120 --no-openChoose another port and suppress browser launch on a server or SSH session.
A different port is not an access-control boundary.
ssh -L 9119:localhost:9119 user@your-vpsReach a loopback-only dashboard on a VPS without publishing the admin port.
Prefer a tunnel or VPN over a raw public bind.
hermes dashboard --statusList running dashboard processes before starting a duplicate server.
Dashboard process health does not prove gateway delivery.
hermes dashboard --stopStop running dashboard processes cleanly before changing bind, auth, or profile isolation.
This does not stop separately managed Telegram, Discord, or other gateway services.
hermes dashboard --isolatedRun a dedicated dashboard scoped to the named profile rather than the unified machine dashboard.
Use only when separate profile auth or network boundaries are intentional.
hermes dashboard register --name "My Hermes server"Register a self-hosted dashboard with Nous Portal when you want the OAuth login gate.
A public deployment still needs HTTPS, firewalling, and a deliberate auth configuration.
HERMES_DASHBOARD_PUBLIC_URL=https://dashboard.example.com hermes dashboard --host 0.0.0.0 --port 9119 --no-openRun an OAuth-registered dashboard behind Cloudflare Tunnel or another HTTPS reverse proxy with the correct callback authority.
Verify `/api/status` reports `auth_required: true`; Cloudflare Tunnel alone is not an authentication provider.
cd ~/.hermes/hermes-agent && uv pip install -e ".[web,pty]"Install the optional HTTP and PTY dependencies for Web UI and browser Chat from a source checkout.
On native Windows, use WSL2 for the PTY-backed Chat tab.
Run the dashboard persistently on Linux
Use a systemd user service under the same Linux account that owns Hermes and can access Docker. This private-by-default unit keeps Web UI on loopback; use an SSH tunnel or VPN for remote browser access.
[Unit]
Description=Hermes Agent Web Dashboard
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
WorkingDirectory=%h/.hermes/hermes-agent
EnvironmentFile=%h/.hermes/.env
Environment=PATH=%h/.local/bin:/usr/local/bin:/usr/bin:/bin
ExecStart=%h/.hermes/hermes-agent/venv/bin/python -m hermes_cli.main dashboard --host 127.0.0.1 --port 9119 --no-open --skip-build
Restart=on-failure
RestartSec=5
[Install]
WantedBy=default.target- 1Save the unit as `~/.config/systemd/user/hermes-dashboard.service`. If Hermes or its virtual environment lives elsewhere, replace `WorkingDirectory` and `ExecStart` with the real paths.
- 2As the same Hermes user, run `docker ps` first if the agent uses the Docker terminal backend. Fix group/socket access before starting the service; do not run the dashboard as root as a workaround.
- 3Run `systemctl --user daemon-reload && systemctl --user enable --now hermes-dashboard.service`, then `sudo loginctl enable-linger "$USER"` if it must start at boot before login.
- 4Verify `systemctl --user status hermes-dashboard.service`, `journalctl --user -u hermes-dashboard.service -n 100 --no-pager`, and `curl -s http://127.0.0.1:9119/api/status`.
- 5Keep the messaging gateway independent with `hermes gateway install` and `hermes gateway status`, then prove one real channel delivery. Tunnel port 9119 for remote browser access instead of publishing the admin port.
Self-hosted Web UI or FlyHermes?
Choose self-hosted Web UI
You want to own the runtime and inspect profiles, sessions, logs, schedules, tools, providers, and gateways inside a private admin boundary.
Avoid when: Your team wants managed browser/mobile access and always-on channels without server operations.
Choose Desktop with a remote backend
You want the native project, files, terminal, artifacts, and Git workspace while an always-on machine owns the Hermes runtime.
Avoid when: You only need browser administration, or nobody wants to maintain the remote host, authentication, updates, and WebSocket path.
Choose FlyHermes
You want browser/mobile chat, connected channels, managed uptime, and less VPS, provider-key, reverse-proxy, and gateway maintenance.
Avoid when: You specifically need to own and customize every part of the runtime.
Use both for diagnosis or migration
Keep Web UI as the self-hosted control-plane reference while moving production access or channel uptime to FlyHermes.
Avoid when: You are using the dashboard as an excuse to publish an unprotected admin port.
What you can verify
Features
- ✓v0.20 Desktop artifacts, plugin SDK, quick entry, and multiple-window workflows remain distinct from the self-hosted Web UI control surface
- ✓Machine-level profile switcher for Config, API Keys, Skills, MCP, Models, and Chat
- ✓Status overview for version, gateways, active sessions, and recent sessions
- ✓Sessions, analytics, token usage, logs, and resume controls
- ✓Cron job creation, run state, schedules, and delivery inspection
- ✓Skills, MCP catalog, tool selection, model, provider, and configuration management
- ✓Browser Chat powered by the real Hermes TUI over an authenticated PTY/WebSocket
- ✓Default localhost access on port 9119 with custom port and headless launch options
- ✓Fail-closed authentication for non-loopback binds using password, Nous OAuth, or OIDC
- ✓Unified machine dashboard by default, plus `--isolated` for intentional per-profile servers
- ✓Remote Hermes Desktop backend support through `hermes serve` or the dashboard server
- ✓Dashboard process controls with `--status` and `--stop`
- ✓Clear boundary: self-hosted operations in Web UI; managed browser/mobile/channel uptime in FlyHermes
Why this tool matters
The dashboard is for operating a Hermes installation, not merely viewing a chat transcript. It brings profile state, sessions, analytics, logs, cron jobs, skills, MCP tools, model/provider settings, and gateway status into one browser surface.
Treat Desktop, Web UI, and the backend as separate failure layers. If Desktop fails after an update but `hermes dashboard` opens, the core runtime is probably alive and the native client needs repair. If neither opens, start with `hermes doctor`, the provider smoke test, and current logs.
On WSL, browser reachability depends on where the dashboard process is bound and which environment owns `HERMES_HOME`. Native Windows and WSL are separate installations; a healthy dashboard with unexpected sessions or settings often means the browser reached the other runtime.
A remote Desktop status probe can pass while live Chat fails because Chat also needs authentication and a working WebSocket. Test the exact remote URL from Desktop, then open Web UI against the same backend and compare the selected profile before changing provider credentials.
Start with the active profile. Config, API Keys, Skills, MCP, Models, and Chat follow the profile switcher. Gateway services remain profile-specific, so verify the bot-owning profile with `hermes -p <name> gateway status` when a channel is silent.
Use Sessions and Logs to reconstruct what happened. Sessions include CLI, gateway, and scheduled runs; Logs expose provider, cron, and delivery failures that a green status card can hide.
Use Analytics to identify token and provider usage before changing models or fallbacks. Cost control is an operational workflow, not only a model-price comparison.
Use the Cron page to inspect schedules and delivery targets, but verify the actual destination. A job is not successful because it appears enabled; it is successful when its expected report or artifact arrives.
The browser Chat tab embeds the real TUI. It requires the web and PTY extras and belongs behind the same trusted boundary as API keys, logs, sessions, and configuration controls.
Localhost is the simplest secure default. For remote private access, use an SSH tunnel or VPN. If you bind to a non-loopback address, Hermes now requires a configured password, Nous OAuth, or OIDC provider and fails closed when none is available.
`--insecure` is retained only as a deprecated compatibility flag. It is a no-op and cannot be used to bypass dashboard authentication.
Use `--status` to find running dashboard processes and `--stop` before changing ports or auth. Use `--isolated` only when a named profile truly needs a dedicated server and separate exposure boundary.
Hermes Desktop remote mode normally connects to a headless `hermes serve` backend; `hermes dashboard` can expose the same backend plus Web UI. The public status probe is not enough: authentication, host binding, and the live WebSocket path must all succeed.
The self-hosted dashboard reduces terminal friction but does not own the server, HTTPS, authentication, backups, provider credentials, gateway uptime, or incident recovery.
FlyHermes is the managed path when the outcome is reliable browser/mobile use and connected channels rather than operating a private control plane.
When a session appears missing, use the Sessions view as orientation, then run `hermes sessions stats` and FTS5 session search before declaring corruption. The active session may be excluded from a picker and messaging views can be origin-scoped.
Desktop Remote Gateway normally uses `hermes serve` on port 9119; `hermes dashboard` can provide the same backend plus Web UI. OpenAI-compatible clients use the separate API server on port 8642, and each profile gateway still needs an end-to-end channel test.
A Cloudflare Tunnel or reverse proxy does not make the dashboard safe by itself. For a public hostname, register Nous OAuth (or configure OIDC), set `HERMES_DASHBOARD_PUBLIC_URL=https://dashboard.example.com`, run the dashboard on port 9119 with a non-loopback bind so the auth gate engages, and point the tunnel at that local origin. Verify `/api/status` reports `auth_required: true` before signing in.
When a channel is connected but silent, leave the dashboard open as context and run `hermes -p <name> gateway status --deep --full` from a normal terminal. Check for the wrong profile, stale child, or duplicate service, then prove recovery in the exact chat or thread.
Best use cases
How this fits with Hermes Agent
Daily operator check
Open the dashboard before trusting an always-on agent: confirm the active profile, provider, memory, skills, cron queue, gateway state, logs, and browser Chat boundary, then verify the real channel or job output that matters.
What the dashboard does
It helps operators inspect and manage local Hermes state: active profile, config, sessions, memory, skills, tools, cron jobs, model/provider state, logs, gateway health, and browser Chat when enabled.
What the dashboard does not do
It does not magically host Hermes, secure a VPS, keep Telegram/Discord online, pay provider bills, replace `hermes doctor`, or prove channel delivery without an end-to-end message test.
When to stop self-hosting the dashboard
If the team wants browser/mobile access, connected channels, bundled API costs, and uptime without owning Docker, nginx, secrets, and restarts, the dashboard is showing you a FlyHermes use case.
Local Hermes Web UI for solo operators
Run Hermes on your laptop, start hermes dashboard, and use WebUI to confirm configuration, memory, skills, tools, cron jobs, sessions, and channel health.
Gateway recovery checkpoint
When Telegram or Discord stops replying, open WebUI to confirm the active profile, provider state, gateway service, and recent cron/tool configuration before rotating tokens or rebuilding the bot.
Protected dashboard for VPS/self-hosting
Run WebUI on a server only behind a private/protected route. Pair it with Docker/VPS/security guides so the dashboard does not become a public admin panel.
Managed cloud chat with FlyHermes
Use FlyHermes when the actual need is browser chat, phone access, Telegram/Discord setup, and hosted uptime without Docker, nginx, provider keys, and gateway maintenance.
Integration debugging surface
When Telegram, Discord, GitHub, VS Code, or MCP tools behave oddly, WebUI gives a visual checkpoint before dropping into logs and CLI commands.
Search query to action map
Dashboard searchers usually need one concrete next step: open with `hermes dashboard`, change ports with `--port`, avoid browser launch with `--no-open`, and keep the admin surface private.
Reader checkpoint before changing config
Use WebUI to confirm the actual profile, provider, memory, skills, tools, cron jobs, and gateway state before editing `.env`, config.yaml, Docker mounts, or Telegram/Discord credentials.
Dashboard-to-proof workflow
Use Web UI to inspect the runtime layer, then validate the actual user-facing outcome: a Telegram reply, Discord thread response, delivered cron report, browser Chat response, or provider/API call. The dashboard narrows the failure layer; it is not the final proof by itself.
Team/mobile decision workflow
If someone asks for the dashboard because they need teammates, phone access, connected channels, and uptime, decide whether this is really a FlyHermes managed-cloud use case before adding reverse proxies, public ports, or shared self-hosted admin credentials.
Claude Code alternative command center
Use Web UI when a coding-agent workflow grows from one active terminal into multiple sessions, scheduled checks, provider decisions, and Telegram/Discord delivery. Use FlyHermes when that command center needs to be hosted and maintained for you.
Dashboard-to-delivery proof loop
Inspect profile, provider, logs, cron, MCP/tools, and gateway state in Web UI; then prove the exact workflow with a delivered Telegram/Discord reply, a cron report, or a browser Chat response. Report both checks, not only the dashboard view.
Terminal-tab fatigue loop
When several agents, cron jobs, and providers are running, use Web UI to manage sessions and logs by goal. If the operator still has to babysit uptime, provider credits, and channels, compare FlyHermes before adding more VPS complexity.
Session-loss triage
Confirm the selected profile, inspect Sessions and Logs, run `hermes sessions stats`, then search one exact phrase. Back up before `hermes sessions repair`; use `--check-only` first.
Cloudflare Tunnel with a custom dashboard hostname
Use port 9119 as the tunnel origin, register Nous OAuth for an internet-facing hostname, set the exact HTTPS public URL for callback construction, and confirm the dashboard advertises an active auth provider. Port 8642 is the optional OpenAI-compatible API server, not Web UI.
Gateway incident checkpoint
Use Web UI to confirm the selected profile, provider, sessions, and logs, then move to the gateway runbook for deep process status and an end-to-end channel test. A green card is not transport proof.
Related Hermes Agent guides
How to use the Hermes Web UI safely
Exact dashboard command, port flags, server workflow, and security checklist for WebUI.
Hermes Desktop install troubleshooting on Windows
Fix PATH, npm proxy, dependency, provider, loading-screen, and WSL2 issues before diagnosing the dashboard.
FlyHermes managed dashboard and cloud chat
Choose FlyHermes when you want the hosted browser chat workspace, mobile access, connected channels, and managed uptime.
Deploy Hermes Agent on a VPS
Use this with WebUI if you want a 24/7 self-hosted agent and understand the server maintenance cost.
Hermes Docker Compose setup
Run Hermes with Docker, then open the dashboard through a protected local or private route.
FAQ
Run `hermes doctor && hermes dashboard`, then open `http://127.0.0.1:9119`. Use `--port 9120` for a different port or `--no-open` on a headless server.
It manages and displays profiles, config, API keys, models, sessions, analytics, logs, cron jobs, skills, MCP, gateway status, and a browser Chat tab.
Yes. The default machine-level dashboard has a profile switcher. Config, API Keys, Skills, MCP, Models, and Chat follow the selected profile; gateways remain separately managed per profile.
It starts a dedicated server scoped to a named profile instead of attaching to the unified machine dashboard. Use it only when separate profile auth or network boundaries are intentional.
No. It is deprecated and now a no-op. Since the June 2026 hardening, every non-loopback bind requires a configured password or OAuth provider and fails closed without one.
Prefer a loopback bind with SSH tunneling or VPN access. If a non-loopback bind is required, configure Basic Auth, Nous OAuth, or OIDC, then add HTTPS and firewall restrictions.
Yes. The Chat tab embeds the real Hermes TUI behind a PTY/WebSocket when the web and PTY dependencies are installed. On native Windows, use WSL2 for the PTY-backed Chat tab.
No. It proves local control-plane state. The final proof is one real reply or delivery in the exact chat, topic, thread, email, or report destination.
Use `hermes dashboard --status` to list them and `hermes dashboard --stop` to stop them.
Run `hermes dashboard register` to register the self-hosted dashboard and save the OAuth client ID, then use the configured Nous Portal login gate for the deployment.
The status probe is less strict than the live WebSocket. Verify the dashboard is bound to a reachable host, authentication is configured, the Host header matches, and Desktop has signed in.
Build the frontend once from the Hermes source checkout, then use `--skip-build` or point `HERMES_WEB_DIST` at the built `hermes_cli/web_dist` directory.
No. Web UI is the self-hosted operations dashboard. FlyHermes is the managed cloud path for browser/mobile access, connected channels, and uptime without maintaining the runtime yourself.
Choose it when teammates need reliable browser/mobile access and connected channels but nobody wants to own VPS, authentication, HTTPS, provider keys, gateway restarts, and incident recovery.
No. Desktop Remote Gateway normally connects to the headless `hermes serve` backend on port 9119; `hermes dashboard` can provide the same backend plus Web UI. OpenAI-compatible clients use port 8642, which is a separate surface.
Yes, but the tunnel is transport, not authentication. For an internet-facing hostname, use Nous OAuth or OIDC, set `HERMES_DASHBOARD_PUBLIC_URL` to the exact HTTPS URL, run the dashboard on port 9119 with a non-loopback bind so the auth gate engages, and confirm `/api/status` reports `auth_required: true`. Do not expose ports 8642 or 8643 by mistake.