Adds an optional dashboard side-process to the container entrypoint, toggled by HERMES_DASHBOARD=1 (also accepts true / yes). When set, the entrypoint backgrounds hermes dashboard before exec-ing the main command so the user's chosen foreground process (gateway, chat, sleep infinity, …) remains PID-of-interest for the container runtime.
docker run -d
-v ~/.hermes:/opt/data
-p 8642:8642 -p 9119:9119
-e HERMES_DASHBOARD=1
nousresearch/hermes-agent gateway run
Defaults chosen for the container case:

• Host: 0.0.0.0 (reachable through published port; can override to 127.0.0.1 via HERMES_DASHBOARD_HOST for sidecar/reverse-proxy setups)
• Port: 9119 (matches hermes dashboard)
• Auto-adds --insecure when binding to non-localhost, matching the dashboard's own safety gate for exposing API keys
• HERMES_DASHBOARD_TUI is read by hermes dashboard directly — no entrypoint plumbing needed Dashboard output is prefixed with [dashboard] via stdbuf+sed -u so it's easy to separate from gateway logs in docker logs. No supervision: if the dashboard crashes it stays down until the container restarts (documented in the :::note panel).
  Other changes bundled in:
• Deprecate GATEWAY_HEALTH_URL / GATEWAY_HEALTH_TIMEOUT env vars in hermes_cli/web_server.py with a DEPRECATED block comment and a .. deprecated:: note on _probe_gateway_health. The feature still works for this release; it'll be removed alongside the move to a first-class dashboard config key.
• Rewrite the "Running the dashboard" doc section around the new single-container pattern. Drops the previously-documented dashboard-as-its-own-container setup — that pattern relied on the deprecated env vars for cross-container gateway-liveness detection, and without them the dashboard would permanently report the gateway as "not running".
• Collapse the two-service Compose example (gateway + dashboard container) into a single service with HERMES_DASHBOARD=1. Removes the now-unnecessary bridge network and depends_on.
• Drop the ":::warning" caveat about "Running a dashboard container alongside the gateway is safe" — that case no longer exists.

What does this PR do?

Related Issue

Fixes #

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

How to Test

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform:

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

For New Skills

• This skill is broadly useful to most users (if bundled) — see Contributing Guide
• SKILL.md follows the standard format (frontmatter, trigger conditions, steps, pitfalls)
• No external dependencies that aren't already available (prefer stdlib, curl, existing Hermes tools)
• I've tested the skill end-to-end: hermes --toolsets skills -q "Use the X skill to do Y"

Screenshots / Logs