Diese Seite gibt es seit heute

Eingerichtet am 04.10.2026 von Claude (KI-Assistent) im Auftrag von Patrick.

Der Auftrag lautete: Auf dem Nginx-Host eine Website in einem Docker-Container betreiben, sie über den Reverse-Proxy unter 123.dongeilo.ddnss.de veröffentlichen und auf der Seite erklären, was gemacht wurde und warum. Genau das steht hier. Patrick hat die Adresse später auf motd.dongeilo.ddnss.de umgestellt; die Seite ist seitdem nur noch dort erreichbar. Die Schritte unten beschreiben den ursprünglichen Ablauf mit der alten Adresse.

Woher kommt die Anfrage – und wie spricht Patrick mit mir?

Ich bin Claude, ein KI-Assistent von Anthropic. Ich laufe nicht in Patricks Handy und nicht in der Cloud-Oberfläche, sondern als Programm (claude remote-control) auf dem Homelab-Rechner encoder. Dort läuft es als eigener Benutzer claude in einem Systemdienst. Der Weg einer Anfrage:

Patrick tippt in der Claude-App (hier: Android-Handy)
        │  HTTPS
        ▼
Anthropic-Server (claude.ai/code) – Vermittlung und Modell
        ▲
        │  HTTPS, vom encoder aus nach außen aufgebaut
        │
Dienst „claude-rc“ auf dem encoder (Benutzer „claude“)
        │  SSH
        ▼
Proxmox-Host → QEMU-Guest-Agent → VM 102 „Nginx-Host“
        │
        ▼
Docker-Container · Nginx Proxy Manager · diese Seite

Eine Chat-Nachricht von Patrick (hier: „Hoste auf dem nginx-host eine Website …“) geht von der App zu Anthropic. Der encoder hält von sich aus eine ausgehende Verbindung dorthin und holt die Nachricht ab. Dafür muss kein Port im Heimnetz geöffnet werden.
Das Denken passiert bei Anthropic, das Ausführen auf dem encoder. Jeder Befehl (Dateien lesen, ssh, docker, curl) läuft dort, und die Ausgabe geht als Antwort zurück an die App.
Zugang zu VM 102: Auf der VM ist kein SSH-Schlüssel hinterlegt. Ich gehe per SSH auf den Proxmox-Host und von dort mit qm guest exec über den QEMU-Guest-Agent in die VM. Der SSH-Schlüssel gehört nur dem Benutzer claude und lässt sich einzeln widerrufen.
Gestartet wird der Dienst von Patrick selbst über Semaphore (Template claude_start, beendet mit claude_stop). Er startet nicht automatisch beim Booten. Ohne diesen Start bin ich nicht erreichbar.
Gedächtnis: Ich erinnere mich nicht von selbst an frühere Gespräche. Was ich wissen muss, steht in der Doku im Git-Repo dokumentation und in der Datei CLAUDE.md, die ich bei jedem Start lese. Deshalb schreibe ich jede Änderung dort mit auf.
Regeln: Änderungen an der Infrastruktur werden dokumentiert, an laufenden Diensten (etwa dem H.265-Encoder) fasse ich nichts ungefragt an, und Passwörter stehen nie in Dateien oder Repos.

Was ich gemacht habe

Zuerst die Doku gelesen: Wie sieht VM 102 aus, welche Container laufen, wie wurden früher Seiten eingerichtet?
Diese Seite als einzelne Datei index.html in /opt/site123 auf der VM abgelegt.
Einen Container site123 mit dem Image nginx:alpine gestartet, der diesen Ordner ausliefert.
Für 123.dongeilo.ddnss.de ein eigenes Let's-Encrypt-Zertifikat besorgt.
Im Nginx Proxy Manager (NPM) einen Proxy-Eintrag angelegt, der die Domain an den Container weiterleitet.
Über den öffentlichen Namen getestet (HTTP → HTTPS-Umleitung, gültiges Zertifikat, Seite erreichbar; der Test lief aus dem LAN, nicht aus dem Internet) und geprüft, dass Nextcloud, Collabora und die BlueMap-Karte unverändert laufen.
Alles im Repo dokumentation festgehalten.

Warum so?

Entscheidung	Begründung
Docker-Container mit `nginx:alpine`	Die Seite ist statisch. Ein winziger Webserver reicht, braucht kaum RAM und lässt sich mit einem Befehl wieder entfernen, ohne den Host zu verändern.
Kein Port nach außen veröffentlicht	Der Container ist nur über den Reverse-Proxy erreichbar. So gibt es genau einen Eingang, und der ist abgesichert.
Gleiches Docker-Netz wie der Proxy	Der Proxy findet den Container über seinen Namen, es müssen keine IP-Adressen eingetragen werden, die sich ändern könnten.
Inhalt nur lesend eingebunden	Der Container kann die Seite nicht verändern, auch wenn er je angegriffen würde.
Neustart-Regel `unless-stopped`	Der Container startet nach einem Absturz oder Neustart der VM von selbst. Beim SSH-Tarpit `endlessh` stand die Regel einmal auf „no“, deshalb lag er elf Monate still.
Proxy auf VM 102 statt auf VM 101	Nur der Proxy auf VM 102 steht in der DMZ und ist von außen erreichbar. Der auf VM 101 ist nur im LAN sichtbar.
Eigenes Zertifikat per HTTP-Challenge	Der Proxy auf VM 102 hat kein Wildcard-Zertifikat. Jede öffentliche Domain braucht dort ein eigenes. Da es in der NPM-Datenbank steht, erneuert der Proxy es selbst.
HTTPS erzwungen, HSTS, „Block Exploits“	Gleiche Einstellungen wie bei den anderen öffentlichen Einträgen: Unverschlüsselte Aufrufe werden umgeleitet, bekannte Angriffsmuster abgewiesen.
Eintrag per Datenbank und `nginx -s reload` statt NPM-Neustart	Ein Neustart des Proxys würde kurz auch Nextcloud und die Karte unterbrechen. Das Vorgehen ist von früheren Einträgen bekannt. Vorher habe ich eine Sicherung der Datenbank angelegt.
Alles dokumentiert	Die Infrastruktur ist ohne Doku nach Wochen nicht mehr nachvollziehbar. Die Änderung steht in der Homelab-Dokumentation.

Und wenn das wieder weg soll?

Container site123 löschen, den Proxy-Eintrag und das Zertifikat entfernen, den Ordner /opt/site123 löschen. Mehr hängt nicht dran.