Souveräne KI im Heimnetz: Das Hermes Agent Dashboard sicher als systemd-Service betreiben

Mein Hermes Agent läuft seit mehreren Wochen produktiv auf meinem Applikation-Server: als Telegram-Gateway, mit angebundenem MCP-Server für GPU-Monitoring und mit ein paar Cron-Jobs für tägliche Hintergrundaufgaben. Konfiguriert habe ich bisher alles über die CLI und direkt in der ~/.hermes/config.yaml. Das funktioniert wunderbar, ist aber nicht immer der schnellste Weg. Besser ist da schon ein Web-Dashboard wenn ich kurz eine alte Session durchsuchen, die Token-Analytics anschauen oder mal eben einen neuen Cron-Job anlegen möchte.

Seit einem der letzten Updates bringt Hermes ein vollständiges Web-Dashboard mit. Per Default bindet es allerdings nur an 127.0.0.1 und muss manuell gestartet werden. Ich will das Dashboard aber aufrufen können von ganz unterschiedlichen Geräten in meinem Netzwerk. In diesem Beitrag zeige ich euch, wie ich das Hermes Agent Dashboard als systemd-Service unter Ubuntu eingerichtet habe. Fehlen darf uch nicht eine gewisse Absicherung, die ihr unbedingt braucht, weil das Dashboard von Haus aus keine eigene Authentifizierung hat.

Was bietet das Dashboard?

Bevor wir loslegen, ein kurzer Überblick, was das Dashboard tatsächlich liefert:

• Status – Live-Ansicht von Agent-Version, Gateway-Status, verbundene Plattformen und aktiven Sessions
• Chat – der komplette Hermes-TUI direkt im Browser (optional, benötigt ptyprocess)
• Config – formularbasierter Editor für die config.yaml mit allen 150+ Feldern
• API Keys – Verwaltung der .env-Datei mit allen Provider-Keys
• Sessions – Volltextsuche über alle bisherigen Konversationen mit FTS5
• Logs – Live-Tailing von Agent-, Gateway- und Error-Logs mit Filtern
• Analytics – Token-Verbrauch und geschätzte Kosten pro Tag und Modell
• Cron – UI für scheduled Jobs ohne Crontab-Editing
• Skills – Aktivieren und Deaktivieren einzelner Skills und Toolsets

Besonders die Volltextsuche über alle Sessions ist für mich wichtig, denn so finde ich Codeschnipsel und Setup-Notizen aus Konversationen wieder, die schon Monate zurückliegen.

Voraussetzungen

• Ubuntu 24.04 LTS oder vergleichbar, mit aktivem systemd
• Hermes Agent v0.6.0 oder neuer
• Python 3.12 – Standard unter Ubuntu 24.04
• Node.js, falls ihr den Chat-Tab im Browser nutzen wollt
• UFW für die Firewall-Absicherung

Schritt 1: Web-Extras installieren

Die Default-Installation von Hermes bringt den HTTP-Stack nicht mit. Diesen HTTP-Stack braucht ihr extra. Ich habe folgende Befehle ausgeführt um alles in die Hermes eigene virtuelle Umgebung zu installieren.

Befehl: cd ~/.hermes/hermes-agent
Befehl: source venv/bin/activate
Befehl: uv pip install -e ".[web,pty]"
Befehl: deactivate

Jetzt sollte alles vorbereitet sein. Für einen schnellen Funktionstest starte ich das Dashboard direkt mit Netzwerk-Binding, damit ich auch von meinem Client-Rechner aus zugreifen kann:

Befehl: hermes dashboard --host 0.0.0.0 --port 9119 --no-open --insecure

Das --no-open verhindert, dass der headless laufende Server versucht einen Browser zu öffnen. Das --insecure ist kein echter Sicherheits-Schalter, sondern eine bewusste Bestätigung von Hermes selbst: „ja, ich weiß, dass ich nicht nur auf localhost binde“ — sobald ihr --host 0.0.0.0 setzt, ist das Flag Pflicht.

Im Browser auf eurem Client öffnet ihr jetzt http://<server-ip>:9119 und solltet das Dashboard sehen. Bei mir sieht das so aus:

Hermes-Agent – WEB Dashbaord

Stoppt den Test wieder mit CTRL+C im SSH-Terminal. Jetzt möchte ich das Dashboard so einrichten, dass es sauber als systemd-Service im Hintergrund läuft und ich es jederzeit aufrufen kann.

Schritt 2: systemd-Service anlegen

Jetzt der zentrale Teil. Erstellt eine neue Service-Datei:

Befehl: sudo nano /etc/systemd/system/hermes-dashboard.service

Jetzt bitte die nachfolgende Service-Programmierung einfügen und die Datei abspeichern.

[Unit]
Description=Hermes Agent Web Dashboard
After=network.target
Wants=network-online.target

[Service]
Type=simple
User=ingmar
Group=ingmar
Environment="HOME=/home/ingmar"
WorkingDirectory=/home/ingmar/.hermes/hermes-agent
ExecStart=/home/ingmar/.hermes/hermes-agent/venv/bin/hermes dashboard --host 0.0.0.0 --port 9119 --no-open --insecure
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Vier Punkte sind hier wichtig:

1. --host 0.0.0.0 bindet auf alle Netzwerk-Interfaces – nur dadurch wird das Dashboard im LAN für alle Geräte erreichbar.
2. --port 9119 ist der Default-Port von Hermes für das Dashboard. Wenn der Port bei euch schon belegt ist (z.B. durch einen anderen lokalen Dienst), wählt einen freien Port – z.B. --port 8119.
3. --insecure ist zwingend erforderlich, sobald ihr nicht mehr das Hermes Agent Dashboard auf die lokale IP 127.0.0.1 bindet. Das Flag bestätigt explizit, dass ihr die Risiken kennt.
4. Pfad zum hermes-Binary zeigt direkt in das Hermes-eigene Venv unter ~/.hermes/hermes-agent/venv/bin/hermes. So umgeht systemd den Launcher-Umweg über ~/.local/bin/ und es kann nichts schiefgehen, falls der PATH des Service-Accounts minimal ist. Mit ls -la ~/.hermes/hermes-agent/venv/bin/hermes verifiziert ihr den Pfad vor dem ersten Start.

Jetzt müssen wir den neu angeleten Service aktivieren und starten:

Befehl: sudo systemctl daemon-reload

Befehl: sudo systemctl enable --now hermes-dashboard

Befehl: sudo systemctl status hermes-dashboard

Wenn der Status grün ist, läuft das Dashboard und ist von jedem Rechner im Netz erreichbar. Genau das ist sowohl Feature als auch Problem.

Hermes-Agent – WEB Dashbaord service status

Schritt 3: Mit UFW auf das eigene LAN beschränken

Das Dashboard liest und schreibt die .env-Datei mit allen API-Keys. Jeder mit Netzwerkzugriff auf Port 9119 hätte vollen Zugriff darauf. Mein Minimum-Schutz: den Port nur für mein internes Subnet freigeben.

Command: sudo ufw allow from 192.168.2.0/24 to any port 9119 proto tcp

Command: sudo ufw reload

Ersetzt 192.168.2.0/24 durch euer eigenes LAN-Subnet. Damit kommt aus dem Internet niemand mehr durch, selbst wenn euer Router fehlkonfiguriert wäre.

Logs prüfen

Wenn etwas hakt, hilft ein Blick ins systemd-Journal:

Befehl: journalctl -u hermes-dashboard -f

Mein persönliches Fazit

Das Dashboard ist genau der Komfort-Layer, den ein aktiv eingesetzter Hermes-Agent gebraucht hat. Die Volltextsuche über meine Sessions hat sich allein nach drei Tagen schon mehrfach bezahlt gemacht. Ich finde damit Snippets und Setup-Notizen aus Konversationen wieder, die ich sonst manuell hätte zusammenkratzen müssen. Auch die Analytics sind aufschlussreich: ich sehe genau, wie viele Tokens meine Modelle pro Tag eingehend und ausgehend erzeugen. Bei einer Cloud-Lösung wäre das die Stelle an der die Kosten überwacht werden können um die monatliche Rechnung mit der vom Service Anbieter gestellten abgleichen zu können. Bei mir landet das in einer Zahl auf der Token-Bilanz, bezahlen muss ich zum Glück nichts. Die GPUs hängen an der Solaranlage und ziehen die paar Kilo-Watt aus der PV-Anlage bzw. dem Speicher wenn die Sonne scheint. Das ist natürlich ab Ende Oktober bis Ende März in Deutschland schwierig.

Die einzige Hürde war für mich die fehlende Authentifizierung. Das ist eine bewusste Designentscheidung denn Hermes Agent ist als lokales Entwickler-Werkzeug gedacht aber sobald ihr es ins LAN exposed, müsst ihr selbst dafür sorgen. Ein nginx mit Basic Auth ist dabei der pragmatische Mittelweg zwischen „läuft auf 0.0.0.0 und alles ist offen“ und „ich schicke meine Verbindungsmetadaten in eine Cloud-VPN-Lösung“.

Für mich ist das genau das Setup, das zu souveräner KI im Heimnetz passt: alles bleibt lokal, niemand braucht ein Cloud-Konto, und trotzdem habe ich die gleiche Bedienkomfort wie bei jeder SaaS-Lösung.

Viel Spaß beim Einrichten!