Summary
hermes dashboard only runs as a manual foreground process. On a headless server it dies on reboot (or when the shell session ends) and never comes back. The gateway has a service installer; the dashboard has nothing equivalent, so every headless deployment hand-rolls its own unit file.
Environment
- Headless Linux box (no desktop session), systemd
- Dashboard fronted over a Tailscale tailnet hostname
- Hermes version: verified on v0.18.0 (v2026.7.1) —
hermes dashboard --help still exposes no service-management flags.
Observed behavior
hermes dashboard starts the dashboard in the foreground and there is no supported way to install it as a managed service.- After a reboot, the gateway (installed as a service) comes back; the dashboard stays down until someone logs in and manually restarts it.
- The asymmetry is easy to miss: the box looks healthy (gateway up, agent responding) while the dashboard is silently dead.
Root cause (as diagnosed)
The dashboard simply lacks the service-installation path the gateway already has — there's no unit generator, no Restart= supervision, no boot-time enablement. It's a missing feature, not a bug in existing code.
Proposed fix
Add hermes dashboard --install-service, mirroring the gateway's installer:
- Generate and enable a systemd unit (
WantedBy=multi-user.target, Restart=always) running the dashboard with the user's configured host/port/auth options.
- Reuse the gateway installer's conventions (unit naming, user vs. system scope, log routing) so operators manage both services the same way.
- A matching
--uninstall-service would round it out.
Local workaround we run
A hand-rolled hermes-dashboard.service: WantedBy=multi-user.target, Restart=always, plus an OnFailure= hook wired to our alerting script so a crash pages us. It works, but it's exactly the boilerplate an --install-service flag should own — and it drifts from upstream defaults every time the dashboard's CLI flags change.
Summary
hermes dashboardonly runs as a manual foreground process. On a headless server it dies on reboot (or when the shell session ends) and never comes back. The gateway has a service installer; the dashboard has nothing equivalent, so every headless deployment hand-rolls its own unit file.Environment
hermes dashboard --helpstill exposes no service-management flags.Observed behavior
hermes dashboardstarts the dashboard in the foreground and there is no supported way to install it as a managed service.Root cause (as diagnosed)
The dashboard simply lacks the service-installation path the gateway already has — there's no unit generator, no
Restart=supervision, no boot-time enablement. It's a missing feature, not a bug in existing code.Proposed fix
Add
hermes dashboard --install-service, mirroring the gateway's installer:WantedBy=multi-user.target,Restart=always) running the dashboard with the user's configured host/port/auth options.--uninstall-servicewould round it out.Local workaround we run
A hand-rolled
hermes-dashboard.service:WantedBy=multi-user.target,Restart=always, plus anOnFailure=hook wired to our alerting script so a crash pages us. It works, but it's exactly the boilerplate an--install-serviceflag should own — and it drifts from upstream defaults every time the dashboard's CLI flags change.