Hermes Agent auf einem VPS installieren: Schritt für Schritt

Wir haben an anderer Stelle bereits erklärt, warum wir intern mit Hermes Agent arbeiten. Die häufigste Rückfrage danach war konkreter: Wie bekommt man das Ding eigentlich auf einen eigenen Server? Dieser Beitrag beantwortet genau das – Schritt für Schritt, auf einem gewöhnlichen Linux-VPS, wie ihn die meisten Mittelständler ohnehin schon für andere Zwecke gemietet haben.

Diese Anleitung ersetzt nicht die offizielle Installationsdokumentation (öffnet in neuem Tab) von Nous Research, sondern führt durch die für einen Server-Betrieb relevanten Schritte und ordnet ein, worauf es dabei ankommt.

Warum ein VPS und nicht der eigene Laptop?

Laut der Hermes-Dokumentation (öffnet in neuem Tab) ist der Agent nicht an ein bestimmtes Gerät gebunden: Er läuft „wherever you put it – a $5 VPS, a GPU cluster, or serverless infrastructure that costs nearly nothing when idle". Der Sinn dahinter: Man kann den Agenten über einen Messenger wie Telegram oder Slack ansprechen, während er auf einem Server arbeitet, den man selbst nie per SSH betritt. Für wiederkehrende Automatisierungen – etwa geplante Auswertungen oder das Überwachen von Kennzahlen – ist ein dauerhaft laufender Server praktischer als ein Laptop, der irgendwann zugeklappt wird.

Voraussetzungen

Laut Installationsanleitung (öffnet in neuem Tab) reicht auf Linux, macOS, WSL2 und Android (Termux) im Kern ein einziges Werkzeug: Git. Auf Linux kommen curl und xz-utils dazu, weil der Installer Node.js als .tar.xz-Archiv herunterlädt:

sudo apt install git curl xz-utils

Alles Weitere – Python 3.11 (über den Paketmanager uv, ohne Root-Rechte), Node.js v22, ripgrep und ffmpeg – installiert das Setup-Skript laut Dokumentation selbstständig nach.

Für die offiziell unterstützten Plattformen gilt laut der Platform-Support-Matrix (öffnet in neuem Tab): Linux/WSL2 auf x86_64 und aarch64 zählt zur höchsten Support-Stufe ("Tier 1"), getestet wird dort auf aktuellem Ubuntu. Andere Distributionen funktionieren laut Dokumentation voraussichtlich gut, wenn sie glibc und systemd mitbringen und dem Filesystem Hierarchy Standard folgen – eine Garantie ist das nicht.

Installation auf dem Server

Der eigentliche Installationsbefehl ist laut Dokumentation eine einzige Zeile:

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

Was dabei passiert, beschreibt die Dokumentation so: Der Installer richtet alle Abhängigkeiten ein, klont das Repository, legt eine virtuelle Python-Umgebung an, verknüpft den globalen hermes-Befehl und führt durch die Einrichtung eines LLM-Anbieters.

Wichtig für den Serverbetrieb ist, als welcher Nutzer installiert wird – das Ergebnis unterscheidet sich laut Dokumentation deutlich:

Der Root-Modus folgt laut Dokumentation dem Filesystem Hierarchy Standard und eignet sich für Server, auf denen mehrere Nutzer denselben systemweiten Hermes-Befehl teilen sollen. Für einen dedizierten VPS, auf dem ein einzelner Dienst laufen soll, ist die Installation unter einem eigenen, unprivilegierten Benutzerkonto der Weg, den die Dokumentation als "Recommended split" für Service-Accounts beschreibt – dazu gleich mehr.

Nach der Installation:

source ~/.bashrc   # oder: source ~/.zshrc
hermes             # Chat starten

Wer bereits über einen Nous-Portal (öffnet in neuem Tab)-Zugang verfügt, kann laut Dokumentation mit hermes setup --portal in einem Schritt Modell-Zugang und die integrierten Werkzeuge (Websuche, Bildgenerierung, TTS, Cloud-Browser) aktivieren, statt Schlüssel für jeden Dienst einzeln zu hinterlegen.

Installation als dedizierter Dienstbenutzer

Für den produktiven Betrieb auf einem VPS ist ein eigener Systembenutzer statt des persönlichen Logins die sauberere Lösung. Laut Dokumentation braucht dabei nur ein einziger Schritt tatsächlich Root-Rechte: die --with-deps-Installation der von Chromium benötigten Systembibliotheken über Playwright (für die Browser-Automatisierung). Der Installer erkennt laut Dokumentation selbst, ob sudo verfügbar ist, und weicht andernfalls aus – er installiert Chromium dann in den lokalen Cache des Dienstbenutzers und gibt den Befehl aus, den ein Administrator separat ausführen muss.

Der von Nous Research empfohlene Ablauf für Debian/Ubuntu:

1. Einmalig als Administrator mit Sudo-Rechten, die Systembibliotheken für Chromium einrichten:

sudo npx playwright install-deps chromium

2. Als unprivilegierter Dienstbenutzer den regulären Installer ausführen. Wer keine Browser-Automatisierung braucht – etwa auf einem reinen Headless-Server –, kann diesen Schritt laut Dokumentation mit einem Flag überspringen:

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

3. hermes im PATH des Dienstbenutzers verfügbar machen. Systemkonten haben laut Dokumentation oft einen minimalen PATH ohne ~/.local/bin:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc

4. Mit hermes doctor verifizieren. Die Dokumentation nennt hier einen konkreten Stolperstein: Erscheint der Fehler ModuleNotFoundError: No module named 'dotenv', wurde die Repository-Quelldatei mit dem System-Python statt mit dem venv-Launcher (~/.hermes/hermes-agent/venv/bin/hermes) aufgerufen – zu beheben durch den PATH-Eintrag aus Schritt 3.

5. Für den Dauerbetrieb: Lingering aktivieren. Ein Dienst, der als normaler Benutzer-Service läuft, stoppt laut Dokumentation beim Ausloggen und startet nicht automatisch beim Boot, solange nicht Lingering für den Benutzer aktiviert ist:

sudo loginctl enable-linger <dienstbenutzer>

Als systemd-Dienst betreiben

Damit der Agent einen Server-Neustart übersteht und dauerhaft im Hintergrund läuft, bringt Hermes laut Messaging-Dokumentation (öffnet in neuem Tab) einen eigenen Gateway-Prozess mit, der sich als Systemdienst installieren lässt:

hermes gateway install          # Nutzer-Dienst (Linux) / launchd (macOS)
sudo hermes gateway install --system   # Nur Linux: Dienst, der beim Booten startet

hermes gateway start
hermes gateway status

Für Umgebungen, in denen ein Prozess-Hänger unbemerkt bleiben könnte, beschreibt die Dokumentation einen optionalen Watchdog: Läuft der interne Event-Loop von Hermes nicht mehr fristgerecht, startet systemd den Dienst automatisch neu. Aktivieren lässt sich das über ~/.hermes/config.yaml:

gateway:
  systemd_watchdog_seconds: 120

Nach einer solchen Änderung muss laut Dokumentation die Dienstdatei neu erzeugt werden: hermes gateway install --force.

Zugriff über Messenger statt SSH

Der eigentliche Vorteil eines Server-Betriebs zeigt sich erst über die Anbindung an einen Messenger. Laut Messaging-Dokumentation (öffnet in neuem Tab) unterstützt das Gateway über 20 Plattformen, darunter Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Microsoft Teams und E-Mail. Die Einrichtung läuft interaktiv:

hermes gateway setup

Der Assistent führt laut Dokumentation durch die Konfiguration jeder gewünschten Plattform per Pfeiltasten-Auswahl und bietet an, den Gateway-Dienst danach direkt zu starten oder neu zu laden.

Was vor dem produktiven Einsatz wichtig ist

Ein Agent, der eigenständig Befehle auf einem Server ausführt, verdient Aufsicht – das haben wir bereits im Grundsatzbeitrag festgehalten. Für den konkreten Server-Betrieb nennt die Security-Dokumentation (öffnet in neuem Tab) acht Sicherheitsebenen, von der Nutzerautorisierung über die Freigabe gefährlicher Befehle bis zur Container-Isolation. Zwei Punkte sind für einen VPS-Betrieb besonders praxisrelevant:

Freigabemodus für gefährliche Befehle. Über approvals.mode in der Konfigurationsdatei lässt sich einstellen, wie Hermes mit riskanten Shell-Befehlen umgeht: smart (Standard) bewertet das Risiko automatisch und lässt nur unklare Fälle vom Menschen entscheiden, manual fragt immer nach, off schaltet jede Prüfung ab. Für Cron-Jobs, die ohne wartenden Menschen laufen, gibt es laut Dokumentation eine eigene Einstellung cron_mode, die im Zweifel (deny, Standardwert) den riskanten Befehl blockiert, statt ihn im Hintergrund einfach durchzuwinken.

Eine feste Sperrliste, die sich nicht abschalten lässt. Unabhängig vom gewählten Freigabemodus verhindert laut Dokumentation eine sogenannte Hardline-Blockliste bestimmte katastrophale Befehle grundsätzlich – etwa rm -rf / oder das direkte Beschreiben eines physischen Datenträgers mit dd. Diese Sperre greift laut Dokumentation selbst dann, wenn YOLO-Modus aktiv ist oder approvals.mode: off gesetzt wurde.

Wer produktiv auf einem VPS arbeitet, sollte diese Einstellungen vor dem ersten Automatisierungslauf einmal bewusst durchgehen, statt sich auf die Voreinstellungen zu verlassen.

Fazit

Die Installation selbst ist laut Dokumentation in wenigen Minuten erledigt – ein Befehl für den Standardfall, eine überschaubare Schrittfolge für den Betrieb als eigener Dienstbenutzer. Der eigentliche Unterschied zum lokalen Betrieb liegt nicht in der Installation, sondern darin, was danach folgt: ein systemd-Dienst, der Neustarts übersteht, eine Messenger-Anbindung, über die man den Agenten erreicht, ohne sich einzuloggen, und eine bewusste Entscheidung darüber, wie viel Automatisierung ohne Rückfrage laufen darf. Wer diese drei Punkte vor dem produktiven Einsatz klärt, hat den eigentlichen Aufwand hinter sich – nicht der Installationsbefehl selbst.