---
title: "Hermes Agent Dashboard einrichten: SSH, Caddy, Docker & Security (2026)"
description: "Betreibe das Hermes-Agent-Web-Dashboard auf deinem VPS mit SSH-Tunneling, Caddy-Reverse-Proxy, Docker oder systemd."
date: 2026-04-14
categories: ["ai"]
tags: ["ai-tools","self-hosted","vps"]
---

Wenn du [Hermes Agent](/hermes-agent-setup-guide/) auf einem VPS fährst und eine browserbasierte Möglichkeit willst, Sessions, API-Keys, Gedächtnis und Konfiguration zu verwalten, macht das eingebaute Dashboard genau das. Seit v0.16 (Juni 2026) kommt das Dashboard als natives Browser-Admin-Panel. Es ist nur einen Befehl entfernt, lauscht aber standardmäßig nur auf localhost. Dieser Guide deckt ab, wie du es lokal laufen lässt, remote per SSH-Tunnel oder über einen Caddy-Reverse-Proxy mit Passwortschutz erreichst, in Docker deployst und mit systemd dauerhaft laufen lässt.

[Hermes Agent GitHub](https://github.com/NousResearch/hermes-agent)

**Was dieser Guide abdeckt**

- Das Hermes-Dashboard lokal und auf einem Remote-Server starten

- Remote-Zugriff via SSH-Port-Forwarding (am einfachsten und sichersten)

- Es extern mit einem Caddy-Reverse-Proxy exponieren

- Basic Auth mit Benutzername und Passwort hinzufügen

- Es dauerhaft mit systemd oder Docker laufen lassen

- Sicherheitsrisiken, die du kennen solltest

## Was das Hermes-Dashboard kann

Video: [Hermes v0.9.0 Just Got a Game-Changing Web Dashboard](https://www.youtube.com/embed/1WaASFqQHgg)

Das Dashboard gibt dir eine Browser-Oberfläche zur Verwaltung deiner Hermes-Agent-Instanz. Darüber kannst du:

- Aktive Chat-Sessions ansehen und verwalten
- Gedächtnis-Dateien des Agenten durchsuchen und bearbeiten
- API-Keys und Modell-Einstellungen konfigurieren
- Token-Nutzung und Kosten überwachen
- Skills und Tool-Konfigurationen verwalten

Es verbindet sich mit dem bestehenden Hermes-Gateway-Prozess, der schon auf deinem Server läuft – es startet keinen zweiten Agenten.

## Dashboard-Tour

Sobald das Dashboard läuft, gibt dir die obere Navigationsleiste Zugriff auf mehrere Tabs. Das zeigt jeder einzelne.

### Status

Der Status-Tab ist die Landing Page. Er zeigt, ob Agent und Gateway laufen, verbundene Plattformen und eine Liste der letzten Sessions mit Nachrichtenzahlen und Vorschauen.

![Hermes-Dashboard-Statusseite mit Agent-Health, Gateway-Status, verbundenen Plattformen und letzten Sessions](@assets/images/26/04/hermes-dash-status.webp)

### Sessions

Der Sessions-Tab listet alle vergangenen und aktiven Sessions. Jeder Eintrag zeigt das genutzte Modell, die Nachrichtenzahl, aufgerufene Tools und wann er zuletzt aktiv war. Du kannst Nachrichteninhalte über alle Sessions hinweg durchsuchen und alte löschen.

![Hermes-Dashboard-Sessions-Seite mit 51 Sessions, Suche, Nachrichtenzahlen und Session-Typen](@assets/images/26/04/hermes-dash-sessionsjpeg.webp)

### Analytics

Der Analytics-Tab trackt Token-Nutzung, Session-Anzahlen und API-Aufrufe über die Zeit. Er zeigt Tagesaufschlüsselungen und Statistiken pro Modell, damit du exakt siehst, wie viel dich dein Agent kostet.

![Hermes-Dashboard-Analytics-Seite mit Gesamt-Tokens, täglichem Nutzungs-Chart und Aufschlüsselung pro Modell](@assets/images/26/04/hermes-dash-analytics.webp)

### Cron

Der Cron-Tab lässt dich geplante Tasks erstellen und verwalten. Du definierst einen Prompt, setzt einen Cron-Ausdruck und wählst, wohin Ergebnisse geliefert werden (lokal, Discord usw.). Du kannst Jobs von hier pausieren, manuell triggern oder löschen.

![Hermes-Dashboard-Cron-Seite mit Job-Erstellungsformular und einem geplanten täglichen Tech-News-Scout-Job](@assets/images/26/04/hermes-dash-jobs.webp)

### Config

Der Config-Tab gibt dir einen strukturierten Editor für `~/.hermes/config.yaml`. Er ist nach Abschnitten organisiert – General, Agent, Terminal, Display, Memory, Security und mehr – jeweils mit beschrifteten Feldern. Du kannst Werte direkt bearbeiten oder in den Raw-YAML-Modus wechseln.

![Hermes-Dashboard-Config-Seite mit General-Einstellungen inklusive Modell, Zeitzone und Command-Allowlist](@assets/images/26/04/hermes-dash-config.webp)

### Keys

Der Keys-Tab verwaltet API-Keys und OAuth-Logins, die in `~/.hermes/.env` gespeichert sind. Er zeigt, welche LLM-Provider konfiguriert sind, behandelt OAuth-Flows (Nous Portal, OpenAI Codex) und lässt dich Credentials hinzufügen oder trennen, ohne die Kommandozeile anzufassen.

![Hermes-Dashboard-Keys-Seite mit OAuth-Provider-Verbindungen und LLM-Provider-API-Key-Verwaltung](@assets/images/26/04/hermes-dash-keys.webp)

## Das Dashboard starten

Der einfachste Weg zum Starten:

```bash
hermes dashboard
```

Das baut die Web-UI (nur beim ersten Lauf) und startet dann einen Server auf `http://127.0.0.1:9119`. Es öffnet außerdem einen Browser-Tab, wenn du es lokal laufen lässt.

### Verfügbare Flags

| Flag | Default | Beschreibung |
|---|---|---|
| `--host` | `127.0.0.1` | Interface, an das gebunden wird |
| `--port` | `9119` | Port, auf dem gelauscht wird |
| `--no-open` | off | Automatischen Browser-Start überspringen |

Das Default-Binding auf `127.0.0.1` heißt, nur deine Maschine erreicht das Dashboard. Das ist der sichere Default – wenn du Remote-Zugriff brauchst, lies weiter.

## Remote-Zugriff via SSH-Port-Forwarding

Wenn du das Dashboard nur von deinem Laptop aus öffnen willst, während es auf einem VPS läuft, ist SSH-Port-Forwarding die einfachste Option. Kein Reverse Proxy, kein DNS, keine offenen Ports auf dem Server – alles läuft durch deine bestehende SSH-Verbindung.

```bash
ssh -L 9119:127.0.0.1:9119 user@your-vps-ip
```

Öffne dann `http://127.0.0.1:9119` im Browser auf deinem Laptop. Das `-L`-Flag leitet deinen lokalen Port 9119 durch den SSH-Tunnel an das localhost:9119 des VPS weiter. Für das Dashboard sieht das wie eine lokale Verbindung aus.

Das ist der sicherste Weg für Remote-Zugriff auf das Dashboard, weil:

- Das Dashboard an `127.0.0.1` gebunden bleibt – nichts anderes im Internet erreicht es
- Der Traffic innerhalb von SSH verschlüsselt ist – kein extra TLS-Setup nötig
- Du schon SSH-Zugriff hast, es gibt also nichts Neues abzusichern
- Keine offenen Ports auf dem VPS außer SSH

**Wann du SSH-Forwarding nutzen solltest**

Nutze das, wenn du die einzige Person bist, die auf das Dashboard zugreift, und du dich immer von einer Maschine mit SSH-Zugriff verbindest. Überspringe die Caddy- und systemd-Abschnitte komplett – lass einfach hermes dashboard in einer tmux- oder screen-Session laufen.

### SSH-Tunnel im Hintergrund

Wenn der Tunnel im Hintergrund offen bleiben soll:

```bash
ssh -f -N -L 9119:127.0.0.1:9119 user@your-vps-ip
```

- `-f` — forkt nach der Authentifizierung in den Hintergrund
- `-N` — kein Remote-Befehl, nur der Tunnel

Um ihn später zu killen:

```bash
# Find the process
ps aux | grep "ssh -f -N -L 9119"

# Kill it
kill <PID>
```

### Dashboard auf dem VPS laufen lassen

Mit SSH-Forwarding muss das Dashboard weiterhin auf dem VPS laufen. Nutze tmux oder screen, damit es SSH-Trennungen überlebt:

```bash
# On the VPS
tmux new -s hermes
hermes dashboard
# Ctrl+B then D to detach

# Later, reattach with
tmux attach -t hermes
```

Wenn es dauerhaft laufen soll – auch ganz ohne SSH – nutze den weiter unten beschriebenen systemd-Service.

## Das Dashboard extern verfügbar machen

Um das Dashboard von einer anderen Maschine zu erreichen (deinem Handy, deinem Laptop oder einem Teamkollegen), brauchst du zwei Dinge: an alle Interfaces binden und einen Reverse Proxy davor.

### Schritt 1: An 0.0.0.0 binden

```bash
hermes dashboard --host 0.0.0.0
```

Das lässt den Server auf allen Netzwerk-Interfaces lauschen. Für sich genommen heißt das: Jeder, der die IP deines Servers erreichen kann, kommt ans Dashboard – hör hier nicht auf.

### Schritt 2: Reverse Proxy mit Caddy

Wenn du Caddy schon als Reverse Proxy auf deinem Server laufen lässt, füge deiner Caddyfile einen Block wie diesen hinzu:

```caddyfile
hermes.yourdomain.com {
    reverse_proxy your-server-ip:9119
    encode gzip
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options nosniff
        X-Frame-Options SAMEORIGIN
        X-XSS-Protection "1; mode=block"
    }
}
```

Wenn deine Caddy-Instanz in Docker läuft und das Dashboard auf dem Host, nutze `host.docker.internal` statt der IP-Adresse:

```caddyfile
hermes.yourdomain.com {
    reverse_proxy host.docker.internal:9119
}
```

**Host-Networking-Voraussetzung**

Wenn das Dashboard an 127.0.0.1 bindet (der Default), können Docker-Container es nicht über host.docker.internal erreichen. Du musst entweder --host 0.0.0.0 nutzen oder Caddy direkt auf dem Host laufen lassen (nicht in Docker).

Dann Caddy neu laden:

```bash
sudo docker exec caddy caddy reload --config /etc/caddy/Caddyfile
```

Oder wenn Caddy auf dem Host läuft:

```bash
sudo systemctl reload caddy
```

## Passwortschutz hinzufügen

Das Hermes-Dashboard hat kein eingebautes Passwort-Feature. Da es aber hinter Caddy sitzt, kannst du HTTP Basic Auth auf Proxy-Ebene nutzen. Das blendet einen Browser-Login-Prompt ein, bevor irgendjemand das Dashboard erreicht.

### Passwort-Hash erzeugen

Caddy speichert Passwörter als bcrypt-Hashes. Erzeuge einen:

```bash
caddy hash-password --plaintext 'your-password-here'
```

Oder innerhalb einer dockerisierten Caddy:

```bash
sudo docker exec caddy caddy hash-password --plaintext 'your-password-here'
```

Das gibt einen Hash-String aus, der mit `$2a$...` beginnt.

### Caddyfile aktualisieren

Füge eine `basic_auth`-Direktive im Site-Block hinzu:

```caddyfile
hermes.yourdomain.com {
    basic_auth {
        yourusername $2a$14$...your-hash-here...
    }
    reverse_proxy host.docker.internal:9119
    encode gzip
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options nosniff
        X-Frame-Options SAMEORIGIN
        X-XSS-Protection "1; mode=block"
    }
}
```

Ersetze `yourusername` und den Hash durch deine eigenen. Du kannst mehrere Benutzername-Hash-Paare für verschiedene Nutzer hinzufügen.

### Verifizieren, dass es funktioniert

Ohne Credentials – erwarte 401:

```bash
curl -sk -o /dev/null -w "%{http_code}" https://hermes.yourdomain.com/
# 401
```

Mit Credentials – erwarte 200:

```bash
curl -sk -o /dev/null -w "%{http_code}" -u yourusername:your-password-here https://hermes.yourdomain.com/
# 200
```

Wenn du die URL in einem Browser öffnest, erscheint ein Login-Popup, bevor das Dashboard lädt.

### Direkten Zugriff auf Port 9119 blockieren

Wenn Caddy Authentifizierung und TLS auf Port 443 übernimmt, gibt es keinen Grund, Port 9119 direkt erreichbar zu lassen. Wenn jemand die IP deines Servers entdeckt, könnte er Caddy umgehen und das Dashboard auf Port 9119 ganz ohne Passwort treffen. Blockiere es mit iptables:

```bash
# Allow Docker/Caddy internal traffic first
sudo iptables -A INPUT -p tcp --dport 9119 -s 172.16.0.0/12 -j ACCEPT

# Block everything else
sudo iptables -A INPUT -p tcp --dport 9119 -j DROP
```

**Die Docker-Allow-Regel ist kritisch**

Wenn du 9119 nur blockierst, ohne Docker-Traffic vorher zu erlauben, wird auch Caddy geblockt. Caddy verbindet sich mit dem Dashboard über Dockers internes Netzwerk (172.16.0.0/12-Bereich). Die ACCEPT-Regel muss vor der DROP-Regel stehen – iptables verarbeitet Regeln der Reihe nach.

Verifiziere, dass die Regeln greifen:

```bash
sudo iptables -L INPUT -n | grep 9119
# ACCEPT  tcp  --  172.16.0.0/12  0.0.0.0/0  tcp dpt:9119
# DROP    tcp  --  0.0.0.0/0      0.0.0.0/0  tcp dpt:9119
```

Das blockiert alle externen Verbindungen auf 9119, während Caddy das Dashboard intern weiter erreicht.

**Regel über Neustarts hinweg persistieren**

iptables-Regeln gehen beim Neustart standardmäßig verloren. Speichere sie:
sudo iptables-save | sudo tee /etc/iptables/rules.v4
Wenn die Datei nicht existiert, installiere zuerst iptables-persistent: sudo apt install iptables-persistent

Wenn du `ufw` statt rohem iptables nutzt:

```bash
sudo ufw deny 9119/tcp
```

## Dauerhaft mit systemd laufen lassen

Der Befehl `hermes dashboard` läuft im Vordergrund. Schließt du dein Terminal, stoppt er. Damit er dauerhaft läuft, erstelle einen systemd-Service.

### Service-Datei erstellen

```bash
sudo tee /etc/systemd/system/hermes-dashboard.service << 'EOF'
[Unit]
Description=Hermes Agent Dashboard
After=network.target

[Service]
Type=simple
User=dragos
ExecStart=/home/dragos/.hermes/hermes-agent/venv/bin/python -m hermes_cli.main dashboard --host 0.0.0.0 --port 9119 --no-open
Restart=on-failure
RestartSec=5
Environment=HOME=/home/dragos

[Install]
WantedBy=multi-user.target
EOF
```

Passe `User` und den Python-Pfad an dein Setup an. Den exakten Pfad findest du mit:

```bash
which hermes
# or
readlink -f $(which hermes)
```

### Aktivieren und starten

```bash
sudo systemctl daemon-reload
sudo systemctl enable hermes-dashboard
sudo systemctl start hermes-dashboard
sudo systemctl status hermes-dashboard
```

### Logs prüfen

```bash
sudo journalctl -u hermes-dashboard -f
```

## In Docker laufen lassen

Wenn du das Dashboard lieber in einem Docker-Container laufen lässt (konsistent mit dem, wie du andere Dienste auf dem VPS deployst), kannst du es containerisieren. Die zentrale Einschränkung: Das Dashboard muss das Hermes-Gateway auf `127.0.0.1:8642` erreichen – der Container muss also Host-Networking nutzen.

### Dockerfile

```dockerfile
FROM python:3.12-slim

RUN pip install hermes-agent[web]

EXPOSE 9119

CMD ["python", "-m", "hermes_cli.main", "dashboard", "--host", "0.0.0.0", "--port", "9119", "--no-open"]
```

### docker-compose.yml

```yaml
services:
  hermes-dashboard:
    build: .
    container_name: hermes-dashboard
    network_mode: host
    restart: unless-stopped
```

`network_mode: host` ist Pflicht, weil das Gateway an `127.0.0.1:8642` bindet – ohne es erreicht der Container das Gateway nicht, auch nicht über `host.docker.internal`.

### Mit Caddy im selben Stack

Wenn du Caddy schon in Docker laufen lässt (typisches Setup mit einem externen `web`-Netzwerk), ist der Dashboard-Container mit `network_mode: host` von Caddy aus unter `host.docker.internal:9119` erreichbar. Füge den Caddy-Block wie im [Caddy-Reverse-Proxy-Abschnitt](#schritt-2-reverse-proxy-mit-caddy) oben beschrieben hinzu – keine Änderungen nötig.

### Bauen und starten

```bash
docker compose up -d --build
```

### Prüfen, ob es läuft

```bash
sudo docker ps --filter name=hermes-dashboard
curl -sk -o /dev/null -w "%{http_code}" http://127.0.0.1:9119/
```

**Host-Networking und Sicherheit**

network_mode: host heißt, der Container teilt sich den Netzwerk-Stack des Hosts direkt. Der Dashboard-Port ist auf allen Interfaces erreichbar – stell sicher, dass Caddy oder eine Firewall davorsteht, wenn du ihn öffentlich exponierst.

## Sicherheitsrisiken

Ein AI-Agent-Dashboard ins Internet zu exponieren ist nicht dasselbe wie eine statische Website zu exponieren. Das musst du verstehen.

### Das Dashboard ist eine Control Plane

Jeder mit Zugriff auf das Dashboard kann Sessions ansehen, Gedächtnis-Dateien lesen, API-Keys ändern und die Konfiguration verändern. Es ist keine Read-only-Statusseite – es ist voller administrativer Zugriff auf deinen AI-Agenten.

### Basic Auth sendet Credentials in Base64

HTTP Basic Auth kodiert Benutzername und Passwort in Base64 in jedem Request-Header. Ohne HTTPS kann jeder, der dein Netzwerk mitsnifft, sie sofort dekodieren. Caddy liefert automatisches HTTPS mit Let's Encrypt, was das löst – aber nur, wenn du einen echten Domainnamen nutzt, keine rohe IP-Adresse.

**Nie ohne HTTPS exponieren**

Betreibe das Dashboard auf Port 9119 mit --host 0.0.0.0 nicht ohne einen TLS-terminierenden Reverse Proxy davor. Basic Auth über schlichtes HTTP ist praktisch gar keine Auth.

### Credential-Speicherung im Browser

Sobald du dich über Basic Auth eingeloggt hast, cachen die meisten Browser die Credentials und senden sie automatisch bei jedem Request an diese Domain. Wenn jemand Zugriff auf deine Browser-Session bekommt (geteilter Computer, Browser-Exploit), hat er freien Zugriff auf das Dashboard.

### Standardmäßig kein Rate-Limiting

Weder das Dashboard noch Basic Auth bringen Brute-Force-Schutz mit. Ein Angreifer kann tausende Passwörter pro Minute probieren. Ziehe fail2ban-Regeln für deine Reverse-Proxy-Logs in Betracht, oder nutze Caddys `forward_auth` mit einem robusteren Auth-Provider, wenn du das brauchst.

### IP-Allowlisting hilft

Wenn du immer von derselben IP auf das Dashboard zugreifst (Büro, Zuhause), füge Firewall-Regeln hinzu, um den Zugriff einzuschränken:

```bash
# Allow only your IP
sudo ufw allow from YOUR_IP_ADDRESS to any port 443
sudo ufw deny 443
```

Oder nutze in Caddy einen `@blocked`-Matcher:

```caddyfile
hermes.yourdomain.com {
    @blocked not remote_ip YOUR_IP_ADDRESS/32
    respond @blocked "Forbidden" 403

    basic_auth {
        yourusername $2a$14$...
    }
    reverse_proxy host.docker.internal:9119
}
```

### Das Dashboard spricht mit dem Gateway

Das Dashboard kommuniziert mit der Hermes-Gateway-API auf `127.0.0.1:8642`. Wenn jemand das Dashboard kompromittiert, hat er auch indirekten Zugriff auf das Gateway – das den Agenten steuert, der Terminal-Befehle auf deinem Server ausführen kann. Behandle das Dashboard als privilegierte Fläche, nicht als Komfort-Feature.

### Risiken im Überblick

| Risiko | Schweregrad | Maßnahme |
|---|---|---|
| Dashboard ohne HTTPS exponiert | Kritisch | Immer Caddy mit TLS nutzen |
| Port 9119 offen ins Internet | Kritisch | Mit iptables blockieren (siehe oben) |
| Schwaches oder wiederverwendetes Passwort | Hoch | Ein starkes Zufallspasswort erzeugen |
| Kein Brute-Force-Schutz | Mittel | fail2ban oder IP-Allowlisting hinzufügen |
| Browser cached Credentials | Mittel | Privates Surfen auf geteilten Maschinen nutzen |
| Dashboard gibt Gateway-Zugriff | Hoch | IP-Restriction + starke Auth + Logs überwachen |

## Kurzreferenz

```bash
# Local only (safe default)
hermes dashboard

# SSH tunnel (remote access, safest)
ssh -L 9119:127.0.0.1:9119 user@your-vps-ip
# Then open http://127.0.0.1:9119 on your laptop

# Remote access (bind to all interfaces)
hermes dashboard --host 0.0.0.0

# Custom port
hermes dashboard --host 0.0.0.0 --port 3000

# With systemd (permanent)
sudo systemctl start hermes-dashboard

# With Docker
docker compose up -d --build

# Check it is running
curl -sk -o /dev/null -w "%{http_code}" https://hermes.yourdomain.com/
```

Für mehr zu Hermes-Agent-Setup, Messaging-Integration und Skills sieh den [Hermes-Agent-Setup-Guide](/hermes-agent-setup-guide/) und den [MIMO-V2-Pro-Integrations-Guide](/hermes-agent-mimo-v2-pro/). Für die besten Drittanbieter-Dashboards und Web-UIs jenseits des eingebauten sieh das Roundup der [besten Hermes-Dashboards](/de/beste-hermes-dashboards/). Für bezahlbare Modell-Empfehlungen für Hermes Agent sieh den Guide zu den [besten günstigen Modellen für Hermes Agent](/de/guenstige-hermes-agent-modelle/). Für strukturiertes Multi-Agent-Task-Management mit visuellen Boards behandelt die [Hermes-Kanban-Einrichtung](/de/hermes-kanban-einrichten/) Kanban-Task-Boards, Abhängigkeiten und Koordinations-Muster.

[Mehr KI-Tool-Guides](/categories/ai/)