Hermes Agent Dashboard and Web UI: Self-Hosted AI Agent Command Center

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.

Yes, for self-hosted Hermes operators. It is the private command center for sessions, analytics, logs, cron jobs, skills, MCP, config, gateway health, and browser Chat. It is not the same as a hosted team/mobile SaaS workspace; use FlyHermes for managed browser/mobile access and uptime.

It should prove which layer is healthy or broken: selected profile, model/provider, memory, skills, MCP tools, cron schedule, logs, gateway state, or browser Chat. For Telegram, Discord, and cron jobs, the final proof is still a real delivered message or report outside the dashboard.

Check the active profile, provider, memory, skills, tools, cron jobs, logs, sessions, and gateway health first. Then verify the real output path — a Telegram/Discord reply, a cron delivery, a command result, or browser Chat response — because a healthy dashboard alone does not prove every channel works.

It shows and manages local Hermes operational state: configuration, active profile, model/provider status, memory, skills, tools, cron jobs, sessions, and gateway health.

It does not remove the need to run Hermes somewhere, secure the dashboard, maintain provider keys, restart gateways, or verify Telegram/Discord end-to-end. It is an admin dashboard, not a complete managed hosted agent product.

No. The self-hosted Hermes Web UI/dashboard is for local configuration and monitoring. FlyHermes is the hosted cloud experience for browser chat, mobile access, connected channels, managed uptime, and less VPS/Docker/provider maintenance.

Do not expose it raw to the internet. Keep it on localhost, behind an SSH tunnel, VPN, or a hardened reverse proxy with authentication.

Check the active profile, provider/model state, gateway status, tool availability, cron jobs, and recent service health, then confirm with hermes gateway status and a real message in the target chat.

Start the dashboard on localhost, confirm the active profile and provider, check memory/tools/cron/gateway status, then send one real Telegram or Discord message if a gateway is involved. Do not expose the dashboard publicly until access control is designed.

Run `hermes dashboard`. If the default port is busy, run `hermes dashboard --port 9120`. On a VPS or SSH session, run `hermes dashboard --no-open` and reach it only through a trusted private path.

The dashboard can show local state, but gateway delivery also depends on platform permissions, topic/thread routing, allowlists, provider credits, and the live gateway process. Always test the exact chat or channel.

Yes. After Desktop connects to a remote runtime, open the backend Web UI privately and confirm the active profile, provider, model, tools, memory, skills, cron jobs, sessions, and gateway status.

Yes, when the dashboard has the web and PTY dependencies available. The Chat tab runs the real Hermes TUI behind a PTY/WebSocket, so it is a self-hosted browser view into your local/server runtime, not managed cloud chat.

That error means Hermes code is out of date or the gateway process is running old in-memory modules after a Hermes update. The Discord adapter started, but a gateway turn called a method that no longer exists in the installed version. Fix it by updating Hermes, then hard-restarting the gateway process (not just /restart from inside the gateway — kill and restart the actual service/process).

Yes. Hermes Agent includes a self-hosted Dashboard/Web UI for configuration, sessions, memory, skills, tools, cron jobs, logs, and gateway health. It is an operations/admin surface, not a managed hosted workspace by itself.

Only behind strong access control. Keep it on localhost when possible, or use an SSH tunnel, VPN, firewall rules, HTTPS, and authentication. Do not expose a raw dashboard port to the public internet.

Dashboard Chat is a self-hosted browser view into your own Hermes runtime when the Web UI/TUI dependencies are installed. FlyHermes is the managed cloud experience for browser/mobile access, connected channels, and uptime without maintaining the runtime yourself.

By default the dashboard opens on localhost port 9119. Use `hermes dashboard --port 9120` or another free port when 9119 is occupied.

Use `--no-open` on servers, SSH sessions, Docker/VPS deployments, and cron-like environments where opening a local browser is wrong. Pair it with a private tunnel or protected reverse proxy, not a raw public port.

On macOS and launchd-style contexts, Hermes may run with a reduced PATH. Verify Node/npm from the shell, build the frontend once in the Hermes source checkout if needed, or point `HERMES_WEB_DIST` at the existing built assets.

Run `hermes dashboard` after the CLI is installed and `hermes doctor` passes. The dashboard opens on localhost by default.

The default dashboard port is 9119. Use `hermes dashboard --port 9120` or another open port if 9119 is already in use.

Choose self-hosted Web UI when you want to operate your own Hermes runtime. Choose FlyHermes when you want hosted browser/mobile chat, connected channels, bundled API costs, and managed uptime without running a VPS or gateway stack.

On a VPS you cannot click the link directly — it will show 'site can't be reached.' Instead, open your local terminal (or PowerShell on Windows) and create an SSH tunnel: `ssh -L 9119:localhost:9119 your-vps-user@your-vps-ip`. Once the tunnel is active, click the localhost:9119 link and the dashboard will load.

The Sessions tab shows both your chat conversations with Hermes and system messages — notifications from the Hermes agent system itself. System messages include cron job invocations, delivery confirmations, and error notifications. This makes it the go-to view for tracing what the agent did and when, especially for debugging cron job failures.

The Analytics tab shows total API call counts, total tokens consumed, a day-by-day usage graph (filterable by 7 days or 90 days), and a per-model breakdown. The per-model breakdown is especially useful when you switch providers mid-session — it tells you which models are consuming the most budget so you can optimize your fallback configuration.

Yes. In the Cron Jobs tab, give the cron a name, describe what the agent should do on each run, set the schedule using cron syntax (e.g., `0 9 * * *` for 9 a.m. daily), and choose the delivery target: local, Discord, Telegram, or email. The dashboard writes the config for you without requiring any terminal edits.

The Logs tab is the primary place to debug failed scheduled tasks. When a cron job fails — for example due to a Discord API issue — the log shows the exact failure message. You can copy that message and paste it directly into a chat with your Hermes agent asking it to diagnose and fix the problem.

Fallback Providers let you add a backup API key and provider so Hermes automatically switches when your primary provider hits usage limits or goes down. For example, if you are on the Claude plan and run out of tokens, you can configure a fallback like MiniMax or another provider so the agent keeps working.

The default gateway timeout is 1800 seconds. Some users see their agent silently fail to respond or time out without an error, especially on slow providers or long tasks. Increasing this value gives Hermes more time to complete a response before the gateway cuts the connection.

The Auxiliary section configures the provider, model, base URL, API key, and timeout for sub-agents that Hermes spawns. If you want the orchestrating agent and its sub-agents to use different models or providers, this is where you set that up.

Open the active profile, provider/model, fallback providers, usage/analytics, gateway timeout, memory, tools, cron jobs, and recent logs. If a provider hit 402/429 or a fallback is misconfigured, the dashboard can show the control-plane state, but you should still run a small CLI or channel smoke test afterward.

Long-running agents fail in layers: provider credits, model routing, cron schedule, gateway process, allowed chat/thread IDs, logs, and server uptime. The dashboard gives one browser place to inspect those layers before you rotate tokens, rebuild Docker, or expose the service publicly.

Current Hermes docs describe it as a machine-level management surface. One dashboard server can manage multiple profiles through the sidebar profile switcher; Config, API Keys, Skills, MCP, Models, and Chat follow the selected profile.

Use `--isolated` only when you deliberately want a dedicated server scoped to one profile, for example when different profiles need different authentication or network exposure. For normal local work, use the unified machine dashboard and switch profiles inside it.

The Web Dashboard needs the Hermes web extra. The Chat tab also needs PTY support so Hermes can spawn the embedded TUI behind a pseudo-terminal; on native Windows, use WSL2 for PTY-backed Chat.