Problem
The Hermes dashboard is not auto-started with the gateway - it runs as a separate process. After WSL restarts or gateway crashes, the dashboard becomes unavailable until manually restarted.
Context
In WSL environments with multiple boot cycles (e.g., after Windows updates, hibernation, or manual WSL restarts), the dashboard process dies and does not come back up. The gateway survives via systemd, but the dashboard does not.
Proposed Solution
Create a separate systemd service for the dashboard that starts after the gateway:
[Unit]
Description=Hermes Agent Dashboard
After=hermes-gateway.service
Wants=hermes-gateway.service
[Service]
Type=simple
User=<hermes_user>
Group=<hermes_user>
ExecStart=<venv_path>/python3 <hermes_path>/hermes dashboard --host 0.0.0.0 --no-open --insecure
WorkingDirectory=<hermes_agent_dir>
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
Benefits
- Dashboard survives WSL restarts and gateway crashes
- Persistent access to http://127.0.0.1:9119/sessions without manual intervention
- Consistent behavior with gateway autostart behavior
Note
The --insecure flag is required when binding to 0.0.0.0. In trusted home networks this is acceptable. Alternatively, the dashboard could bind to localhost only if mirrored networking is available
Problem
The Hermes dashboard is not auto-started with the gateway - it runs as a separate process. After WSL restarts or gateway crashes, the dashboard becomes unavailable until manually restarted.
Context
In WSL environments with multiple boot cycles (e.g., after Windows updates, hibernation, or manual WSL restarts), the dashboard process dies and does not come back up. The gateway survives via systemd, but the dashboard does not.
Proposed Solution
Create a separate systemd service for the dashboard that starts after the gateway:
Benefits
Note
The
--insecureflag is required when binding to 0.0.0.0. In trusted home networks this is acceptable. Alternatively, the dashboard could bind to localhost only if mirrored networking is available