HarnessRouter: jak uruchomić własne API dla agentów AI

Co eliminuje HarnessRouter

HarnessRouter Community Edition to rozwiązanie typu self-hosted, które pozwala umieścić jeden interfejs API przed wieloma agentami typu 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 osobnej 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.

Taka jest główna idea tego rozwiązania, a koszt jego wdrożenia warto wyraźnie podkreślić. Dodajesz do serwera kontener, mechanizm logowania, wolumen oraz ścieżkę aktualizacji, aby scalić kilka ruchomych elementów w jeden. Jeśli obecnie korzystasz tylko z jednego harnessa, taka konfiguracja jest mniej efektywna niż bezpośrednia instalacja tego narzędzia. Analiza tego kompromisu znajduje się w ostatniej sekcji, dlatego należy się z nią zapoznać przed przystąpieniem do wdrożenia.

Wszystkie poniższe informacje zweryfikowano dla obrazu o tagu 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 błędy. 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, by na nim budować, i 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 tak wczesnego etapu rozwoju protokołu, a licencja Apache-2.0 pozwala na fork dowolnej jego części. Oznacza to również, że UHP nie jest jeszcze standardem wielodostawczym. 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 już płacisz. Pobierany obraz zajmuje około 700 MB, a pozostałe miejsce jest przeznaczone na CLI agentów oraz przestrzenie 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ępniony na licencji Apache-2.0. CLI agentów nie podlegają tej licencji, dlatego są pobierane przy pierwszym uruchomieniu, zamiast być dostarczane 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 należy monitorować uruchamianie kontenera. Pierwszy start trwa długo, a dziennik zdarzeń wyjaśnia przyczynę.

docker logs -f harnessrouter

Podczas pracy widoczne będą 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)…

Należy poczekać na ready on :3000. Instalacja ta odbywa się jednorazowo dla każdego wolumenu, więc każde kolejne uruchomienie zajmuje kilka sekund i nie generuje żadnych komunikatów o instalacji.

Z tego pobierania wynikają dwa fakty, które mają znaczenie na serwerze VPS. Po pierwsze, pierwsze uruchomienie wymaga dostępu do sieci zewnętrznej. Obraz nie jest samowystarczalny, więc serwer znajdujący się 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 miejscem na wykrycie problemu. Po drugie, instalowane jest oprogramowanie stron trzecich na warunkach tych stron. Claude Code podlega warunkom firmy Anthropic, a Hermes warunkom swojego dostawcy, dlatego przed użyciem komercyjnym należy sprawdzić oba zestawy zasad.

-v harnessrouter:/data tworzy nazwany wolumen Docker. Wszystkie trwałe dane znajdują się w /data: bazy danych SQLite, przechowywane pliki, magazyn kluczy oraz obszary robocze agenta. Usunięcie tego wolumenu oznacza usunięcie instancji, w tym kluczy dostawcy i wszystkich transkrypcji. Kopię zapasową należy wykonać 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 i linia wymagająca zmiany

Repozytorium zawiera 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ęta wersja zamiast latest. Przypinanie wersji jest istotne, ponieważ między 9 a 18 sierpnia 2026 wydano szesnaście wersji, a środowisko uruchomieniowe agenta, które zmienia się w sposób niekontrolowany, jest trudne w debugowaniu. Następnie skopiuj plik środowiskowy, zabezpiecz 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 jawnej, więc tryb 600 jest wartością minimalną. Jeśli podkomenda docker compose jest nieznana, ściąga poleceń Docker Compose zawiera zestawienie najczęściej używanych operacji.

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świetlające 127.0.0.1:3000 jest poprawne. 0.0.0.0:3000 oznacza, że konsola jest dostępna z publicznego Internetu. W tym przypadku jest to bardziej ryzykowne niż w większości aplikacji self-hosted, ponieważ konsola tworzy środowiska uruchomieniowe, odczytuje wszystkie transkrypcje, uruchamia agentów oraz zapewnia im dostęp do powłoki i rzeczywistego systemu plików w ich obszarze roboczym. Przechowuje również klucz dostawcy, który został podłączony. 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, wpisując własne reguły do tabeli jądra nat, a są one oceniane przed łańcuchem zarządzanym przez ufw, więc 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 test nie będzie miarodajny. Jest to ta sama lekcja, co w przypadku uruchamiania dsh w trybie headless na porcie 3080: powiąż usługę z interfejsem loopback, a następnie podejmij świadomą decyzję o sposobie uzyskiwania do niej dostępu.

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 haseł zabezpieczających. 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ć je 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

System nie przewiduje resetowania hasła przez e-mail, ponieważ nie zaimplementowano systemu kont ani serwera pocztowego. W przypadku utraty hasła należy usunąć plik autoryzacji w wolumenie i zrestartować kontener, a następnie zalogować się ponownie 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

Flaga HR_AUTH_DISABLED=1 całkowicie usuwa bramkę logowania. W pliku README zaznaczono, że rozwiązanie to jest przeznaczone wyłącznie dla „środowiska, do którego 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 lokalnym.

Sprawdź wersję, ponieważ starsze wydania nie posiadają mechanizmu autoryzacji

To jest etap, który należy potraktować poważnie. Wersje 0.1.x oraz 0.2.0 zostały wydane całkowicie bez mechanizmu autoryzacji: każda osoba, która uzyskała 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 tagu 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 tag 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 w czasie. W przypadku wersji równej lub wyższej nadal konieczna jest zmiana hasła, ponieważ domyślne hasło oraz jego brak są dla osoby skanującej port 3000 tożsame. Nie należy traktować numerów wersji podanych na tej stronie jako aktualnych. Były one poprawne w dniu wskazanym na górze, a projekt ten charakteryzuje się szybkim cyklem wydawniczym.

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 w powłoce należy ująć ją w cudzysłów:

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

.env.example określa jedną zmienną połączenia dla 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ą, z którego połączenia domyślnie korzysta 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 wyświetla żadnych przydatnych informacji. Należy zachować hermes na liście, dopóki problem nie zostanie rozwiązany w upstreamie. Jeśli Hermes jest jedynym wymaganym mechanizmem, uruchomienie agenta Hermes na własnym VPS stanowi mniejszą konfigurację wdrożeniową.

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 harness w metadata.harness_id oraz model faktycznie udostępniany przez połą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 harness został uruchomiony. Zmiana harness_id z codex na claude wysyła to samo żądanie do innego harnessa, a ta możliwość zamiany jest głównym powodem istnienia tego oprogramowania. Powyższe niestandardowe połączenie służy do wskazywania harnessowi punktu końcowego zgodnego z OpenAI, który jest już hostowany, w sposób opisany w samodzielnie hostowany harness DeepSeek na VPS.

Dostęp z laptopa bez publikowania portu

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

Tunel SSH jest najprostszym rozwiązaniem i nie wymaga instalacji dodatkowego oprogramowania na serwerze. Przekierowuje on lokalny port na maszynie użytkownika na interfejs loopback serwera VPS.

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

Pozostaw to połączenie aktywne i otwórz http://localhost:3000 w przeglądarce. Jeśli SSH zwróci błąd bind: Address already in use, oznacza to, że port 3000 jest już zajęty na laptopie. Należy wówczas wybrać inny port lokalny za pomocą -L 3100:127.0.0.1:3000 i przejść pod adres 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 na interfejs 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 linia, o której często zapominają użytkownicy. Agent przesyła tokeny strumieniowo przez kilka minut, a proxy, które buforuje odpowiedź, przetrzymuje te tokeny do momentu zakończenia transmisji. Powoduje to, że konsola wydaje się zawieszona, a następnie wyświetla całą zawartość naraz. Odpowiednikiem w Nginx jest proxy_buffering off; umieszczone w 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 danej konfiguracji.

Uruchamianie jako dedykowany użytkownik, a nie root

Demon Docker działa z uprawnieniami roota, a przynależność do grupy docker jest równoważna 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 demon 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.

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 jest w tym przypadku obowiązkowa. 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ć poleceniem docker info, które wyświetla rootless w sekcji Security Options. Tryb rootless nie pozwala na wiązanie portów poniżej 1024 bez dodatkowej konfiguracji, co w tym przypadku nie ma znaczenia, ponieważ port 3000 znajduje się powyżej tego zakresu. Konfiguracja samego konta została opisana w tworzenie użytkowników z minimalnymi uprawnieniami na VPS.

Co ulega awarii i co zobaczysz

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

Pierwsze uruchomienie nigdy się nie kończy. Dziennik zatrzymuje się po linii installing, a ready on :3000 nigdy się nie pojawia. Maszyna nie może połączyć się z siecią, aby pobrać pliki wykonywalne agenta, ponieważ nie znajdują się one w obrazie. Należy naprawić trasę wyjściową lub ustawienia proxy, a następnie zrestartować usługę.

Konsola ładuje się, ale każde zadanie kończy się niepowodzeniem. Żaden dostawca nie jest podłączony. W obrazie nie ma wbudowanego modelu ani darmowego planu, więc nowa 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. Należy ustawić flush_interval -1 w Caddy lub proxy_buffering off; w Nginx.

Brak dostępu z laptopa mimo aktywnego tunelu. Uruchom docker port harnessrouter na serwerze. Jeśli polecenie nie zwraca żadnych danych, kontener nie publikuje żadnych portów, co oznacza, że został uruchomiony bez flagi -p.

Czy warto to uruchamiać?

Uruchomienie jest zasadne, jeśli faktycznie używa się więcej niż jednego mechanizmu (harness) i wymagany jest jeden punkt końcowy oraz jeden magazyn poświadczeń zamiast trzech osobnych dla każdego z nich. Warto to również wdrożyć w przypadku budowania produktu w oparciu o to rozwiązanie, gdy pożądane jest traktowanie mechanizmu jako wartości konfiguracyjnej, a nie elementu wymagającego przebudowy kodu. To właśnie zapewnia UHP, przy uwzględnieniu wspomnianego wcześniej zastrzeżenia dotyczącego wczesnego etapu rozwoju tego protokołu.

Uruchomienie nie jest zasadne, jeśli używany jest tylko jeden mechanizm. Instalacja odpowiedniego CLI bezpośrednio na serwerze oznacza mniej ruchomych elementów, a między użytkownikiem a narzędziem nie znajduje się żadna warstwa logowania. Rozwiązanie to nie sprawdzi się również w sytuacji, gdy celem jest współpraca kilku agentów przy jednym zadaniu, zamiast jednego API obsługującego kilka mechanizmów. W takim przypadku należy skorzystać z innego narzędzia: zobacz wieloagentowy mechanizm, taki jak Omnigent. Niezależnie od wyboru, zasady wdrażania pozostają niezmienne. Powiązanie z interfejsem zwrotnym (loopback), zmienione hasło, przypięty tag w wersji 0.3.0 lub nowszej oraz dedykowane konto użytkownika.

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, więc otwarty port naraża wszystkie te zasoby. 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 reverse proxy z terminacją TLS. Sam firewall hosta jest niewystarczający: Docker zapisuje własne reguły bezpośrednio w tablicy nat jądra systemu, więc opublikowany port odpowiada na żądania z Internetu, nawet jeśli ufw wskazuje na jego zablokowanie. Należy zweryfikować stan za pomocą sudo ss -ltnp | grep 3000, co powinno zwrócić 127.0.0.1:3000.

W której wersji HarnessRouter dodano bramkę logowania?

W 0.3.0. Wersje 0.1.x oraz 0.2.0 zostały wydane bez żadnego mechanizmu uwierzytelniania, a 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. Na dzień 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 Docker Hub, a nie z tą stroną, oraz zmienić domyślne hasło nawet w aktualnej wersji.

Dlaczego kontener kończy działanie natychmiast po ustawieniu HR_BACKENDS?

Każda wartość HR_BACKENDS, która pomija hermes, powoduje natychmiastowe wyjście kontenera ze statusem 1 bez komunikatu o błędzie, co jest znanym problemem opisanym w pliku README projektu. Objawem jest Exited (1) w docker ps -a w ciągu sekundy lub dwóch oraz brak przydatnych 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 przez twórców.

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, a następnie nigdy nie osiągnie 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, który został skonfigurowany.

Utraciłem 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, 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.