HarnessRouter selbst hosten: Eine API für Agenten

Was HarnessRouter entfernt

Sie betreiben HarnessRouter Community Edition im Self-Hosting, um mehrere Agent-Harnesses auf einem Server unter Ihrer Kontrolle über eine gemeinsame API anzusprechen. Ein Agent-Harness ist ein Kommandozeilenprogramm, das ein Modell in einer Schleife steuert: Es hält eine Sitzung aufrecht, bearbeitet Dateien, führt Befehle aus und streamt den Fortschritt an denjenigen zurück, der die Aufgabe angefordert hat. Codex, Claude Code und Hermes übernehmen diese Aufgabe jeweils mit eigener Installation, eigenem Format für Zugangsdaten und eigenem Sitzungsmodell. HarnessRouter führt alle drei in einem Container aus und stellt ihnen einen gemeinsamen HTTP-Endpunkt, eine gemeinsame Anmeldung und einen gemeinsamen Secret Store voran.

Das ist der gesamte Ansatz. Die Kosten sollten trotzdem klar benannt werden. Sie fügen Ihrem Server einen Container, eine Anmeldung, ein Volume und einen Upgrade-Pfad hinzu, damit aus mehreren beweglichen Teilen eine Einheit wird. Wenn Sie heute genau ein Harness ausführen, ist diese Einrichtung schlechter als die direkte Installation dieses Harnesses. Dieser Kompromiss wird im letzten Abschnitt behandelt. Lesen Sie ihn daher, bevor Sie die Bereitstellung durchführen.

Alles Folgende wurde gegen den Image-Tag 0.5.5 geprüft, der am 19. August 2026 abgerufen wurde. Das Projekt veröffentlicht an den meisten Tagen neue Tags. Prüfen Sie daher den Tag, den Sie tatsächlich ausführen, statt sich in einem Monat noch auf diese Seite zu verlassen. Die Befehle stammen aus der README des Projekts unter github.com/HarnessRouter/harnessrouter.

Was das Unified Harness Protocol tatsächlich ist

HarnessRouter implementiert das Unified Harness Protocol (UHP), das auf unifiedharnessprotocol.org veröffentlicht ist. UHP beschreibt, wie ein Produkt eine Aufgabe in einem Harness startet, die laufende Aufgabe verfolgt, Sitzungen und Dateien verwaltet und Fehler meldet. Die Spezifikation wird anhand des Datums versioniert. Die am 19. August 2026 gültige Version ist auf 2026-08-11 datiert. Die Website bezeichnet sie als Entwurfsstandard, der „stabil genug für die Verwendung ist und so versioniert wird, dass er sicher geändert werden kann“.

Lesen Sie die Formulierung „offener Standard“ hier genau. Dasselbe Unternehmen verfasst die Spezifikation, stellt die Referenzimplementierung bereit und entwickelt die 52 Prüfungen umfassende Konformitätssuite, die entscheidet, wer konform ist. Das ist bei einem so jungen Protokoll üblich. Die Apache-2.0-Lizenz bedeutet außerdem, dass Sie jeden Teil davon forken können. UHP ist daher noch kein herstellerübergreifender Standard. Betrachten Sie es als aufkommendes Protokoll: nützlich, in Bewegung und so konzipiert, dass Ihr eigener Code ohne vollständige Überarbeitung darauf verzichten kann.

Was Sie vor dem Start benötigen

Docker und ungefähr 4 GB freien Speicherplatz. Außerdem benötigen Sie einen API-Schlüssel von einem Modellanbieter, für den Sie bereits bezahlen. Der Image-Pull umfasst etwa 700 MB. Der verbleibende Speicherplatz wird von den Agent-CLIs und den Arbeitsbereichen belegt, in die sie schreiben. Das Image enthält kein gebündeltes Modell und keinen Testschlüssel. Aufgaben schlagen daher fehl, bis Sie einen Anbieter verbinden. HarnessRouter selbst steht unter der Apache-2.0-Lizenz. Die Agent-CLIs sind von dieser Lizenz nicht abgedeckt. Deshalb werden sie beim ersten Start abgerufen und nicht im Image ausgeliefert.

Self-host HarnessRouter mit einem docker run

docker pull harnessrouter/harnessrouter
docker run -d --name harnessrouter \
  -p 127.0.0.1:3000:3000 \
  -v harnessrouter:/data \
  harnessrouter/harnessrouter

Beobachten Sie anschließend, wie der Container startet. Der erste Start dauert länger. Die Logs zeigen den Grund.

docker logs -f harnessrouter

Während des Starts sehen Sie Zeilen wie diese:

installing Claude Code (Anthropic's terms apply)…
installing Codex (Apache-2.0)…
installing Hermes (check its upstream license before use)…

Warten Sie auf ready on :3000. Diese Installation erfolgt einmal pro Volume. Jeder spätere Start dauert daher nur wenige Sekunden und gibt keine Installationszeilen mehr aus.

Aus diesem Download ergeben sich zwei wichtige Punkte für einen VPS. Erstens benötigt der erste Start ausgehenden Netzwerkzugriff. Das Image ist nicht vollständig eigenständig. Ein System hinter einer Egress-Filterung oder ohne Route nach außen bleibt an dieser Stelle hängen und gibt ready on :3000 nie aus. Der Fehler tritt beim ersten Start auf, nicht bei docker pull. Das ist ein ungünstiger Zeitpunkt, um dies festzustellen. Zweitens installieren Sie Software von Drittanbietern unter deren jeweiligen Bedingungen. Claude Code wird unter den Bedingungen von Anthropic bereitgestellt, für Hermes gelten die Bedingungen des jeweiligen Upstream-Projekts. Prüfen Sie beide, bevor Sie die Software kommerziell einsetzen.

-v harnessrouter:/data erstellt ein benanntes Docker-Volume. Alle dauerhaften Daten liegen in /data: die SQLite-Datenbanken, die gespeicherten Dateien, der Secret-Speicher und die Agent-Arbeitsbereiche. Wenn Sie dieses Volume löschen, löschen Sie die gesamte Instanz, einschließlich der Provider-Schlüssel und aller Transkripte. Sichern Sie das Volume bei gestopptem Container. Beim Kopieren einer SQLite-Datenbank während eines Schreibvorgangs kann eine Datei entstehen, die sich anschließend nicht öffnen lässt. Diese Reihenfolge aus Stoppen und anschließendem Kopieren gilt für jeden zustandsbehafteten Container auf dem System. Die Details unterscheiden sich jedoch je nach Dienst, da PhotoPrism und Immich jeweils eigene Backup-Befehle benötigen.

docker stop harnessrouter
docker run --rm -v harnessrouter:/data -v "$PWD":/backup alpine \
  tar czf /backup/harnessrouter-data.tgz -C / data
docker start harnessrouter

Die Compose-Variante und die zu ändernde Zeile

Das Repository enthält eine Compose-Datei. Sie veröffentlicht "3000:3000" und bindet damit an jede Schnittstelle des Hosts. Ändern Sie diese Zeile, bevor Sie den Stack auf einem öffentlichen Server starten.

services:
  harnessrouter:
    image: harnessrouter/harnessrouter:0.5.5
    ports:
      - "127.0.0.1:3000:3000"
    env_file:
      - .env
    volumes:
      - harnessrouter-data:/data
    restart: unless-stopped

volumes:
  harnessrouter-data:

Zwei Dinge weichen vom Upstream ab: die Bind-Adresse und ein fest gesetzter Versions-Tag anstelle von latest. Das Festlegen der Version ist wichtig, weil zwischen dem 9. und 18. August 2026 sechzehn Version-Tags veröffentlicht wurden. Eine Agent-Laufzeit, die sich ohne Ihr Zutun ändert, ist schwer zu debuggen. Kopieren Sie anschließend die Umgebungsdatei, schränken Sie ihre Berechtigungen ein und starten Sie den Stack.

cp .env.example .env
chmod 600 .env
docker compose up -d
docker compose logs -f

.env enthält Ihren Provider-Schlüssel im Klartext. Daher ist der Modus 600 das Minimum. Falls Ihnen das Unterkommando docker compose nicht vertraut ist, behandelt das Spickzettel für Docker-Compose-Befehle die täglich verwendeten Befehle.

Warum der Port auf 127.0.0.1 und nicht auf 0.0.0.0 veröffentlicht wird

-p 3000:3000 veröffentlicht den Port auf jeder Schnittstelle des Hosts. -p 127.0.0.1:3000:3000 veröffentlicht ihn nur auf dem Loopback-Interface. Der einzige Zugriff ist dann vom VPS selbst möglich. Der Container lauscht intern immer auf Port 3000. Sie ändern daher die linke Seite. Prüfen Sie das Ergebnis:

docker port harnessrouter
sudo ss -ltnp | grep 3000

ss mit der Ausgabe von 127.0.0.1:3000 ist korrekt. 0.0.0.0:3000 bedeutet, dass die Konsole im öffentlichen Internet erreichbar ist. Das ist hier gefährlicher als bei den meisten Self-Hosting-Anwendungen. Die Konsole erstellt Harnesses, liest jedes Transkript, führt Agents aus und stellt diesen Agents eine Shell sowie ein echtes Dateisystem in ihrem Arbeitsbereich bereit. Außerdem enthält sie den hinterlegten Provider-Key. Jeder, der eine ungeschützte Konsole erreicht, kann Ihre Arbeit lesen, Befehle ausführen und Ihren Key verwenden.

Eine Host-Firewall schützt Sie davor nicht. Docker veröffentlicht Ports, indem es eigene Regeln in die Kernel-nat-Tabelle schreibt. Diese Regeln werden ausgewertet, bevor die von ufw verwaltete Chain an der Reihe ist. Deshalb bleibt ein veröffentlichter Port erreichbar, auch wenn sudo ufw status ihn als verweigert aufführt. Testen Sie von einem anderen Rechner aus, nicht vom VPS. Andernfalls testen Sie nichts. Das ist dieselbe Lehre wie beim headless Ausführen von dsh auf Port 3080: Binden Sie den Dienst an das Loopback-Interface und entscheiden Sie anschließend bewusst, wie Sie darauf zugreifen.

Ändern Sie die Standardanmeldung vor allen anderen Schritten

Melden Sie sich unter http://localhost:3000 mit dem Benutzernamen harnessrouter und dem Passwort harnessrouter an. Diese Zugangsdaten stehen in der README, weil sie Platzhalter und keine Geheimnisse sind. Der Container warnt Sie bei jedem Start, bis Sie sie ändern:

using the DEFAULT password. Set HR_AUTH_PASSWORD, or change it from the profile page, before exposing this instance.

Ändern Sie die Zugangsdaten auf der Seite „Profile“, oder setzen Sie sie beim Start für ein skriptgesteuertes Deployment. HR_AUTH_USER und HR_AUTH_PASSWORD überschreiben die Standardwerte.

docker run -d --name harnessrouter \
  -p 127.0.0.1:3000:3000 \
  -v harnessrouter:/data \
  -e HR_AUTH_USER='you' \
  -e HR_AUTH_PASSWORD='the-password-you-chose' \
  harnessrouter/harnessrouter

Es gibt keine E-Mail zum Zurücksetzen, weil es kein Kontosystem und keinen Mailserver gibt. Wenn Sie das Passwort verlieren, löschen Sie die Authentifizierungsdatei im Volume und starten Sie den Container neu. Melden Sie sich anschließend wieder mit den Standardwerten an.

docker stop harnessrouter
docker run --rm -v harnessrouter:/data alpine rm -f /data/selfhost-auth.json
docker start harnessrouter

HR_AUTH_DISABLED=1 entfernt die Anmeldesperre vollständig. In der README ist diese Option auf „ein System, das niemand sonst erreichen kann“ beschränkt. Ein VPS mit einer öffentlichen IP-Adresse ist kein solches System. Lassen Sie die Anmeldesperre daher aktiviert, außer Sie führen die Anwendung auf einem Laptop aus.

Prüfen Sie Ihre Version, denn die alten Versionen haben keine Zugriffssperre

Diesen Teil sollten Sie ernst nehmen. Die Versionen 0.1.x und 0.2.0 wurden vollständig ohne Authentifizierungssperre veröffentlicht: Jeder, der Port 3000 erreichen konnte, hatte bereits Zugriff auf die Konsole. 0.3.0 war die erste Version mit Anmeldung. Diese älteren Tags sind weiterhin veröffentlicht und lassen sich weiterhin abrufen. Ein alter fest gesetzter Tag oder eine von einem Kollegen kopierte Compose-Datei kann daher auch heute eine ungeschützte Konsole an einem öffentlichen Port bereitstellen.

Am 19. August 2026 ist 0.5.5 der neueste veröffentlichte Tag. Er ist auf den 18. August 2026 datiert, und latest verweist auf ihn. Prüfen Sie, welche Version Sie verwenden, und vergleichen Sie sie anschließend mit der Tag-Liste auf Docker Hub:

docker image ls harnessrouter/harnessrouter

Alles unter 0.3.0 sollte sofort ersetzt und nicht erst zur späteren Umstellung eingeplant werden. Für alles ab dieser Version muss das Passwort trotzdem geändert werden, denn für jemanden, der Port 3000 scannt, sind ein Standardpasswort und kein Passwort dasselbe. Behandeln Sie die Versionsnummern auf dieser Seite nicht als aktuell. Sie waren am oben genannten Datum korrekt, und dieses Projekt veröffentlicht schnell neue Versionen.

Provider verbinden

Nichts wird ausgeführt, solange kein Modellanbieter verbunden ist. Fügen Sie auf der Seite Integrations in der Konsole einen Anbieter hinzu oder übergeben Sie ihn in der Umgebung an docker run. Der Wert ist JSON und muss daher in der Shell in Anführungszeichen gesetzt werden:

-e HR_SECRET_GLOBAL_HARNESS_CONN_ANTHROPIC='{"name":"anthropic","provider":"anthropic","api_key":"sk-ant-…"}'

.env.example benennt eine Verbindungsvariable pro Anbieterfamilie: HR_SECRET_GLOBAL_HARNESS_CONN_ANTHROPIC für das claude-code-Backend, HR_SECRET_GLOBAL_HARNESS_CONN_OPENAI für das codex-Backend und HR_SECRET_GLOBAL_HARNESS_CONN_CUSTOM für jeden OpenAI-kompatiblen Endpunkt. Dort wird ein Aggregator oder Ihr eigener Inferenzserver eingetragen. Die zugehörigen Variablen HR_SECRET_GLOBAL_HARNESS_POLICY_CLAUDE, HR_SECRET_GLOBAL_HARNESS_POLICY_CODEX und HR_SECRET_GLOBAL_HARNESS_POLICY_HERMES legen fest, welche Verbindung das jeweilige Backend standardmäßig verwendet. HR_SECRET_KEY ist davon unabhängig und wird nur benötigt, wenn Sie eine Datenbank mit einem Agent verbinden.

HR_BACKENDS legt fest, welche Backends geladen werden, wie in HR_BACKENDS=claude,codex,hermes. Ein bekanntes Problem sollten Sie kennen, bevor es auftritt: Jeder Wert ohne hermes beendet den Container sofort mit Status 1 und ohne Fehlermeldung. Eine Sekunde nach dem Start sehen Sie Exited (1) in docker ps -a, während docker logs keine nützlichen Informationen ausgibt. Lassen Sie hermes in der Liste, bis der Upstream das Problem behebt. Wenn Hermes das einzige von Ihnen gewünschte Harness ist, ist der Betrieb des Hermes-Agenten auf einer eigenen VPS die kleinere Bereitstellung.

Aufrufen der API ohne die Konsole

Die Konsole ist optional. Beide verwenden dieselbe API, die einen Responses-ähnlichen Vertrag verwendet. Melden Sie sich zunächst an, um ein Sitzungscookie zu erhalten:

curl -c hr.cookies http://localhost:3000/api/selfhost/login \
  -H 'content-type: application/json' \
  -d '{"username":"harnessrouter","password":"your-password"}'

Senden Sie anschließend eine Aufgabe. Geben Sie in metadata.harness_id den Harness und ein Modell an, das Ihr verbundener Provider tatsächlich bereitstellt:

curl -s -b hr.cookies http://localhost:3000/api/harness/v1/responses \
  -H 'content-type: application/json' \
  -d '{"input":"Reply with exactly this and nothing else: it works.",
       "metadata":{"harness_id":"codex"},
       "model":"gpt-5.4-mini",
       "stream":false}'

Ein JSON-Objekt mit einem Ausgabe-Block und einer Token-Anzahl bedeutet, dass der Harness ausgeführt wurde. Wenn Sie harness_id von codex in claude ändern, wird dieselbe Anfrage an einen anderen Harness gesendet. Dieser Austausch ist der eigentliche Grund für diese Software. Mit der oben beschriebenen benutzerdefinierten Verbindung verweisen Sie einen Harness auf einen bereits von Ihnen betriebenen OpenAI-kompatiblen Endpunkt, wie dies bei einem selbst gehosteten DeepSeek-Harness auf einem VPS eingerichtet ist.

Erreichen Sie es von Ihrem Laptop aus, ohne einen Port zu veröffentlichen

Dafür gibt es zwei Möglichkeiten. Keine davon öffnet einen Port auf 0.0.0.0.

Ein SSH-Tunnel ist die einfachste Lösung und erfordert keine Installation auf dem Server. Er leitet einen lokalen Port auf Ihrem Rechner an den Loopback des VPS weiter.

ssh -N -L 3000:127.0.0.1:3000 you@your-vps

Lassen Sie den Tunnel geöffnet und rufen Sie http://localhost:3000 im Browser auf. Wenn SSH bind: Address already in use ausgibt, verwendet bereits ein anderer Prozess auf Ihrem Laptop Port 3000. Wählen Sie dann mit -L 3100:127.0.0.1:3000 einen anderen lokalen Port und rufen Sie Port 3100 im Browser auf.

Ein Reverse Proxy mit TLS-Terminierung ist die richtige Lösung, wenn auch andere Personen Zugriff benötigen. Der Proxy verwaltet das TLS-Zertifikat (Transport Layer Security) und leitet Anfragen an den Loopback weiter. Die README enthält eine Caddy-Konfiguration:

console.example.com {
    encode zstd gzip
    reverse_proxy 127.0.0.1:3000 {
        flush_interval -1      # agent turns stream for minutes; never buffer them
    }
}

flush_interval -1 ist die Zeile, die häufig übersehen wird. Agent erzeugt Stream-Tokens über mehrere Minuten. Ein Proxy, der die Antwort puffert, hält diese Tokens bis zum Ende des Durchlaufs zurück. Dadurch wirkt die Konsole eingefroren und gibt anschließend alles auf einmal aus. Das Äquivalent in Nginx ist proxy_buffering off; innerhalb des location-Blocks. Unabhängig von Ihrer Wahl muss der DNS-Name auf den Proxy und der Container auf den Loopback zeigen. Nginx, Caddy und Traefik als Reverse Proxy im Vergleich beschreibt, welcher Proxy zu Ihrem Server passt.

Führen Sie es unter einem eigenen Benutzer aus, nicht als root

Der Docker-Daemon läuft als root. Die Mitgliedschaft in der Gruppe docker entspricht daher root-Rechten, weil ein Mitglied einen Container starten kann, der das Host-Dateisystem einbindet. Wenn Sie also „das Team der Docker-Gruppe hinzufügen“, vergeben Sie root-Rechte auf dem System, auf dem Ihr Provider-Schlüssel liegt.

Die einfache Variante: Erstellen Sie ein Dienstkonto, dem die Compose-Datei und .env gehören. Halten Sie diese Dateien aus gemeinsam genutzten Home-Verzeichnissen heraus.

sudo adduser --disabled-password --gecos "" harness
sudo install -d -o harness -g harness -m 750 /srv/harnessrouter

Die sicherere Variante ist Rootless Docker. Dabei läuft der Daemon selbst unter diesem unprivilegierten Benutzer. Dafür benötigt der Benutzer das Paket uidmap für newuidmap und newgidmap sowie mindestens 65536 untergeordnete UIDs in /etc/subuid und /etc/subgid.

sudo apt install -y uidmap docker-ce-rootless-extras
sudo loginctl enable-linger harness
sudo -iu harness
dockerd-rootless-setuptool.sh install
export DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock
systemctl --user enable --now docker

loginctl enable-linger ist hier nicht optional. Ohne diese Einstellung wird die systemd-Instanz des Benutzers beendet, sobald die letzte Sitzung geschlossen wird. Dadurch wird der Container beendet, wenn Sie sich abmelden. Prüfen Sie das Ergebnis mit docker info. Der Befehl listet rootless unter Security Options auf. Im Rootless-Modus können ohne zusätzliche Konfiguration keine Ports unter 1024 gebunden werden. Das ist hier unerheblich, weil Port 3000 darüber liegt. Die Einrichtung des Kontos selbst wird unter Benutzer mit geringsten erforderlichen Rechten auf einem VPS erstellen beschrieben.

Was fehlschlägt und was Sie sehen

Der Container wird eine Sekunde nach dem Start beendet und die Logs sind leer. docker ps -a zeigt Exited (1). Das ist das oben beschriebene Problem mit HR_BACKENDS: Ihr Wert enthielt hermes nicht. Fügen Sie es wieder hinzu.

Der erste Start wird nie abgeschlossen. Das Log endet nach einer installing-Zeile und ready on :3000 erscheint nie. Der Server kann das Netzwerk nicht erreichen, um die Agent-CLIs abzurufen, weil sie nicht im Image enthalten sind. Korrigieren Sie die ausgehende Route oder die Proxy-Einstellungen und starten Sie den Container anschließend neu.

Die Konsole wird geladen, und jede Aufgabe schlägt fehl. Es ist kein Provider verbunden. Das Image enthält weder ein gebündeltes Modell noch einen kostenlosen Tarif. Eine neue Instanz kann Sie daher anmelden, aber trotzdem keine Aufgaben ausführen.

Die Konsole friert hinter einem Proxy mitten in der Antwort ein. Die Ausgabe erscheint erst in einem Block, wenn der Durchlauf beendet ist. Das wird durch das Puffern der Antwort verursacht. Setzen Sie flush_interval -1 in Caddy oder proxy_buffering off; in Nginx.

Sie können die Anwendung von Ihrem Laptop aus nicht erreichen, obwohl der Tunnel aktiv ist. Führen Sie docker port harnessrouter auf dem Server aus. Wenn keine Ausgabe erscheint, veröffentlicht der Container keinen Port. Er wurde daher ohne -p gestartet.

Lohnt sich der Betrieb?

Der Betrieb lohnt sich, wenn Sie tatsächlich mehr als ein Harness verwenden und statt jeweils drei Endpunkten und drei Credential-Speichern nur einen Endpunkt und einen Credential-Speicher benötigen. Er lohnt sich ebenfalls, wenn Sie darauf ein Produkt aufbauen und das Harness als Konfigurationswert statt als Anlass für eine Überarbeitung behandeln möchten. Genau das ermöglicht UHP, mit dem oben genannten Vorbehalt, dass das Protokoll noch jung ist.

Der Betrieb lohnt sich nicht, wenn Sie nur ein Harness verwenden. Die Installation dieser CLI auf dem Server bedeutet weniger bewegliche Teile, und zwischen Ihnen und dem Harness befindet sich keine Anmeldung. Es ist außerdem die falsche Architektur, wenn mehrere Agents an einer Aufgabe zusammenarbeiten sollen, statt eine API vor mehrere Harnesses zu setzen. Dafür benötigen Sie ein anderes Tool: Siehe ein Multi-Agent-Harness wie Omnigent für dieses Muster. Die Bereitstellungsregeln bleiben in jedem Fall unverändert. Binden Sie an Loopback, ändern Sie das Passwort, verwenden Sie ein festgelegtes Tag bei 0.3.0 oder höher und einen eigenen Benutzer.

FAQ

Ist es sicher, HarnessRouter auf Port 3000 zu veröffentlichen?

Nein. Die Konsole erstellt Harnesses, liest jedes Transkript, führt Agents mit Shell- und Dateisystemzugriff aus und enthält den von Ihnen verbundenen Provider-Key. Ein offener Port legt daher all diese Funktionen offen. Veröffentlichen Sie den Dienst mit -p 127.0.0.1:3000:3000 nur auf dem Loopback-Interface und greifen Sie über einen SSH-Tunnel oder einen Reverse Proxy mit TLS-Terminierung darauf zu. Eine Host-Firewall reicht allein nicht aus: Docker schreibt eigene Regeln in die Kernel-Tabelle nat. Daher antwortet ein veröffentlichter Port aus dem Internet, selbst wenn ufw ihn als verweigert anzeigt. Prüfen Sie dies mit sudo ss -ltnp | grep 3000. Der Befehl sollte 127.0.0.1:3000 ausgeben.

Welche HarnessRouter-Version hat die Anmeldesperre hinzugefügt?

0.3.0. Die Versionen 0.1.x und 0.2.0 wurden vollständig ohne Authentifizierung veröffentlicht. Beide Tags sind weiterhin veröffentlicht und weiterhin abrufbar. Wer sie verwendet, verlässt sich daher darauf, dass niemand den Port findet. Am 19. August 2026 ist der neueste Tag 0.5.5, datiert auf den 18. August 2026. Führen Sie docker image ls harnessrouter/harnessrouter aus, um Ihre Version anzuzeigen. Vergleichen Sie sie mit der Tag-Liste auf Docker Hub und nicht mit dieser Seite. Ändern Sie das Standardpasswort auch bei einer aktuellen Version.

Warum wird der Container direkt beendet, nachdem ich HR_BACKENDS gesetzt habe?

Jeder HR_BACKENDS-Wert, bei dem hermes fehlt, beendet den Container sofort mit Status 1 und ohne Fehlermeldung. Dieses bekannte Problem ist in der README des Projekts dokumentiert. Das Symptom ist Exited (1) in docker ps -a innerhalb von ein oder zwei Sekunden. In docker logs erscheint dabei nichts Brauchbares. Lassen Sie hermes wie in HR_BACKENDS=claude,codex,hermes in der Liste, bis das Upstream-Projekt das Problem behebt.

Benötigt HarnessRouter beim ersten Start Internetzugriff?

Ja. Die Agent-CLIs werden beim ersten Start abgerufen und sind nicht im Image enthalten, weil jede CLI ihre eigene Lizenz mitbringt. Ein System ohne ausgehende Route gibt die installing-Zeilen aus und erreicht anschließend nie ready on :3000. Der Download erfolgt einmal pro Volume. Spätere Starts dauern daher nur wenige Sekunden und benötigen keine Netzwerkverbindung außer zum von Ihnen verbundenen Model-Provider.

Ich habe das Konsolenpasswort verloren. Wie erhalte ich wieder Zugriff?

Es gibt keine E-Mail zum Zurücksetzen, weil es kein Kontensystem und keinen Mailserver gibt. Stoppen Sie den Container, löschen Sie /data/selfhost-auth.json aus dem Volume und starten Sie ihn erneut. Melden Sie sich anschließend mit den Standard-Anmeldedaten an und setzen Sie auf der Seite Profile ein neues Passwort. Wenn Container und Volume beide harnessrouter heißen, lautet die Abfolge docker stop harnessrouter, dann docker run --rm -v harnessrouter:/data alpine rm -f /data/selfhost-auth.json und anschließend docker start harnessrouter.