Vitalij Bojatschkin

Hermes Agent selbst hosten: Installation auf Proxmox (LXC), Automationen und Betrieb

Hermes Agent auf Proxmox im LXC-Container installieren: Gateway, Telegram, Dashboard, Backup und Update, plus Docker-Alternative und Betriebsfallen.

Veröffentlicht: 2026-09-07. Aktualisiert: 2026-10-12.

Das Wichtigste in Kürze

Hermes Agent ist ein selbst gehosteter KI-Agent von Nous Research unter MIT-Lizenz, der modell-agnostisch arbeitet: Provider und Modell sind eine Konfigurationszeile, kein Umbau.
Auf Proxmox läuft Hermes bei mir nativ in einem LXC-Container mit Ubuntu 22.04, 2 Kernen und 8 GB zugewiesenem RAM, von denen im Betrieb rund 3 GB belegt sind. Installiert wird über das offizielle Skript, gesichert per vzdump mit getesteter Wiederherstellung.
Der eigentliche Unterschied zur Coding-CLI ist der Gateway: der Agent läuft dauerhaft auf einem Server und ist über Telegram, Discord, Slack oder Signal erreichbar, nicht nur im Terminal.
Der wirtschaftliche Hebel liegt nicht im Chat, sondern im Cron-Scheduler — wiederkehrende Auswertungen, die ohne Aufforderung laufen und ihr Ergebnis dorthin liefern, wo man ohnehin liest.
Ein Agent ohne Zugriff auf den eigenen Wissensstand bleibt ein besserer Chatbot. Der Kontext-Kanal ist die Arbeit, die den Nutzen erzeugt.
Die teuerste Betriebseigenschaft ist der stille Ausfall: ein geplanter Job, der scheitert und niemanden informiert, ist schlimmer als kein Job.

Hermes Agent ist ein selbst gehosteter KI-Agent von Nous Research, quelloffen unter MIT-Lizenz und nicht an einen Modellanbieter gebunden. Er läuft dauerhaft auf eigener Hardware, ist über Telegram, Discord, Slack oder Signal erreichbar und bringt einen eigenen Cron-Scheduler mit, der Aufgaben unbeaufsichtigt ausführt. Der Nutzen entsteht dabei nicht im Chat, sondern in den wiederkehrenden Auswertungen, die niemand mehr anstoßen muss. Dieser Artikel zeigt die Installation auf Proxmox im LXC-Container Schritt für Schritt, die Docker-Alternative, die Automationen, die sich in meinem eigenen Betrieb bewährt haben, und die drei Fallen, die mich dabei echte Zeit gekostet haben.

Was Hermes Agent ist — und was er nicht ist

Hermes Agent kommt von Nous Research und steht unter MIT-Lizenz auf GitHub. Er ist kein Coding-Assistent im Sinne von Claude Code oder Codex, auch wenn sich die Werkzeugkästen überschneiden. Der Unterschied liegt im Betriebsmodell: Eine Coding-CLI startet man, arbeitet damit und beendet sie. Hermes läuft durch.

Daraus folgt fast alles andere. Ein Prozess, der durchläuft, kann auf Nachrichten reagieren, ohne dass ein Terminal offen ist. Er kann geplante Aufgaben ausführen. Er kann sich zwischen zwei Sitzungen an etwas erinnern. Und er kann — das ist die unangenehme Kehrseite — auch dann etwas tun, wenn gerade niemand hinschaut.

Modellseitig legt Hermes nichts fest. Nous Portal, OpenRouter, OpenAI-kompatible Endpunkte oder ein eigener Inferenz-Server sind gleichwertige Optionen, der Wechsel läuft über hermes model. Wer die Grundsatzfrage zwischen eigenem Betrieb und Managed Service noch nicht entschieden hat, findet die ehrliche Rechnung dazu in meinem Vergleich KI lokal hosten oder als Managed Service beziehen.

LXC, VM oder Docker?

Auf Proxmox gibt es drei naheliegende Wege, und keiner ist für jedes Setup richtig:

Variante	Isolation	Aufwand	Passt, wenn …
LXC-Container	teilt den Kernel des Hosts	gering, wenig RAM	der Agent in einem abgegrenzten Homelab läuft und der Zugriff anderswo eingeschränkt ist
VM	eigener Kernel	höher	der Agent Shell-Zugriff auf sensible Systeme bekommt oder Fremde ihm schreiben können
Docker	Container-Isolation	gering, wenn Docker schon läuft	ein Docker-Host oder VPS schon existiert

Ich betreibe Hermes nativ in einem LXC-Container: Ubuntu 22.04, 2 Kerne, 8 GB RAM zugewiesen, im Betrieb rund 3 GB belegt. Docker innerhalb des Containers wäre eine zweite Container-Schicht ohne Gewinn. Das ist eine bewusste Abwägung für mein Homelab. Für einen Agenten, der auf Unternehmenssysteme zugreift, ist eine VM die vertretbarere Wahl; die Gründe stehen in meiner OpenClaw-Anleitung.

Hermes Agent auf Proxmox installieren

Schritt 1: Container anlegen

Das Template holen Sie mit pveam, den Container legen Sie auf dem Proxmox-Host an. Die Werte sind ein Beispiel; ID, Speicher und Netzwerk passen Sie an Ihre Umgebung an:

pveam update
pveam available --section system | grep ubuntu
pveam download local ubuntu-22.04-standard_22.04-1_amd64.tar.zst

pct create 110 local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst \
  --hostname hermes --cores 2 --memory 4096 --swap 1024 \
  --rootfs local-lvm:16 --net0 name=eth0,bridge=vmbr0,ip=dhcp \
  --unprivileged 1 --onboot 1
pct start 110
pct enter 110

--unprivileged 1 bildet root im Container auf einen unprivilegierten Nutzer des Hosts ab. Das ist der sicherere Standard für einen Agenten mit Shell-Zugriff.

Schritt 2: Voraussetzungen installieren

Das offizielle Installationsskript braucht unter Linux nur curl, git und xz-utils. Python, uv, Node.js, ripgrep und ffmpeg bringt es selbst mit:

apt update && apt upgrade -y
apt install -y curl git xz-utils

Schritt 3: Hermes Agent installieren

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

Der Befehl lädt ein externes Skript und führt es aus. Prüfen Sie dessen Inhalt und Herkunft vorab. Beginnen Sie ohne produktive Schlüssel; die Installation allein ist keine Sicherheitsprüfung.

Als root installiert, liegt der Code unter /usr/local/lib/hermes-agent/, der Befehl unter /usr/local/bin/hermes und alle Daten unter /root/.hermes/. Mit einem eigenen Nutzer landen die Daten in dessen ~/.hermes/.

Eine Abkürzung, die ich nicht wiederholen würde: Beim ersten Aufsetzen habe ich Hermes als Python-Paket über uv tool install installiert, weil Ubuntu 22.04 ein zu altes Python mitbringt. Das lief, ist aber kein offiziell unterstützter Weg: Updates bedeuteten danach eine Neuinstallation. Das Skript bringt sein eigenes Python mit und macht den Umweg überflüssig.

Schritt 4: Modell und Werkzeuge einrichten

Danach führen vier Befehle zu einem arbeitsfähigen Zustand:

hermes setup     # Assistent: Provider, Modell, Werkzeuge, Messaging
hermes model     # Modell und Provider einzeln wechseln
hermes tools     # Werkzeuge gezielt an- und abschalten
hermes doctor    # Diagnose, wenn etwas nicht greift

hermes setup fragt alles ab, was für den ersten Lauf nötig ist. Wer die Sammlung einzelner API-Schlüssel für Modell, Websuche, Bildgenerierung und Sprachausgabe vermeiden will, kann mit hermes setup --portal stattdessen Nous Portal anbinden; die eigenen Schlüssel bleiben pro Werkzeug weiter möglich.

Kommen Sie von OpenClaw? Dann ist der Weg kürzer, als er aussieht. Der Setup-Assistent erkennt eine vorhandene ~/.openclaw-Installation und bietet die Übernahme von sich aus an. Nachträglich geht das auch:

hermes claw migrate --dry-run   # zeigt nur an, was übernommen würde
hermes claw migrate             # übernimmt Persona, Memories, Skills, Freigaben

Übernommen werden Persona-Datei, Memories, selbst erstellte Skills, die Freigabe-Muster für Befehle, Messaging-Einstellungen und ausgewählte API-Schlüssel. Wer sein OpenClaw-Setup nach meiner Proxmox-Anleitung abgesichert hat, behält die dortigen Grundsätze bei: Isolation, Firewall, kein offener Port ins Internet, Freigaben nur für explizit erlaubte Befehle. Die Härtung gilt für Hermes unverändert — der Agent hat dieselbe Klasse von Zugriff.

Schritt 5: Gateway einrichten und als Dienst starten

hermes gateway setup              # Telegram, Discord, Slack, Signal …
hermes gateway install --system   # als systemd-Dienst, startet mit dem Container

Für Telegram landen Bot-Token und die erlaubten Nutzer-IDs in /root/.hermes/.env:

TELEGRAM_BOT_TOKEN=...
TELEGRAM_ALLOWED_USERS=123456789

Die Liste der erlaubten Nutzer ist keine Formalität. Ohne sie kann jeder, der den Bot findet, einem Agenten mit Shell-Zugriff Aufträge geben.

Schritt 6: Dashboard nur mit Anmeldung erreichbar machen

hermes dashboard startet eine Weboberfläche auf 127.0.0.1:9119. Bindet man sie an eine andere Adresse, verlangt Hermes eine Anmeldung. Bei mir läuft das Dashboard als eigener systemd-Dienst und ist nur über einen Reverse Proxy mit vorgeschalteter Anmeldung aus dem Heimnetz erreichbar, nicht aus dem Internet.

Schritt 7: Backup und Update

Alles, was Hermes ausmacht, liegt in einem Verzeichnis: Konfiguration, Schlüssel, Sitzungen, Memories, Skills und Cron-Jobs unter /root/.hermes/. Auf Proxmox sichere ich deshalb den ganzen Container täglich mit vzdump. Eine Sicherung zählt erst, wenn die Wiederherstellung einmal geprobt wurde; bei mir stimmte der wiederhergestellte Stand Byte für Byte mit dem laufenden überein.

Vor jedem Update lege ich einen Snapshot an, weil ein Update schon einmal mittendrin hängen geblieben ist:

# auf dem Proxmox-Host
pct snapshot 110 vor-update

# im Container
hermes update --backup
hermes doctor

Achten Sie beim Backup-Skript auf die Reihenfolge: Bei mir lief der Container einmal voll, weil das Aufräumen alter Sicherungen erst nach einem Fehlerabbruch gekommen wäre und deshalb nie lief.

Alternative: Hermes Agent mit Docker

Ohne Proxmox, etwa auf einem VPS mit Docker, beschreibt die offizielle Docker-Anleitung zwei Befehle:

mkdir -p ~/.hermes
docker run -it --rm -v ~/.hermes:/opt/data nousresearch/hermes-agent setup

docker run -d --name hermes --restart unless-stopped \
  -v ~/.hermes:/opt/data -p 8642:8642 \
  nousresearch/hermes-agent gateway run

Port 8642 ist eine OpenAI-kompatible API mit Health-Endpunkt; öffnen Sie ihn nicht ungeschützt nach außen. Dasselbe ~/.hermes darf nie in zwei Container gleichzeitig eingebunden werden.

Wer zwischen Hermes und OpenClaw noch schwankt, findet die Unterschiede in Hermes Agent vs. OpenClaw.

Der Gateway ist der eigentliche Unterschied

hermes gateway startet einen Prozess, der den Agenten an Messaging-Plattformen hängt: Telegram, Discord, Slack, WhatsApp, Signal. Ab da ist der Agent kein Terminalprogramm mehr, sondern ein Kontakt.

Das klingt nach Bequemlichkeit und ist in Wahrheit der Punkt, an dem die Nutzung kippt. Ein Werkzeug, für das ich ein Terminal öffnen, in ein Verzeichnis wechseln und einen Befehl tippen muss, benutze ich, wenn ich ohnehin am Rechner arbeite. Ein Werkzeug, das in derselben App liegt, in der ich ohnehin lese, benutze ich unterwegs, abends und zwischendurch. Die Zahl der tatsächlichen Anfragen unterscheidet sich in meinem Betrieb deutlich zwischen beiden Zuständen.

Für den Dauerbetrieb gehört der Gateway hinter einen Dienst-Manager, nicht in eine Terminal-Sitzung. Unter Linux heißt das eine systemd-Unit mit Restart=always. Genau daran hängt später Falle Nummer zwei.

Die Automationen, die sich wirklich lohnen

Der Cron-Scheduler ist der Teil, der aus einem Chat-Werkzeug ein Arbeitsmittel macht. Jobs werden in natürlicher Sprache beschrieben, laufen unbeaufsichtigt und liefern ihr Ergebnis an eine gewählte Plattform.

Vier Muster haben sich in meinem eigenen Betrieb gehalten:

Das tägliche Briefing. Ein Job liest abends Feeds und Nachrichtenquellen, gleicht sie gegen den aktuellen Stand meiner Projekte ab und liefert eine sortierte Einordnung: was heute zählt, was auf dem Radar bleibt, was Rauschen ist. Der Wert liegt im dritten Teil. Eine Zusammenfassung von zwanzig Meldungen kann jeder Feed-Reader; die Entscheidung, dass achtzehn davon für meinen Stack irrelevant sind, braucht Kontext über meinen Stack.

Die Link-Pipeline. Alle zwei Stunden werden gesammelte Links abgearbeitet — Videos transkribiert, Artikel eingeordnet, alles gegen eine Qualitätsprüfung geschickt und abgelegt. Das ersetzt den Stapel offener Tabs, den man sonst am Wochenende durchgeht und meistens eben nicht durchgeht.

Der Fristwächter. Ein Job pro Monat, der eine wiederkehrende Compliance-Frist prüft und eine Nachricht schickt. Technisch trivial, wirtschaftlich einer der wertvollsten Jobs überhaupt, weil vergessene Fristen teuer sind und Kalendererinnerungen abstumpfen.

Der wöchentliche Rückblick. Ein Job, der die Arbeitsprotokolle der Woche liest und daraus einen Bericht erzeugt: was ist entschieden worden, was liegt fest, was ist offen geblieben. Das ist die Aufgabe, die man sich vornimmt und nie macht.

Das Muster hinter allen vieren ist dasselbe: wiederkehrend, klar abgegrenzt, mit einem Ergebnis, das dort landet, wo ohnehin gelesen wird. Aufgaben ohne diese drei Eigenschaften taugen nicht als Automation — sie werden zu Benachrichtigungen, die man wegwischt.

Ohne Kontext bleibt es ein besserer Chatbot

Der Punkt, an dem die meisten Setups stehen bleiben: Der Agent kennt das eigene Umfeld nicht. Er weiß nicht, woran gearbeitet wird, was letzten Monat entschieden wurde und welche Systeme im Einsatz sind. Damit kann er allgemein antworten und sonst wenig.

In meinem Setup spiegelt ein Sync-Skript die Wissensverzeichnisse aller Projekte auf die Maschine, auf der der Agent läuft, zusammen mit einem Volltextindex. Der Agent sucht damit in derselben Datenbank wie ich. Der Rückweg ist getrennt: Was der Agent erzeugt, landet in einem eigenen Export-Verzeichnis und wird von dort abgeholt — er schreibt nicht in meine Quellen.

Diese Trennung ist keine Förmlichkeit. Ein Sync mit --delete in die falsche Richtung löscht in Sekunden, was der Agent nie hätte anfassen dürfen. Wer Kontext bereitstellt, sollte vorher festlegen, welche Richtung schreiben darf und welche nur liest.

Drei Fallen, die mich Zeit gekostet haben

Erstens: der unbeaufsichtigte Schlüssel. Ein Sync-Job braucht einen SSH-Schlüssel ohne Passphrase. Genau dieser Schlüssel ist dann der schwächste Punkt im Setup, wenn er auf ein Root-Login zeigt. Die Lösung ist ein Forced Command im authorized_keys-Eintrag, der den Schlüssel auf genau eine Operation in genau einem Verzeichnis festnagelt. Danach ist die Gegenprobe Pflicht: Jeder andere Befehl über diesen Schlüssel muss abgewiesen werden, und man muss das einmal wirklich ausprobiert haben.

Zweitens: die Systemd-Unit ohne Laufzeitumgebung. Der Gateway lief bei mir als System-Unit und startete Kindprozesse über einen systemd-Scope. Nach einem Update begann jeder agent-gestützte Cron-Job zu scheitern, mit einer Meldung über einen nicht verfügbaren User-Scope. Ursache war eine einzige fehlende Umgebungsvariable: Eine System-Unit erbt kein XDG_RUNTIME_DIR, und ohne die findet der Aufruf den User-Manager nicht. Interaktiv über SSH funktionierte derselbe Befehl einwandfrei — deshalb dauerte die Diagnose. Der Test, der es entschieden hat, war die Gegenprobe mit einer bewusst leergeräumten Umgebung:

env -i HOME=/root USER=root PATH=/usr/bin:/bin systemd-run --user --scope true
# scheitert – wie im Dienst

env -i HOME=/root USER=root PATH=/usr/bin:/bin \
  XDG_RUNTIME_DIR=/run/user/0 systemd-run --user --scope true
# läuft

Merksatz: Wenn etwas in der Shell geht und im Dienst nicht, ist es fast immer die Umgebung — und die vergleicht man am schnellsten, indem man sie absichtlich zerstört.

Drittens, und das ist die teuerste: der stille Ausfall. Derselbe Defekt hat einen Job 24 Mal hintereinander scheitern lassen, ohne dass irgendwo eine Warnung entstanden wäre. Der Job schrieb in ein Log, das niemand liest. Ein geplanter Job, der scheitert und schweigt, ist schlechter als gar kein Job: Man verlässt sich auf ein Ergebnis, das nicht mehr kommt.

Die Gegenmaßnahme, die bei mir funktioniert, ist unspektakulär: Die Warnung wird in die Datei geschrieben, die ohnehin gelesen wird — oben, vor den Inhalt. Wenn das Briefing älter als die erlaubte Frist ist, steht der Hinweis darauf im Briefing selbst. Ein Log, das man aktiv aufrufen muss, erreicht niemanden. Wer Automationen betreibt, braucht für jeden Job die Antwort auf eine Frage: Woran merke ich, dass dieser Job seit einer Woche nicht mehr läuft? Fällt die Antwort nicht in einem Satz, fehlt die Überwachung.

Wann sich das lohnt — und wann nicht

Es lohnt sich, wenn es wiederkehrende Auswertungen gibt, die heute niemand macht, weil sie zu klein für einen Termin und zu lästig für den Feierabend sind. Es lohnt sich, wenn der Kontext im Haus liegt und nicht in ein öffentliches Werkzeug soll. Und es lohnt sich, wenn jemand da ist, der den Betrieb übernimmt — ein Agent ist ein laufender Dienst mit allem, was dazugehört.

Es lohnt sich nicht als Selbstzweck. Ein selbst gehosteter Agent, der einmal die Woche eine Frage beantwortet, ist ein teurer Chatbot. Und es lohnt sich nicht ohne geklärten Datenweg: Welche Daten der Agent sieht, wohin sie zur Inferenz gehen und wer im Fehlerfall verantwortet, gehört vor die Installation, nicht danach. Einen Einstieg dazu gibt mein Leitfaden zu DSGVO-konformer KI.

Was gehört zu einer Hermes-Integration im Unternehmen?

Eine Installation ist noch kein einsatzfähiger Unternehmensprozess. Die ausführliche Fassung mit Agentenwahl und Kosten steht in OpenClaw und Hermes Agent im Unternehmen. Vor dem produktiven Einsatz lege ich mit Ihnen fest:

Daten und Identitäten: Welche Quellen sind freigegeben, welches Konto greift darauf zu und wohin gehen die Daten zur Modellverarbeitung? Self-Hosting des Agenten bedeutet nicht automatisch lokale Inferenz.
Aktionen und Freigaben: Darf der Agent nur lesen und Entwürfe erstellen oder auch schreiben? Externe Nachrichten und Änderungen an Kundendaten brauchen einen definierten Freigabeweg.
Abnahme: Welche bekannten Fälle muss der Workflow richtig bearbeiten? Was passiert bei fehlendem Kontext, verweigertem Zugriff oder einem nicht verfügbaren Modell?
Betrieb und Übergabe: Wer erhält Fehlermeldungen, begrenzt Kosten und kann den Dienst stoppen oder wiederherstellen? Tests und Betriebsanleitung gehören zur Übergabe.

Ein mögliches Ziel ist ein Unternehmens-PersonalOS: Hermes verarbeitet abgegrenzte Aufgaben auf Basis einer kontrollierten gemeinsamen Kontextschicht. Claude Code und Codex können bei der Entwicklung derselben Lösung eingesetzt werden. Die Auswahl folgt dem vereinbarten Prozess, nicht einer möglichst langen Tool-Liste.

Wie ich dabei unterstütze

Ich betreibe dieses Setup selbst, im Alltag, mit allem was daran kaputtgeht. Das ist der Grund, warum ich es anbiete — und auch der Grund, warum ich ehrlich sagen kann, wo der Aufwand liegt.

Es gibt zwei sinnvolle Einstiege:

Sie haben eine konkrete Automation im Kopf. Ein wiederkehrender Prozess, der heute manuell läuft, oder ein bestimmter Ablauf, den ein Agent übernehmen soll. Dann sind Umfang und Weg meist schon klar genug, um direkt zu bauen: Einrichtung, Anbindung an Ihre Systeme, der Job selbst, die Überwachung dazu und eine dokumentierte Übergabe.

Sie haben eine Idee, aber keinen belastbaren Umfang. Das ist der häufigere Fall und der Grund, warum es die Produkt-Discovery gibt: ein Festpreis, an dessen Ende ein Scope-Dokument steht — Ziel, Nutzer, benötigte Daten und Integrationen, technische Richtung, Risiken und ein belastbares Folgeangebot. Bei Bedarf mit einem begrenzten Proof of Concept, der die zentrale Annahme prüft, statt sie zu behaupten. Die Discovery-Gebühr wird auf ein anschließendes Projekt vollständig angerechnet.

Was danach kommt, ist die eigentliche KI-Produktentwicklung — in abgegrenzten, einzeln beschriebenen Abschnitten bis zu Livegang und Übergabe. Wenn Sie danach Weiterentwicklung oder Betriebsunterstützung brauchen, ist das ein separater Auftrag und keine automatische Bindung.

Kostenloses Erstgespräch buchen

Weiterlesen

Hermes Agent vs. OpenClaw — Unterschiede bei Sicherheit, Memory, Skills und Kanälen
Mein KI-Assistent im Homelab — Erfahrungsbericht: Hermes mit PersonalOS im Alltag, Freigaben und Fehler
OpenClaw auf Proxmox sicher selbst hosten — Isolation, Firewall und Prompt-Injection-Schutz für Agenten mit Shell-Zugriff
KI lokal hosten oder AWS Bedrock — wann sich eigener Betrieb rechnet und wann nicht
MCP-Server entwickeln: Leitfaden — eigene Werkzeuge an einen Agenten anbinden

Häufige Fragen

Was ist Hermes Agent und wie unterscheidet er sich von einem Chatbot?

Hermes Agent ist ein Open-Source-KI-Agent von Nous Research (MIT-Lizenz), der auf eigener Hardware läuft und Werkzeuge aufruft: Dateien lesen und schreiben, Shell-Befehle ausführen, HTTP-Anfragen stellen, Skills starten. Ein Chatbot antwortet; ein Agent führt aus. Der Unterschied ist weniger das Modell als der Zugriff auf ein System — und damit auch das Risiko.

Welches Modell braucht Hermes Agent?

Keines fest vorgegebenes. Hermes ist provider-agnostisch und arbeitet unter anderem mit Nous Portal, OpenRouter, OpenAI-kompatiblen Endpunkten und eigenen Inferenz-Servern. Der Wechsel läuft über 'hermes model' ohne Codeänderung. Für dauerhaft laufende Automationen ist eine Fallback-Kette sinnvoll, weil Anbieterausfälle real sind.

Läuft Hermes Agent in einem LXC-Container oder braucht es eine VM?

Technisch läuft er in beidem. Für einen Agenten mit Shell-Zugriff ist eine VM die vertretbarere Wahl, weil LXC-Container den Kernel des Hosts teilen. Ich betreibe ihn in einem LXC-Container und habe den Zugriff dafür an anderer Stelle eingeschränkt — das ist eine bewusste Abwägung, keine Empfehlung für jedes Setup.

Wie installiere ich Hermes Agent auf Proxmox?

Einen LXC-Container oder eine VM mit Ubuntu anlegen, curl, git und xz-utils installieren, dann das offizielle Skript ausführen: curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash. Danach hermes setup für Provider und Modell, hermes gateway setup für Telegram oder Discord und hermes gateway install --system für den Dauerbetrieb. Vor jedem Update einen Snapshot anlegen.

Läuft Hermes Agent auch in Docker?

Ja. Nous Research stellt das Image nousresearch/hermes-agent bereit; die Daten liegen in einem gemounteten Verzeichnis unter /opt/data. Auf Proxmox brauche ich Docker nicht, weil der LXC-Container bereits die Isolationsschicht ist. Docker lohnt sich, wenn Hermes auf einem vorhandenen Docker-Host oder VPS laufen soll.

Kann ich von OpenClaw zu Hermes Agent migrieren?

Ja. Hermes bringt einen eigenen Migrationspfad mit: 'hermes claw migrate' übernimmt Persona-Datei, Memories, selbst erstellte Skills, Freigabe-Muster für Befehle, Messaging-Einstellungen und ausgewählte API-Schlüssel. Der Setup-Assistent erkennt eine vorhandene OpenClaw-Installation und bietet die Übernahme von sich aus an. 'hermes claw migrate --dry-run' zeigt vorher, was passieren würde.

Was kostet Hermes Agent?

Hermes Agent selbst kostet nichts: Er ist quelloffen unter MIT-Lizenz. Bezahlt werden zwei Posten. Erstens Hardware oder VPS — bei mir reicht ein LXC-Container mit 2 Kernen und 8 GB zugewiesenem RAM, von denen im Betrieb rund 3 GB belegt sind. Zweitens die Modellkosten beim gewählten Anbieter. Sie hängen davon ab, wie viele Automationen wie oft laufen und wie groß ihr Kontext ist, und sind der Posten, der ohne Beobachtung überrascht. Ein belastbarer Kostenrahmen entsteht erst, wenn die konkreten Automationen feststehen.

Welche Alternativen gibt es zu Hermes Agent?

Die bekannteste ist OpenClaw, ebenfalls ein selbst gehosteter Agent mit Messaging-Anbindung. Die Unterschiede bei Sicherheit, Memory, Skills und Kanälen sowie den Migrationsweg beschreibe ich im Vergleich Hermes Agent vs. OpenClaw. Wer keinen dauerhaft laufenden Agenten braucht, kommt mit einer Coding-CLI wie Claude Code oder Codex aus.