seb/hermes-agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(dashboard): document machine-level multi-profile management

Browse Source 
- web-dashboard.md: 'Managing multiple profiles' section (switcher, URL
  deep-links, unified launch, --isolated, scoped Chat, what stays
  per-profile) + --isolated in the options table
- profiles.md: 'From the dashboard' subsection + set-as-active vs
  switcher clarification
- cli-commands.md: --isolated flag + profile-alias launch example
This commit is contained in:
Teknium
2026-06-10 22:06:29 -07:00
parent f02302738d
commit e600f69515
3 changed files with 57 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
website/docs/user-guide/features/web-dashboard.md
+38
View File
@@ -28,6 +28,7 @@ This starts a local web server and opens `http://127.0.0.1:9119` in your browser
| `--host` | `127.0.0.1` | Bind address |
| `--no-open` | — | Don't auto-open the browser |
| `--insecure` | off | Allow binding to non-localhost hosts (**DANGEROUS** — exposes API keys on the network; pair with a firewall and strong auth) |
| `--isolated` | off | When launched from a named profile (`worker dashboard`), run a dedicated per-profile server instead of routing to the machine dashboard |
```bash
# Custom port
@@ -40,6 +41,43 @@ hermes dashboard --host 0.0.0.0
hermes dashboard --no-open
```
## Managing multiple profiles
The dashboard is a **machine-level** management surface: one server manages
every [profile](../profiles.md) on the machine. A profile switcher in the
sidebar (visible whenever more than one profile exists) decides which
profile the management pages read and write — Config, API Keys, Skills,
MCP, Models, and the Chat tab all follow it. While a profile other than
the dashboard's own is selected, an amber banner names the managed profile
so the write target is never ambiguous.
The selection lives in the URL (`?profile=<name>`), so deep links like
`http://127.0.0.1:9119/skills?profile=worker` land with the switcher
preselected and survive refresh.
Launching the dashboard from a profile alias routes to the machine
dashboard instead of starting a second server:
```bash
worker dashboard
# → already running: opens the browser at ?profile=worker
# → not running: starts the machine dashboard with "worker" preselected
```
Pass `--isolated` to opt out and run a dedicated server scoped to that
profile (the pre-unification behavior — useful if you deliberately expose
different profiles' dashboards with different auth).
The **Chat** tab follows the switcher too: a scoped chat spawns its PTY
child with the selected profile's `HERMES_HOME`, so the conversation runs
with that profile's model, skills, memory, and session history. Switching
profiles starts a fresh terminal session.
What stays per-profile and is *not* absorbed by the switcher: gateway
processes (manage them via `hermes -p <name> gateway …`), each profile's
session database, and cron schedulers (the Cron page already aggregates
across profiles with its own filter).
## Prerequisites
The default `hermes-agent` install does not ship the HTTP stack or PTY helper — those are optional extras. The **web dashboard** needs FastAPI and Uvicorn (`web` extra). The **Chat** tab also needs `ptyprocess` to spawn the embedded TUI behind a pseudo-terminal (`pty` extra on POSIX). Install both with: