Ich habe Hermes Agent auf einem Hostinger VPS eingerichtet — und am nächsten Morgen war alles kaputt. Hier ist die ehrliche Aufarbeitung: Fehlerdiagnose, Root Cause und der Fix für dauerhaften Betrieb.
Das .venv von Hermes überlebt keinen Container-Neustart, weil es im Image-Filesystem liegt, nicht im Volume. Einmalig neu bauen + Permissions fixen + Volume-Mount ergänzen = dauerhaft stabil.
Warum ich Hermes ausprobiere
Ich betreibe mit SMART11 eine Performance-Marketing-Agentur für Handwerksbetriebe im DACH-Raum. Unser Stack: Close CRM, Make, Airtable, ClickUp, Slack und seit Kurzem zunehmend Claude API für interne Automatisierungen.
Die Idee hinter dem Hermes-Piloten: Ein selbst-gehosteter KI-Agent, der morgens automatisch ein Sales-Pipeline-Briefing in Slack postet ohne dass ich oder mein Team manuell Zahlen zusammensuchen müssen. Hermes von Nous Research ist Open Source, läuft vollständig self-hosted, hat einen eingebauten Cron-Scheduler und unterstützt über 20 Messaging-Plattformen als Gateway. Klingt perfekt.
Hostinger KI Agenten (Werbung) hat einen Ein-Klick-Deploy für Hermes im VPS-App-Katalog, das hat mich überzeugt, es dort zu versuchen statt auf Hetzner. Frankfurt-Datacenter, DSGVO-konform, schnell eingerichtet.
Tag 1: Setup läuft durch
Die Installation über hPanel war tatsächlich reibungslos. VPS mit Ubuntu 24.04 deployen, Hermes-App auswählen, API Keys eintragen — nach wenigen Minuten war der Agent erreichbar und ich konnte ihn im Browser öffnen. Gateway verbunden, Telegram-Bot läuft, erster Test erfolgreich.
Was funktioniert hat
Ein-Klick-Deploy über hPanel · Telegram-Gateway-Verbindung · Claude API Key Integration · Erster manueller Test im Browser-Terminal
Tag 2: Alles kaputt
Am nächsten Morgen öffne ich den Hermes-Agent im Browser und statt der gewohnten Shell erscheint ein zsh-Konfigurationsdialog. Das war das erste Symptom.
Fehlermeldung im Terminal: hermes-shim: /opt/hermes/.venv/bin/hermes not found or not executable
Das Binary ist weg. Aber warum? Der Container läuft (docker ps zeigt Up 7 minutes), die Daten in /opt/data sind da — aber Hermes selbst antwortet nicht.
Die Fehlerdiagnose Schritt für Schritt
1. Container-Logs prüfen
Der erste Schritt war ein Blick in die Docker-Logs:
docker logs hermes-agent-pizb-hermes-agent-1 --tail 100Der entscheidende Eintrag:
# Exit Code 127 = Command not found process exited with code 127, pid: 202. Entrypoint und hermes.sh analysieren
Der Entrypoint des Hostinger-Images ruft /hermes.sh auf, welches intern hermes gateway run startet. Das Binary wird über /opt/hermes/.venv/bin/hermes aufgelöst — und genau das existierte nach dem Neustart nicht mehr.
3. Root Cause: .venv im falschen Ort
Der entscheidende Fund mit docker inspect:
# Nur /opt/data ist als Volume gemountet "Mounts": [{ "Type": "bind", "Source": "/docker/hermes-agent-pizb/data", "Destination": "/opt/data" }]Das .venv liegt in /opt/hermes/.venv — also im Container-Filesystem, nicht im Volume. Beim Neustart des Containers wird das Image-Filesystem neu aufgebaut. Wenn das Build-Skript das .venv nicht korrekt anlegt (oder das Image-Layer fehlt), ist das Binary weg.
Root Cause
Das .venv liegt im Container-Filesystem (nicht im Volume) und wurde beim letzten Start nicht korrekt gebaut. Jeder Neustart ohne funktionierendes Entrypoint-Build-Skript hinterlässt das Binary-Verzeichnis leer.
Der Fix
Schritt 1: In den Container, .venv neu bauen
docker exec -it hermes-agent-pizb-hermes-agent-1 bash # Im Container: cd /opt/hermes rm -rf .venv python3 -m venv .venv source .venv/bin/activate pip install -e . # Prüfen: hermes --version # → Hermes Agent v0.15.1 ✅Schritt 2: Permissions korrigieren
Hermes läuft intern als hermes User (via gosu). Ein als Root gebautes .venv ist nicht ausführbar:
exit # raus aus Container docker exec hermes-agent-pizb-hermes-agent-1 \ chown -R hermes:hermes /opt/hermes/.venv docker restart hermes-agent-pizb-hermes-agent-1Schritt 3: .venv dauerhaft ins Volume auslagern
Der eigentliche Dauerhaft-Fix: Das .venv aus dem Container-Filesystem ins gemountete Volume verschieben, damit es Neustarts überlebt:
cd /docker/hermes-agent-pizb # .venv aus Container auf Host kopieren docker cp hermes-agent-pizb-hermes-agent-1:/opt/hermes/.venv ./venv chown -R 1000:1000 ./venv # docker-compose.yml anpassen: sed -i 's| - ./data:/opt/data| - ./data:/opt/data\n - ./venv:/opt/hermes/.venv|' \ docker-compose.yml # Neu starten docker compose down && docker compose up -dDie finale docker-compose.yml sieht dann so aus:
volumes: - ./data:/opt/data - ./venv:/opt/hermes/.venv # neu: überlebt NeustartsErgebnis
Gateway startet zuverlässig. Binary ist nach Neustarts verfügbar. Daten bleiben erhalten. Kein manueller Eingriff mehr nötig.
Wichtige Hinweise für den Betrieb
- Niemals/restartim Chat-Interface nutzen, bekannter Bug in Docker: der Befehl fährt den Gateway permanent herunter statt ihn neu zu starten. Immerdocker restartper SSH verwenden.
- Das Hostinger-Image läuft alshermesUser. Als Root gebaute Dateien in/opt/hermesführen zu Permission-Fehlern. Immerchown -R hermes:hermesnachziehen.
- DSGVO-Hinweis: Hostinger Frankfurt ist EU-konform für den Server-Standort. Die Claude API (US-Server) braucht zusätzlich einen AVV/DPA — der ist für API-Kunden bei Anthropic automatisch ab 1. Januar 2026 in den Commercial Terms enthalten.
- System-Updates nicht vergessen: Beim ersten Login lagen 9 ausstehende Pakete vor, darunter Docker CE und containerd. Einapt upgrade -y && rebootdirekt nach dem Setup ist Pflicht.
Fazit
Hermes auf Hostinger funktioniert, aber der Ein-Klick-Deploy ist kein „fire and forget“. Das größte Fallstrick ist das .venv, das im Container-Filesystem liegt und bei Neustarts verloren gehen kann. Mit dem Volume-Mount-Fix ist das gelöst. Für micht bleibt der Use-Case interessant: Ein morgendliches Sales-Pipeline-Briefing via Telegram, automatisch durch Cron getriggert. Dafür brauche ich keinen teuren Cloud-Service und ein 5€ VPS reicht.
