HarnessRouter: konfiguracja własnego API dla agentów

Co eliminuje HarnessRouter

HarnessRouter Community Edition to rozwiązanie typu self-hosted, które pozwala umieścić jeden interfejs API przed wieloma agentami typu agent harness na własnym serwerze. Agent harness to program wiersza poleceń, który steruje modelem w pętli: utrzymuje sesję, edytuje pliki, wykonuje polecenia i przesyła postępy do podmiotu zlecającego pracę. Codex, Claude Code oraz Hermes realizują to zadanie, przy czym każdy z nich wymaga własnej instalacji, posiada własny format poświadczeń i odmienną definicję sesji. HarnessRouter uruchamia je wszystkie wewnątrz jednego kontenera, udostępniając jeden punkt końcowy HTTP, jeden mechanizm logowania oraz jeden magazyn kluczy.

To cała koncepcja, a koszt tego rozwiązania warto jasno określić. Dodajesz do serwera kontener, mechanizm logowania, wolumen oraz ścieżkę aktualizacji, aby połączyć kilka ruchomych elementów w jeden. Jeśli obecnie używasz dokładnie jednego agenta harness, ta konfiguracja będzie mniej wydajna niż bezpośrednia instalacja tego narzędzia. Ten kompromis opisano w ostatniej sekcji, dlatego należy się z nim zapoznać przed wdrożeniem.

Wszystkie poniższe informacje zweryfikowano dla tagu obrazu 0.5.5, pobranego 19 sierpnia 2026. Projekt publikuje nowe tagi niemal codziennie, dlatego należy sprawdzić tag faktycznie używanej wersji, zamiast polegać na treści tej strony po miesiącu. Polecenia pochodzą z pliku README projektu dostępnego pod adresem github.com/HarnessRouter/harnessrouter.

Czym w rzeczywistości jest Unified Harness Protocol

HarnessRouter implementuje Unified Harness Protocol (UHP), opublikowany pod adresem unifiedharnessprotocol.org. UHP opisuje sposób, w jaki produkt uruchamia zadanie w ramach harness, monitoruje jego przebieg, zarządza sesjami i plikami oraz raportuje awarie. Specyfikacja jest wersjonowana według daty. Wersja obowiązująca w dniu 19 sierpnia 2026 r. nosi datę 2026-08-11, a witryna określa ją mianem standardu roboczego, „wystarczająco stabilnego do budowania rozwiązań, wersjonowanego w sposób umożliwiający bezpieczne wprowadzanie zmian”.

Należy uważnie interpretować określenie „otwarty standard”. Ta sama firma tworzy specyfikację, implementację referencyjną oraz zestaw 52 testów zgodności, które decydują o tym, kto spełnia wymogi. Jest to typowe dla protokołu na tak wczesnym etapie rozwoju, a licencja Apache-2.0 umożliwia fork dowolnej jego części. Oznacza to również, że UHP nie jest jeszcze standardem wielodostawcowym. Należy traktować go jako protokół wschodzący: użyteczny, dynamiczny i taki, z którego własny kod powinien móc zrezygnować bez konieczności przepisywania całości.

Wymagania wstępne

Docker oraz około 4 GB wolnego miejsca na dysku. Wymagany jest również klucz API od dostawcy modelu, za którego usługi uiszczana jest opłata. Obraz zajmuje około 700 MB, a pozostałe miejsce jest przeznaczone na CLI agentów oraz obszary robocze, w których zapisują one dane. Obraz nie zawiera wbudowanego modelu ani klucza próbnego, dlatego zadania kończą się niepowodzeniem do momentu połączenia z dostawcą. HarnessRouter jest udostępniany na licencji Apache-2.0. CLI agentów nie podlegają tej licencji, dlatego są pobierane przy pierwszym uruchomieniu, zamiast być dostarczanymi wewnątrz obrazu.

Uruchamianie HarnessRouter za pomocą jednego polecenia docker run

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

Następnie monitoruj uruchamianie kontenera. Pierwszy start trwa długo, a dziennik zdarzeń wyjaśnia przyczynę.

docker logs -f harnessrouter

Podczas pracy zobaczysz linie podobne do poniższych:

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

Poczekaj na ready on :3000. Instalacja ta odbywa się raz na wolumen, więc każde kolejne uruchomienie zajmuje kilka sekund i nie generuje żadnych linii dotyczących instalacji.

Z tego pobierania wynikają dwa fakty, oba istotne w przypadku VPS. Po pierwsze, pierwsze uruchomienie wymaga dostępu do sieci zewnętrznej. Obraz nie jest samowystarczalny, więc serwer za filtrem ruchu wychodzącego lub bez trasy wyjściowej zawiesi się w tym miejscu i nigdy nie wyświetli ready on :3000. Proces kończy się niepowodzeniem przy pierwszym starcie, a nie przy docker pull, co jest mylącym momentem na wykrycie problemu. Po drugie, instalujesz oprogramowanie stron trzecich na warunkach tych stron. Claude Code podlega warunkom Anthropic, a Hermes warunkom swojego dostawcy, więc sprawdź oba przed komercyjnym wykorzystaniem.

-v harnessrouter:/data tworzy nazwany wolumen Docker. Wszystkie trwałe dane znajdują się w /data: bazy danych SQLite, zapisane pliki, magazyn kluczy oraz obszary robocze agenta. Usunięcie tego wolumenu oznacza usunięcie instancji, w tym kluczy dostawcy i wszystkich transkrypcji. Wykonuj kopię zapasową przy zatrzymanym kontenerze, ponieważ kopiowanie bazy danych SQLite w trakcie zapisu może skutkować plikiem, którego nie da się otworzyć. Ta sama zasada zatrzymania przed kopiowaniem dotyczy każdego kontenera stanowego na serwerze, choć szczegóły różnią się w zależności od usługi, ponieważ PhotoPrism i Immich wymagają własnych poleceń tworzenia kopii zapasowych.

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

Wariant compose oraz linia wymagająca zmiany

Repozytorium dostarcza plik compose. Publikuje on "3000:3000", co oznacza wszystkie interfejsy na hoście. Zmień tę linię przed uruchomieniem usługi na publicznym serwerze.

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:

Dwie rzeczy różnią się od wersji upstream: adres powiązania (bind address) oraz przypięty tag wersji zamiast latest. Przypinanie wersji jest istotne, ponieważ między 9 a 18 sierpnia 2026 wydano szesnaście tagów wersji, a środowisko uruchomieniowe agenta, które zmienia się w trakcie pracy, jest trudne w debugowaniu. Następnie skopiuj plik środowiskowy, zablokuj jego uprawnienia i uruchom usługę.

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

.env przechowuje klucz dostawcy w postaci czystego tekstu, więc tryb 600 jest minimum. Jeśli podkomenda docker compose jest nieznana, ściąga poleceń Docker Compose zawiera codzienne operacje.

Dlaczego port jest publikowany na 127.0.0.1, a nie na 0.0.0.0

-p 3000:3000 publikuje port na każdym interfejsie dostępnym na hoście. -p 127.0.0.1:3000:3000 publikuje go wyłącznie na interfejsie zwrotnym (loopback), co oznacza, że jedyną drogą dostępu jest połączenie bezpośrednio z poziomu VPS. Kontener zawsze nasłuchuje na porcie 3000 wewnątrz, więc modyfikacji podlega lewa strona zapisu. Sprawdź bieżącą konfigurację:

docker port harnessrouter
sudo ss -ltnp | grep 3000

ss wyświetlenie 127.0.0.1:3000 jest poprawne. 0.0.0.0:3000 oznacza, że konsola jest wystawiona na publiczny Internet. W tym przypadku jest to bardziej ryzykowne niż w większości aplikacji self-hosted, ponieważ konsola tworzy środowiska uruchomieniowe, odczytuje wszystkie transkrypty, uruchamia agentów oraz zapewnia im dostęp do powłoki i rzeczywistego systemu plików w ich obszarze roboczym. Przechowuje ona również klucz dostawcy, który został użyty do połączenia. Każdy, kto uzyska dostęp do niezabezpieczonej konsoli, może odczytać Twoją pracę, wykonywać polecenia i zużywać Twój klucz.

Firewall hosta nie chroni przed tym zagrożeniem. Docker publikuje porty poprzez wpisywanie własnych reguł bezpośrednio do tablicy nat jądra systemu, a reguły te są sprawdzane przed łańcuchem zarządzanym przez ufw. W rezultacie opublikowany port pozostaje osiągalny nawet wtedy, gdy sudo ufw status wskazuje, że dostęp jest zabroniony. Testy należy przeprowadzać z innej maszyny, a nie z poziomu VPS, w przeciwnym razie wynik testu będzie niemiarodajny. Jest to ta sama lekcja, co w przypadku uruchamiania dsh headless na porcie 3080: powiąż usługę z interfejsem zwrotnym, a następnie świadomie zdecyduj, w jaki sposób będziesz uzyskiwać do niej dostęp.

Zmiana domyślnych danych logowania przed wykonaniem jakichkolwiek innych czynności

Zaloguj się pod adresem http://localhost:3000, używając nazwy użytkownika harnessrouter oraz hasła harnessrouter. Te dane uwierzytelniające są podane w pliku README, ponieważ pełnią rolę symboli zastępczych, a nie poufnych haseł. Kontener wyświetla ostrzeżenie przy każdym uruchomieniu, dopóki dane te nie zostaną zmienione:

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

Zmiany można dokonać na stronie profilu (Profile) lub ustawić dane w momencie uruchamiania w przypadku wdrożeń skryptowych. Zmienne HR_AUTH_USER oraz HR_AUTH_PASSWORD nadpisują wartości domyślne.

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

Funkcja resetowania hasła przez e-mail nie istnieje, ponieważ system nie posiada obsługi kont ani serwera pocztowego. W przypadku utraty hasła należy usunąć plik autoryzacji w wolumenie i zrestartować kontener, a następnie ponownie zalogować się przy użyciu danych domyślnych.

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

Zmienna HR_AUTH_DISABLED=1 całkowicie usuwa bramkę logowania. W pliku README zaznaczono, że rozwiązanie to jest przeznaczone dla „urządzeń, do których nikt inny nie ma dostępu”. Serwer VPS z publicznym adresem IP nie spełnia tego warunku, dlatego należy pozostawić bramkę włączoną, chyba że usługa jest uruchamiana na komputerze przenośnym.

Sprawdź wersję, ponieważ starsze wydania nie posiadają bramki uwierzytelniania

To jest etap wymagający szczególnej uwagi. Wersje 0.1.x oraz 0.2.0 zostały wydane całkowicie bez bramki uwierzytelniania: każda osoba, która mogła uzyskać dostęp do portu 3000, miała bezpośredni dostęp do konsoli. Wersja 0.3.0 była pierwszym wydaniem wprowadzającym logowanie. Starsze tagi są nadal publikowane i możliwe do pobrania, więc użycie starego przypiętego taga lub pliku compose skopiowanego od współpracownika może skutkować wystawieniem niezabezpieczonej konsoli na publicznym porcie.

Na dzień 19 sierpnia 2026 najnowszym opublikowanym tagiem jest 0.5.5, datowany na 18 sierpnia 2026, a latest wskazuje właśnie na niego. Sprawdź posiadaną wersję, a następnie porównaj ją z listą tagów w serwisie Docker Hub:

docker image ls harnessrouter/harnessrouter

Wszystkie wersje poniżej 0.3.0 należy wymienić natychmiast, bez odkładania tego zadania w czasie. W przypadku wersji równej lub wyższej nadal konieczna jest zmiana hasła, ponieważ dla osoby skanującej port 3000 domyślne hasło jest równoznaczne z jego brakiem. Nie należy traktować numerów wersji na tej stronie jako aktualnych. Były one poprawne w dniu wskazanym na górze, a projekt ten rozwija się dynamicznie.

Podłączanie dostawcy

Nic nie zadziała, dopóki nie zostanie podłączony dostawca modelu. Należy dodać go na stronie Integrations w konsoli lub przekazać do docker run w środowisku. Wartość jest w formacie JSON, więc należy ująć ją w cudzysłów w powłoce:

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

.env.example definiuje jedną zmienną połączenia dla każdej rodziny dostawców: HR_SECRET_GLOBAL_HARNESS_CONN_ANTHROPIC dla backendu claude-code, HR_SECRET_GLOBAL_HARNESS_CONN_OPENAI dla backendu codex oraz HR_SECRET_GLOBAL_HARNESS_CONN_CUSTOM dla dowolnego punktu końcowego zgodnego z OpenAI, gdzie kierowany jest agregator lub własny serwer wnioskowania. Odpowiadające im zmienne HR_SECRET_GLOBAL_HARNESS_POLICY_CLAUDE, HR_SECRET_GLOBAL_HARNESS_POLICY_CODEX oraz HR_SECRET_GLOBAL_HARNESS_POLICY_HERMES określają, którego połączenia domyślnie używa dany backend. HR_SECRET_KEY to osobny element, wymagany wyłącznie w przypadku łączenia bazy danych z agentem.

HR_BACKENDS wybiera, które backendy mają zostać załadowane, tak jak w HR_BACKENDS=claude,codex,hermes. Warto znać jeden znany problem, zanim wystąpi: każda wartość, która pomija hermes, powoduje natychmiastowe wyjście kontenera ze statusem 1 bez komunikatu o błędzie. W docker ps -a sekundę po uruchomieniu widoczny jest komunikat Exited (1), a docker logs nie pokazuje żadnych przydatnych informacji. Należy pozostawić hermes na liście, dopóki problem nie zostanie rozwiązany w upstreamie. Jeśli Hermes jest jedynym wymaganym środowiskiem, uruchomienie agenta Hermes na własnym VPS stanowi mniejsze wdrożenie.

Wywoływanie API bez użycia konsoli

Konsola jest opcjonalna. To samo API obsługuje oba interfejsy i korzysta z kontraktu w stylu Responses. Najpierw należy się zalogować, aby uzyskać plik cookie sesji:

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

Następnie należy wysłać zadanie, wskazując środowisko testowe w metadata.harness_id oraz model faktycznie udostępniany przez podłączonego dostawcę:

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}'

Obiekt JSON zawierający blok wyjściowy oraz liczbę tokenów oznacza, że środowisko testowe zostało uruchomione. Zmiana harness_id z codex na claude powoduje wysłanie tego samego żądania do innego środowiska testowego, a ta możliwość zamiany jest głównym powodem istnienia tego oprogramowania. Powyższe niestandardowe połączenie pozwala wskazać środowisko testowe dla punktu końcowego zgodnego z OpenAI, który jest już hostowany, w sposób opisany w samodzielnie hostowanym środowisku testowym DeepSeek na VPS.

Dostęp z laptopa bez publikowania portu

Istnieją dwa sposoby, z których żaden nie wymaga otwierania surowego portu na 0.0.0.0.

Tunel SSH jest najprostszym rozwiązaniem i nie wymaga instalacji żadnego dodatkowego oprogramowania na serwerze. Przekierowuje on lokalny port na Twoim komputerze do interfejsu loopback na VPS.

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

Pozostaw to polecenie uruchomione i otwórz http://localhost:3000 w przeglądarce. Jeśli SSH wyświetli błąd bind: Address already in use, oznacza to, że port 3000 jest już zajęty na Twoim laptopie. Wybierz inny lokalny port za pomocą -L 3100:127.0.0.1:3000 i przejdź do portu 3100.

Terminujący reverse proxy jest rozwiązaniem, gdy dostęp mają uzyskać inne osoby. Proxy obsługuje certyfikat TLS (transport layer security) i przekazuje ruch do interfejsu loopback. Plik README zawiera przykładową konfigurację dla Caddy:

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 to linijka, o której często zapominają użytkownicy. Agent generuje tokeny strumieniowe przez kilka minut, a proxy, które buforuje odpowiedź, przetrzymuje te tokeny do momentu zakończenia generowania. W efekcie konsola wydaje się zawieszona, a następnie wyświetla całą treść naraz. Odpowiednikiem w Nginx jest proxy_buffering off; umieszczone wewnątrz bloku location. Niezależnie od wyboru, nazwa DNS powinna wskazywać na proxy, a kontener powinien działać na interfejsie loopback. Porównanie Nginx, Caddy i Traefik jako reverse proxy zawiera informacje o tym, które rozwiązanie najlepiej sprawdzi się w Twoim środowisku.

Uruchamianie jako dedykowany użytkownik, a nie jako root

Daemon Docker działa z uprawnieniami roota, a członkostwo w grupie docker jest równoważne z posiadaniem uprawnień roota, ponieważ członek grupy może uruchomić kontener montujący system plików hosta. Zatem „dodanie zespołu do grupy docker” oznacza przyznanie uprawnień roota na maszynie, na której przechowywany jest klucz dostawcy.

Wersja uproszczona: należy utworzyć konto serwisowe, które będzie właścicielem pliku compose oraz .env, a następnie przechowywać te pliki poza jakimkolwiek współdzielonym katalogiem domowym.

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

Wersja bardziej rygorystyczna to rootless Docker, w której sam daemon działa jako użytkownik bez uprawnień administracyjnych. Wymaga to pakietu uidmap dla newuidmap i newgidmap, a także co najmniej 65536 podrzędnych identyfikatorów UID w plikach /etc/subuid oraz /etc/subgid dla danego użytkownika. Pakiet uidmap znajduje się w repozytoriach Ubuntu, ale docker-ce-rootless-extras nie: jest on dostarczany z własnego repozytorium apt firmy Docker pod adresem download.docker.com, które jest dodawane podczas instalacji silnika Docker. Jeśli silnik nie został zainstalowany z tego repozytorium, polecenie grep -rl download.docker.com /etc/apt/sources.list.d/ nie zwróci żadnych wyników, a poniższa instalacja nie znajdzie pakietu.

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

Opcja loginctl enable-linger nie jest tutaj opcjonalna. Bez niej instancja systemd użytkownika zatrzymuje się po zamknięciu ostatniej sesji, co powoduje wyłączenie kontenera w momencie wylogowania. Wynik należy potwierdzić za pomocą docker info, które wyświetla rootless w sekcji Security Options. Tryb rootless nie może wiązać portów poniżej 1024 bez dodatkowej konfiguracji, co w tym przypadku nie ma znaczenia, ponieważ port 3000 znajduje się powyżej tej wartości. Konfiguracja samego konta została opisana w tworzeniu użytkowników z minimalnymi uprawnieniami na VPS.

Co ulega awarii i co zobaczysz

Kontener wyłącza się sekundę po uruchomieniu, a logi są puste. docker ps -a pokazuje Exited (1). Jest to problem HR_BACKENDS opisany powyżej: w Twojej wartości pominięto hermes. Przywróć ją.

Pierwsze uruchomienie nigdy się nie kończy. Log zatrzymuje się po linii installing, a ready on :3000 nigdy się nie pojawia. Maszyna nie może połączyć się z siecią, aby pobrać CLI agenta, ponieważ nie ma ich w obrazie. Napraw trasę wychodzącą lub ustawienia proxy, a następnie zrestartuj usługę.

Konsola ładuje się, ale każde zadanie kończy się niepowodzeniem. Żaden dostawca nie jest połączony. W obrazie nie ma wbudowanego modelu ani darmowego planu, więc świeża instancja pozwala na zalogowanie, ale nie może niczego uruchomić.

Konsola zawiesza się w trakcie generowania odpowiedzi za proxy. Dane wyjściowe pojawiają się w jednym bloku dopiero po zakończeniu tury. Jest to efekt buforowania odpowiedzi. Ustaw flush_interval -1 w Caddy lub proxy_buffering off; w Nginx.

Nie można uzyskać dostępu z laptopa, mimo że tunel działa. Uruchom docker port harnessrouter na serwerze. Jeśli polecenie nic nie zwraca, kontener nie publikuje żadnych portów, co oznacza, że został uruchomiony bez -p.

Czy warto to uruchamiać?

Warto to uruchamiać, jeśli faktycznie używasz więcej niż jednego narzędzia typu harness i potrzebujesz jednego punktu końcowego oraz jednego magazynu poświadczeń zamiast trzech dla każdego z nich. Warto to również uruchomić, jeśli budujesz na tym produkt i chcesz, aby harness był wartością konfiguracyjną, a nie wymagał przepisywania kodu. To właśnie zapewnia UHP, przy zastrzeżeniu wspomnianym powyżej, dotyczącym wczesnego etapu rozwoju tego protokołu.

Nie warto tego uruchamiać, jeśli używasz tylko jednego narzędzia typu harness. Instalacja tego CLI na serwerze oznacza mniej ruchomych elementów, a między użytkownikiem a narzędziem nie znajduje się żaden proces logowania. Jest to również niewłaściwe rozwiązanie, jeśli celem jest współpraca kilku agentów przy jednym zadaniu, a nie jedno API przed kilkoma harnessami; do tego służy inne narzędzie: zobacz wieloagentowy harness, taki jak Omnigent. Niezależnie od wyboru, zasady wdrażania pozostają niezmienne. Powiązanie z interfejsem loopback, zmienione hasło, przypięty tag w wersji 0.3.0 lub nowszej oraz dedykowany użytkownik.

FAQ

Czy publikowanie HarnessRouter na porcie 3000 jest bezpieczne?

Nie. Konsola tworzy harnessy, odczytuje wszystkie transkrypty, uruchamia agentów z dostępem do powłoki i systemu plików oraz przechowuje klucz dostawcy, który został podłączony. Otwarty port wystawia te wszystkie elementy na ryzyko. Należy publikować usługę na interfejsie loopback za pomocą -p 127.0.0.1:3000:3000 i uzyskiwać do niej dostęp przez tunel SSH lub odwrotne proxy z terminacją TLS. Sam firewall hosta nie wystarcza: Docker samodzielnie zapisuje reguły w tablicy nat jądra systemu, więc opublikowany port odpowiada na zapytania z Internetu, nawet jeśli ufw wskazuje na odmowę dostępu. Należy to zweryfikować za pomocą sudo ss -ltnp | grep 3000, co powinno zwrócić 127.0.0.1:3000.

W której wersji HarnessRouter dodano bramkę logowania?

0.3.0. Wersje 0.1.x oraz 0.2.0 zostały wydane bez żadnego mechanizmu uwierzytelniania. Oba tagi są nadal opublikowane i możliwe do pobrania, więc każdy, kto ich używa, polega wyłącznie na tym, że nikt nie odkryje otwartego portu. Według stanu na 19 sierpnia 2026 najnowszym tagiem jest 0.5.5, datowany na 18 sierpnia 2026. Należy uruchomić docker image ls harnessrouter/harnessrouter, aby sprawdzić posiadaną wersję, porównać ją z listą tagów w serwisie Docker Hub (zamiast polegać na tej stronie) oraz zmienić domyślne hasło, nawet w aktualnej wersji.

Dlaczego kontener wyłącza się natychmiast po ustawieniu HR_BACKENDS?

Każda wartość HR_BACKENDS, która pomija hermes, powoduje natychmiastowe wyjście z kontenera ze statusem 1 bez komunikatu o błędzie. Jest to znany problem opisany w pliku README projektu. Objawem jest Exited (1) w docker ps -a w ciągu sekundy lub dwóch oraz brak użytecznych informacji w docker logs. Należy zachować hermes na liście, tak jak w HR_BACKENDS=claude,codex,hermes, dopóki problem nie zostanie rozwiązany w głównej gałęzi projektu.

Czy HarnessRouter wymaga dostępu do Internetu przy pierwszym uruchomieniu?

Tak. Pliki wykonywalne CLI agentów są pobierane przy pierwszym uruchomieniu zamiast być dostarczanymi wewnątrz obrazu, ponieważ każdy z nich posiada własną licencję. Maszyna bez trasy wyjściowej wyświetli linie installing i nigdy nie osiągnie stanu ready on :3000. Pobieranie odbywa się raz na wolumen, więc kolejne uruchomienia trwają kilka sekund i nie wymagają sieci poza połączeniem z dostawcą modelu.

Utracono hasło do konsoli. Jak odzyskać dostęp?

Nie istnieje funkcja resetowania hasła przez e-mail, ponieważ system nie posiada kont użytkowników ani serwera pocztowego. Należy zatrzymać kontener, usunąć /data/selfhost-auth.json z wolumenu, uruchomić go ponownie, a następnie zalogować się przy użyciu domyślnych danych uwierzytelniających i ustawić nowe hasło na stronie profilu. Przy kontenerze i wolumenie o nazwie harnessrouter, należy wykonać docker stop harnessrouter, następnie docker run --rm -v harnessrouter:/data alpine rm -f /data/selfhost-auth.json, a na końcu docker start harnessrouter.