Local-First Hermes Dashboard Operations

The Hermes dashboard provides browser-based access to configuration, sessions, logs, analytics, cron jobs, profiles, skills, MCP connections, models, and chat. Its safest default is local: hermes dashboard binds to localhost and keeps the management surface on the machine.

Official documentation: https://hermes-agent.nousresearch.com/docs/user-guide/features/web-dashboard

Daily operator checklist

  • [ ] Start on the default loopback address unless remote access is intentional.
  • [ ] Confirm the active profile before changing config, skills, models, or keys.
  • [ ] Read the profile banner and URL profile parameter before saving.
  • [ ] Treat the API Keys page as a secret-management surface.
  • [ ] Use Sessions and Logs to investigate before changing configuration.
  • [ ] Confirm changes in a fresh agent session or after the required gateway restart.
  • [ ] Keep gateway processes separate from the dashboard process.
  • [ ] Stop temporary dashboard instances when finished.

Multi-profile write safety

A machine-level dashboard can manage several profiles. The profile switcher determines which profile most management pages read and write. Chat also runs with the selected profile's home, model, skills, memory, and sessions. Before any edit, confirm the selected profile; a polished UI does not eliminate cross-profile risk.

Remote access is a separate security decision

Binding beyond localhost can expose configuration and credentials. Do not use an insecure network bind as a shortcut. A remote dashboard should use strong authentication, a protected network path, and explicit verification of both HTTP status and authenticated WebSocket chat—not just a public readiness endpoint.

Pitfalls

  • Assuming a profile alias launches an entirely unrelated machine dashboard.
  • Editing the wrong profile after following an old deep link.
  • Exposing the dashboard on 0.0.0.0 without strong authentication and network controls.
  • Treating the dashboard as the messaging gateway; they are separate processes.
  • Expecting config changes to rewrite an already-running session's prompt state.
  • Sharing screenshots that reveal API-key names, session content, or private logs.

Verification steps

  • Open the local dashboard and confirm the expected profile banner.
  • Check Status, Sessions, and Logs without making changes.
  • Make one reversible test setting in the intended profile.
  • Start a fresh session and confirm the setting applies there.
  • If remote access is configured, verify authentication and chat connectivity from the intended client.
  • Confirm the dashboard is not reachable from networks that should not have access.