Hermes Agent sicher auf einem Hostinger VPS installieren

Vor dem Kauf: Ist ein Hostinger VPS die richtige Runtime?

Ein VPS passt gut, wenn Hermes rund um die Uhr erreichbar sein soll, externe Modell-APIs nutzt und vor allem Web-, Messaging-, Datei- oder leichte Script-Aufgaben erledigt. Typische Beispiele sind Daily Briefings, ein Telegram-Assistent, Repository-Zusammenfassungen und read-only Monitoring. Der Server bleibt online, wenn dein Laptop geschlossen ist, und lässt sich als klar abgegrenzte Agentenumgebung behandeln.

Ein VPS ist nicht automatisch die beste Wahl. Wenn Hermes auf lokale Mac-Dateien zugreifen oder ein Apple-Silicon-Modell verwenden soll, ist ein Mac naheliegender. Wenn dein Unternehmen bereits AWS IAM oder Microsoft Entra betreibt, sind Bedrock oder Foundry oft besser in Governance und Audit integriert. Für hochsensible Daten kann eine eigene Infrastruktur mit lokalen Modellen erforderlich sein.

Die Kosten bestehen aus mindestens zwei Teilen: VPS und Modellnutzung. Der genaue Hostinger-Preis hängt von Tarif, Region, Laufzeit, Aktionen und Steuern ab und kann sich jederzeit ändern. Modellkosten schwanken stärker als der Serverpreis. Browser-Automation, lange Kontexte, häufige Cron-Jobs und mehrere Agenten können aus einem günstigen Setup einen teuren Betrieb machen.

1. VPS auswählen und bereitstellen

Wähle einen KVM-basierten VPS mit Ubuntu LTS. Für einen einzelnen Agenten mit externem Modell ist ein kleiner Plan ausreichend; 2 GB RAM geben dem Gateway, Python-Werkzeugen und gelegentlichen Browser- oder Build-Prozessen mehr Luft. Für Docker, mehrere Profile oder speicherintensive Tools sind 4 GB sinnvoller.

• Virtualisierung: KVM mit voller Linux-Umgebung
• Betriebssystem: eine aktuell unterstützte Ubuntu-LTS-Version
• RAM: 2 GB als komfortabler Einstieg, mehr bei Docker oder parallelen Jobs
• Region: passend zu Nutzern, Daten und Verträgen; nicht nur nach Latenz entscheiden
• Backups: Anbieter-Snapshot ist hilfreich, ersetzt aber kein getrenntes Anwendungsbackup

Aktuelle Hostinger-VPS-Pläne prüfen →
Affiliate-Link; für dich entstehen durch die Zuordnung keine zusätzlichen Kosten.

2. Per SSH verbinden – aber Root nicht zum Dauerzustand machen

Das Provider-Panel zeigt IP-Adresse und initiale Zugangsdaten. Vergleiche den SSH-Fingerprint mit den Angaben des Anbieters, bevor du ihn bestätigst. Der erste Login kann als Root erfolgen; anschließend legst du einen persönlichen Benutzer an und verwendest SSH-Keys.

ssh root@DEINE_VPS_IP
apt update
apt upgrade -y
adduser hermesops
usermod -aG sudo hermesops

Erzeuge auf deinem eigenen Rechner einen Schlüssel, falls noch keiner existiert, und kopiere den öffentlichen Schlüssel auf den Server:

ssh-keygen -t ed25519 -C "hermescoach-vps"
ssh-copy-id hermesops@DEINE_VPS_IP

Öffne eine zweite Terminalverbindung und prüfe, dass der neue Login samt sudo funktioniert. Erst danach deaktivierst du Passwort- und Root-Login in der SSH-Konfiguration. Bei einem Fehler behältst du die erste Session offen und kannst korrigieren, statt dich selbst auszusperren.

3. Grundpakete und Zeitzone prüfen

Melde dich als neuer Benutzer an. Installiere nur, was du wirklich benötigst. Für den offiziellen Installer sind mindestens curl und eine funktionierende Linux-Umgebung relevant. Git und Build-Werkzeuge werden für viele Entwicklungs-Workflows nützlich.

sudo apt update
sudo apt install -y curl git build-essential ca-certificates
timedatectl status

Die richtige Zeitzone ist für Cron-Jobs entscheidend. Prüfe ausdrücklich, ob geplante Aufgaben in UTC oder Europe/Berlin laufen sollen. Eine falsch verstandene Zeitzone ist einer der häufigsten Gründe für vermeintlich ausgefallene Briefings.

4. Hermes mit dem offiziellen Installer installieren

Führe den aktuellen Installer als normaler Benutzer aus. Verwende die offizielle Hermes-Domain statt eines kopierten Raw-GitHub-Pfads aus einem alten Blogpost.

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Starte danach eine neue Shell oder lade das von der Installation genannte Profil. Prüfe, ob der Befehl vorhanden ist:

hermes --version
hermes doctor

Diese Anleitung ist für Hermes v0.18.2 geprüft. Wenn eine neuere Version verfügbar ist, lies zuerst die offiziellen Release Notes. Eine Produktionsinstanz sollte nicht ungeprüft unmittelbar nach jedem Release aktualisiert werden.

5. Modellprovider wählen und einen Terminaltest machen

Starte die Modellauswahl:

hermes model

Der beste Provider hängt nicht nur vom Preis ab. Prüfe Tool-Calling-Qualität, Kontextfenster, Datenweg, Vertragslage, Latenz und Rate Limits. Nous Portal bietet den schnellsten Einstieg in viele Modelle. OpenRouter kann verschiedene Anbieter bündeln. AWS Bedrock oder Microsoft Foundry passen zu bestehender Enterprise-Identität. Ein lokaler OpenAI-kompatibler Endpoint vermeidet externe Modellaufrufe, benötigt aber passende Hardware.

Teste zuerst eine harmlose, überprüfbare Aufgabe in einem eigenen Arbeitsverzeichnis:

mkdir -p ~/hermes-workspace
cd ~/hermes-workspace
hermes

Bitte den Agenten etwa, eine kurze Markdown-Datei anzulegen und anschließend wieder zu lesen. Prüfe Dateiinhalt, Modellantwort und Tool-Anzeige. Verbinde erst danach weitere Systeme.

6. Telegram-Bot sicher anbinden

Öffne in Telegram den verifizierten @BotFather, führe /newbot aus und bewahre den Token wie ein Passwort auf. Er darf nicht in ein Repository, einen Screenshot oder eine Chatnachricht geraten. Auf dem VPS startet der interaktive Gateway-Wizard:

hermes gateway setup

Wähle Telegram, hinterlege den Token und trage deine numerische Telegram User-ID in die Allowlist ein. Die ID ist nicht der veränderbare Username. Für Teams ist DM-Pairing oft besser: Ein neuer Nutzer erhält einen zeitlich begrenzten Code, den der Betreiber serverseitig freigibt.

hermes pairing list
hermes pairing approve telegram PAIRING_CODE

Teste das Gateway zunächst im Vordergrund:

hermes gateway

Schicke dem Bot eine Nachricht. Prüfe die Antwort und beende den Test mit Ctrl+C. Setze in einem privaten Chat oder Teamkanal über /sethome einen Home Channel, damit geplante Aufgaben ein eindeutiges Ziel besitzen.

7. Gateway als dauerhaften Linux-Service installieren

Ein Prozess in tmux eignet sich für einen Test, aber nicht als dauerhafter Betriebsweg. Hermes kann den Gateway als Service installieren. Auf einem Linux-Server ist ein bootfähiger System-Service möglich:

sudo hermes gateway install --system
sudo hermes gateway start --system
sudo hermes gateway status --system

Die Logs findest du in diesem Modus über:

journalctl -u hermes-gateway -f

Wenn du lieber einen Benutzer-Service verwendest, folge der aktuellen Gateway-Dokumentation und aktiviere bei Bedarf Linger, damit der Dienst nach dem SSH-Logout weiterläuft. Verwende nicht gleichzeitig mehrere Startmethoden; sonst konkurrieren zwei Gateways um denselben Bot-Token.

8. Docker und minimale Berechtigungen

Der lokale Terminal-Backend führt Befehle direkt auf dem VPS aus. Für unbekannte Repositorys, Teamzugriff oder generierten Code ist ein Container-Backend deutlich sicherer. Docker ist keine magische Grenze: Mounts, Netzwerk, Capabilities, persistente Volumes und Ressourcenlimits müssen bewusst konfiguriert werden.

Beginne mit einem eigenen Arbeitsverzeichnis ohne persönliche SSH-Schlüssel oder Cloud-Admin-Tokens. Gib dem Agenten nur die APIs, die der erste Workflow wirklich braucht. Ein Briefing-Agent braucht Webzugriff und einen Versandkanal, aber keinen Root-Zugriff. Ein Repository-Reviewer benötigt möglicherweise Lesezugriff auf GitHub, aber nicht automatisch Merge- oder Deployment-Rechte.

9. Backup, Update und Kostenkontrolle

Mindestens Konfiguration, Skills, Cron-Definitionen und relevante Zustandsdaten unter ~/.hermes/ müssen gesichert werden. Verschlüssele Backups, wenn sie Tokens oder personenbezogene Inhalte enthalten. Speichere mindestens eine Kopie außerhalb des VPS und teste eine Wiederherstellung auf einer frischen Umgebung.

• Täglich: Gateway-Status, fehlgeschlagene Cron-Jobs und ungewöhnliche Kosten prüfen.
• Wöchentlich: Betriebssystemupdates, Disk, Logs und Backup-Erfolg kontrollieren.
• Vor Hermes-Updates: Snapshot und Anwendungsbackup erstellen, Release Notes lesen, Kernworkflow testen.
• Monatlich: Tokens, Pairings, API-Scopes, veraltete Skills und nicht mehr benötigte Daten bereinigen.

Ein Cron-Job läuft in einer frischen Session. Schreibe deshalb selbstständige Prompts mit Quellen, Zeitraum, Format, Zielkanal, maximalem Umfang und Abbruchkriterien. „Mach mein übliches Briefing“ ist kein belastbarer Auftrag.

10. Häufige Probleme und Lösungen

hermes: command not found

Öffne eine neue Shell, lies die Installerausgabe und prüfe den PATH. Installiere nicht parallel mit mehreren Methoden, bevor klar ist, welche Umgebung aktiv ist.

Der Telegram-Bot antwortet nicht

Prüfe hermes gateway status, die Service-Logs, Bot-Token, Nutzer-Allowlist und ob ein zweiter Prozess denselben Token verwendet. Bei Cron-Ausgaben muss außerdem ein Home Channel gesetzt sein.

Modellaufrufe hängen oder brechen ab

Führe hermes doctor aus. Prüfe Provider-Guthaben, Rate Limit, Modellname und Kontextfenster. Lokale Modelle benötigen bei langem Prompt unter Umständen deutlich längere Prefill-Zeit.

RAM oder Disk laufen voll

Identifiziere zuerst den Verursacher: Browser, Docker-Images, Build-Artefakte, Logs oder mehrere parallele Jobs. Ein Swapfile kann kurze Spitzen abfedern, ersetzt aber kein passendes Sizing und keine Limits. Lösche Daten nicht blind, bevor Backups und laufende Prozesse geprüft sind.

Der Agent verbraucht unerwartet viel Geld

Stoppe Gateway oder betroffenen Job, prüfe Cron-Frequenz, Wiederholungen, Modell, Kontextgröße und Subagenten. Baue eine günstigere mechanische Vorstufe ein: Ein Script prüft, ob neue Daten vorhanden sind; nur dann startet das LLM.

11. Produktions-Checkliste

• Persönlicher sudo-Benutzer und SSH-Key funktionieren; Root- und Passwortzugriff sind begrenzt.
• Firewall und Provider-Firewall öffnen nur notwendige Ports; für Telegram-Polling ist kein öffentlicher Bot-Port nötig.
• Hermes und Provider wurden mit einem harmlosen Testworkflow geprüft.
• Telegram nutzt Allowlist oder Pairing; der Bot-Token liegt nur in der geschützten Umgebung.
• Gateway läuft genau einmal als überwachter Service und startet nach einem Reboot.
• Agentenarbeit findet in einem begrenzten Workspace oder Container statt.
• Cron-Jobs besitzen vollständige Prompts, Zielkanal, Budget und Fehlermeldung.
• Backups liegen getrennt vor und eine Rücksicherung wurde getestet.
• Providerlimits, Kostenwarnungen, Logs und ein Kill-Switch sind dokumentiert.
• Ein Mensch ist als Owner für Ergebnisse, Fehler und Berechtigungen benannt.

Quellen und Transparenz

Technische Hermes-Angaben wurden am 15. Juli 2026 gegen die offizielle Dokumentation, das offizielle GitHub-Repository und die Releases geprüft. Hostinger ist eine mögliche Runtime, nicht Voraussetzung für Hermes Agent. Dieser Guide enthält Affiliate-Links; die fachliche Empfehlung wird davon getrennt.