Dashboard hinter Caddy: TLS (100 Jahre selbstsigniert) + eigene Basic-Auth auf Port 443

Stefans Entscheidung: 0.0.0.0-Bind mit unverschluesseltem Basic-Auth war nur
Testzustand. Jetzt bindet hermes-agent-dashboard wieder auf 127.0.0.1, ein
neuer Caddy-Service (network_mode: host) terminiert TLS auf 443 mit einem
manuell erzeugten selbstsignierten Zertifikat (100 Jahre Laufzeit, kein
Let's-Encrypt-Domain-Zwang) und erzwingt eine zweite, eigene Basic-Auth-Schicht
(bcrypt-Hash in CADDY_BASIC_AUTH_HASH, getrennt von Hermes' pbkdf2-Hash) -
noetig weil Hermes' eigenes Auth-Gate laut Fehlermeldung nur bei 0.0.0.0-Binds
"engagiert". README + .env.example um die Setup-Schritte (Cert-Erzeugung,
Caddy-Hash, $-Escaping-Falle) ergaenzt.

docker-compose.yml

@@ -195,10 +195,51 @@ services:
       # Hash-Erzeugen).
       - HERMES_DASHBOARD_USER=${HERMES_DASHBOARD_USER:-admin}
       - HERMES_DASHBOARD_PASSWORD_HASH=${HERMES_DASHBOARD_PASSWORD_HASH:?HERMES_DASHBOARD_PASSWORD_HASH muss in .env gesetzt sein - siehe .env.example. Ohne Auth-Provider verweigert Hermes den 0.0.0.0-Bind komplett.}
-    # Stefans Wunsch vom 19.07.2026: weiter auf 0.0.0.0, weil SSH-Tunnel/SSL
-    # Probleme machte — jetzt aber MIT registriertem Basic-Auth-Provider (s.o.),
-    # sonst kommt der Container laut Hermes' eigenem Auth-Gate gar nicht hoch.
-    command: ["dashboard", "--host", "0.0.0.0", "--no-open"]
+    # Kurskorrektur 19.07.2026, spaeter Abend: Stefan wollte erst 0.0.0.0
+    # (SSH-Tunnel machte mit SSL Probleme), jetzt aber die richtige Loesung:
+    # Dashboard bleibt auf 127.0.0.1 (Hermes' eigenes Auth-Gate verlangt dann
+    # gar keinen registrierten Provider mehr, siehe Fehlermeldung "the auth
+    # gate engages on non-loopback binds") und der Caddy-Reverse-Proxy unten
+    # macht TLS + Basic-Auth auf Port 443 nach aussen. HERMES_DASHBOARD_USER/
+    # _PASSWORD_HASH bleiben trotzdem gesetzt (schadet nicht, falls der Bind
+    # doch mal wieder auf 0.0.0.0 wandert).
+    command: ["dashboard", "--host", "127.0.0.1", "--no-open"]
+
+  # ─── Caddy (TLS-Reverse-Proxy + Basic-Auth vor dem Dashboard) ──────────
+  # Stefans Entscheidung 19.07.2026: Dashboard bleibt intern auf 127.0.0.1,
+  # Caddy uebernimmt TLS-Termination auf Port 443 UND eine zweite Basic-Auth-
+  # Schicht davor. Der zweite Punkt ist kein Overkill, sondern noetig: Hermes'
+  # eigenes Auth-Gate "engagiert" laut seiner eigenen Fehlermeldung NUR bei
+  # einem 0.0.0.0-Bind. Auf 127.0.0.1 (das Caddy hier anspricht) ist unklar/
+  # nicht garantiert, ob dashboard.basic_auth trotzdem noch durchgesetzt wird
+  # - deshalb sichert Caddy selbst zusaetzlich ab, statt sich darauf zu
+  # verlassen. Nutzt denselben HERMES_DASHBOARD_USER wie Hermes (aus .env),
+  # aber einen EIGENEN Hash: Caddys basic_auth will bcrypt, Hermes' Hash ist
+  # pbkdf2 — Formate sind nicht kompatibel, siehe .env.example fuer die
+  # Erzeugung von CADDY_BASIC_AUTH_HASH.
+  #
+  # Zertifikat: bewusst KEIN Let's Encrypt (bräuchte oeffentliche Domain +
+  # Port-80-Challenge). Stefans Wunsch: ein selbstsigniertes Zertifikat mit
+  # 100 Jahren Laufzeit, einmalig im Browser als Ausnahme akzeptieren, nie
+  # wieder um Erneuerung kuemmern. Erzeugung siehe README Setup-Schritt.
+  # network_mode: host aus demselben Grund wie bei hermes-agent/-dashboard:
+  # muss 127.0.0.1:9119 (Dashboard) erreichen UND selbst auf dem Host-Port
+  # 443 lauschen.
+  caddy:
+    image: caddy:2-alpine
+    container_name: hermes-caddy
+    restart: unless-stopped
+    network_mode: host
+    depends_on:
+      - hermes-agent-dashboard
+    volumes:
+      - ./Caddyfile:/etc/caddy/Caddyfile:ro
+      - ./hermes-data/caddy-certs:/certs:ro
+      - ./hermes-data/caddy-data:/data
+      - ./hermes-data/caddy-config:/config
+    environment:
+      - HERMES_DASHBOARD_USER=${HERMES_DASHBOARD_USER:-admin}
+      - CADDY_BASIC_AUTH_HASH=${CADDY_BASIC_AUTH_HASH:?CADDY_BASIC_AUTH_HASH muss in .env gesetzt sein - siehe .env.example}
 
 networks:
   hermes-net: