Hermes Agent pod Dockerem: instalacja i utwardzanie przetestowane

„Hermes Agent” porównywany z OpenClaw w 2026 to ten od Nous Research: zainstalowany i utwardzony pod Dockerem w izolowanym laboratorium, bez wpisanego klucza ani identyfikatora, z dwoma nieudokumentowanymi ustawieniami sieciowymi, które trzeba znać przed jego udostępnieniem.

Hermes Agent pod Dockerem: instalacja i utwardzanie przetestowane
Szybka odpowiedź

„Hermes Agent” porównywany z OpenClaw w polskich wyszukiwaniach to ten od Nous Research (NousResearch/hermes-agent, licencja MIT), nie klient webowy hermes-webui ani społecznościowy indeks „HermesHub”. Zainstalowany i utwardzony pod Dockerem w izolowanym laboratorium, bez wpisanego klucza ani identyfikatora, uruchamia się w 17 do 19 sekund do rzeczywiście pozytywnego punktu kontroli stanu. Dwa nieudokumentowane ustawienia do poznania przed udostępnieniem: internal: true odcina też opublikowany port, nie tylko wyjście do internetu, a bramka domyślnie nasłuchuje tylko na własnej pętli lokalnej, nawet za portem już ograniczonym do 127.0.0.1 po stronie hosta.

„Hermes agent” i „hermes vs openclaw” regularnie wracają w polskich wyszukiwaniach, ale nazwa jest niejednoznaczna: kilka projektów nazywa się Hermes. Tylko jeden jest porównywany z OpenClaw w źródłach datowanych na 2026 rok. Jest tu zidentyfikowany, zainstalowany i utwardzony pod Dockerem w izolowanym laboratorium, rozróżniając na każdym etapie to, co naprawdę zostało uruchomione, od tego, co pozostaje udokumentowane.

Który dokładnie Hermes Agent?

Projekt, o który chodzi w tych wyszukiwaniach, to Hermes Agent, rozwijany przez Nous Research i publikowany na licencji MIT w repozytorium NousResearch/hermes-agent, . Repozytorium pokazywało 242 851 gwiazdek i 49 953 forków 7 września 2026, przy utworzeniu 22 lipca 2025. Jego opis mieści się w jednym zdaniu: „the agent that grows with you”. Jeden agent, który tworzy i dopracowuje własne umiejętności na podstawie doświadczenia, w przeciwieństwie do platformy orkiestrującej wielu agentów. Ta różnica filozofii wraca w porównaniach publikowanych w 2026 wobec OpenClaw i potwierdza, że za zapytaniami „hermes vs openclaw” stoi właśnie ten projekt.

Dwie pułapki nazewnictwa, których trzeba unikać. hermes-webui to zewnętrzny klient webowy, nieutrzymywany przez Nous Research. „HermesHub” oznacza społecznościowy indeks umiejętności, odrębny od oficjalnego huba wbudowanego w CLI. Oba łatwo pomylić z głównym projektem w wynikach wyszukiwania. Hermes Agent dołącza zresztą do listy, którą nasz przegląd agentów kodu w linii poleceń porównuje między sobą.

Zainstalować Hermes Agent z Dockerem

Oficjalny obraz to nousresearch/hermes-agent. Dokumentacja Docker opisuje interaktywnego asystenta konfiguracji, a potem uruchomienie jako usługi:

bash
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

Laboratorium poniżej nie korzysta z tego interaktywnego asystenta: przechodzi bezpośrednio przez utwardzony compose, który odtwarza gateway run na innej sieci i innych portach. Port 8642 służy jednocześnie jako punkt kontroli stanu i bramka kompatybilna z API OpenAI, port 9119, opcjonalny, służy do tablicy webowej. Wolumin zamontowany na /opt/data zawiera .env, config.yaml, SOUL.md, a także foldery sessions/, memories/ i skills/. Dokumentacja zaleca od 1 do 4 GB pamięci i od 1 do 2 rdzeni, zależnie od użycia.

Przypiąłem ostatnią wersję z datą zamiast latest. Wydania na GitHubie wskazują v0.21.0 (tag v2026.8.31, „The Pantheon Release”), opublikowaną 31 sierpnia 2026, około 5 800 commitów i 760 kontrybutorów po poprzedniej wersji. Pobranie zajęło 1 min 47 s na tej maszynie za 908 MB skompresowanych (3,93 GB po dekompresji, architektura arm64). Obraz v2026.4.30, 8,2 GB, umiejscawia prawdziwą zmianę architektury wewnętrznej między kwietniem a majem 2026. Ten punkt kontrolny wciąż startuje na tini, podczas gdy sierpniowa wersja używa s6-overlay jako PID 1, z porzuceniem uprawnień na rzecz użytkownika hermes (domyślnie UID 10000). Ciekawostka odnotowana przy okazji: rejestr Docker Hub pokazuje, że rozmiar obrazu spadł z około 2,5 GB w kwietniu do poniżej 900 MB od lipca 2026.

Utwardzić konfigurację: sieć, porty, sekrety

Oficjalny docker-compose.yml deklaruje network_mode: host zarówno dla bramki, jak i dla tablicy, wygodne, ale bez żadnej izolacji sieciowej. Dla laboratorium zbudowałem utwardzoną wersję: dedykowana sieć, porty publikowane wyłącznie na pętli lokalnej, sekrety poza plikiem compose.

yaml
services:
  hermes:
    image: nousresearch/hermes-agent:v2026.8.31
    container_name: hermes-lab
    networks:
      - hermes_lab
    ports:
      - "127.0.0.1:8642:8642"
      - "127.0.0.1:9119:9119"
    volumes:
      - ./data:/opt/data
    env_file:
      - ./secrets/hermes.env     # ewentualny klucz dostawcy, poza repozytorium
    environment:
      - HERMES_UID=501
      - HERMES_GID=20
      - HERMES_DASHBOARD=1
      - HERMES_DASHBOARD_HOST=0.0.0.0
      - API_SERVER_HOST=0.0.0.0   # zobacz niżej: bez tej linii, /health
    deploy:                       #   pozostaje nieosiągalny, mimo opublikowanego portu
      resources:
        limits:
          memory: 1g
          cpus: "1.0"
    command: ["gateway", "run"]

networks:
  hermes_lab:
    driver: bridge

Dwa ustawienia oficjalnego compose zachowują się inaczej, niż pozwala oczekiwać dokumentacja. Pierwsza dotyczy sieci. Oznaczenie jej jako internal: true, żeby odciąć całe wyjście do internetu, odcina też opublikowany port. W laboratorium żądanie wysłane z wnętrza kontenera otrzymuje HTTP 200 na /health. To samo żądanie z maszyny hosta, na opublikowanym porcie, nie otrzymuje żadnej odpowiedzi. Próba wyjścia do example.com zawodzi na niemożliwym rozwiązaniu DNS. Izolacja trzyma więc, ale zabiera ze sobą uzasadnione lokalne użycie portu. internal: true nadaje się tylko do laboratorium całkowicie offline. Dla rzeczywistego użycia ze zdalnym dostawcą modelu izolacja przechodzi przez klasyczną dedykowaną sieć i zaporę wychodzącą, nie przez to ustawienie.

Druga zaskakuje bardziej. Nawet na dedykowanej sieci nieoznaczonej jako internal, opublikowany port pozostawał nieosiągalny, połączenie TCP akceptowane, odpowiedź HTTP pusta. Poszukiwanie w zainstalowanym kodzie daje dokładne wyjaśnienie:

bash
docker exec hermes-lab grep -r API_SERVER_HOST /opt/hermes/hermes_cli/security_audit_startup.py

host = extra.get("host") or os.environ.get("API_SERVER_HOST", "127.0.0.1")

Domyślnie bramka nasłuchuje tylko na pętli lokalnej wewnątrz kontenera, niezależnie od wybranej sieci Docker. Stąd linia API_SERVER_HOST=0.0.0.0 w compose powyżej: niczego nie zmienia w zewnętrznej ekspozycji, ponieważ to prefiks 127.0.0.1: opublikowanego portu już ją ogranicza. Zweryfikowane po poprawce: curl http://127.0.0.1:8642/health odpowiada 200 z hosta, to samo żądanie wysłane na lokalny adres sieciowy maszyny (192.168.x.x) nie otrzymuje żadnej odpowiedzi. Co do tablicy, odmawia ona wprost uruchomienia na nielokalnym interfejsie bez skonfigurowanego dostawcy uwierzytelniania:

bash
Refusing to bind dashboard to 0.0.0.0 — the auth gate engages on non-loopback
binds (0.0.0.0), but no auth providers are registered.
There is no unauthenticated public-dashboard option.

Zdrowe zachowanie domyślne, z efektem ubocznym widocznym w dziennikach. Pozostawiona tak, bez skonfigurowanego uwierzytelniania, usługa nie zostaje po prostu wyłączona, zawodzi, a potem restartuje się w pętli pod nadzorem s6. Nic poważnego, ale wystarczająco głośno, żeby warto było o tym wiedzieć. Ostatni zweryfikowany punkt: limit deploy.resources.limits z compose powyżej rzeczywiście stosuje się poza trybem Swarm z Docker Compose v5.1.0. docker inspect potwierdza Memory=1073741824 i NanoCpus=1000000000 na uruchomionym kontenerze. Starsze wersje Compose ignorowały deploy: poza Swarm.

Co widać przy uruchamianiu

Po poprawieniu konfiguracji, docker compose up -d, a potem sondowanie /health co 0,3 sekundy dają czas uruchamiania około 18,9 sekundy na zimno (pusty folder danych) i 16,6 sekundy po zwykłym restarcie. Różnica bierze się głównie z fazy wewnętrznego rozgrzewania, którą dzienniki nazywają wprost „turn-machinery warm-up” i która otwiera bramę wejściową po 20 sekundach, mimo że trwa dalej w tle. Wewnątrz ps aux potwierdza, że nadzorca zostaje rootem, ale że proces hermes gateway run działa rzeczywiście pod nieuprzywilejowanym użytkownikiem hermes. Baner startowy pokazuje Hermes Agent v0.21.0 (2026.8.31), Python 3.13.5 i SDK OpenAI 2.24.0.

Port albo plik Rola Dostęp domyślny
8642 Stan zdrowia + bramka kompatybilna z API OpenAI Pętla lokalna kontenera (API_SERVER_HOST=127.0.0.1)
9119 Tablica webowa Odmawia każdego nielokalnego powiązania bez uwierzytelniania
/opt/data/.env Klucze dostawców modeli i narzędzi Wzorzec całkowicie zakomentowany, brak aktywnego klucza przy instalacji
/opt/data/config.yaml Model domyślny, terminal, kompresja kontekstu Generowany przy pierwszym uruchomieniu

Podłączenie do modelu

Plik .env wygenerowany przy pierwszym uruchomieniu wylicza, całkowicie w komentarzach, ze trzydziestu dostawców (Fireworks, OpenRouter, NovitaAI, Gemini, z.ai, Kimi, MiniMax, OpenCode Zen…) i tyle samo kluczy narzędzi (Firecrawl, Exa, Browserbase), żaden nie jest aktywny. „Ollama” pojawia się tam tylko w postaci OLLAMA_API_KEY, płatnej usługi chmurowej Ollama, i żaden wpis nie celuje w instancję lokalną. Wbudowana diagnostyka potwierdza neutralny stan instalacji:

bash
docker exec hermes-lab hermes doctor

✓ No active security advisories
✓ No suspicious MCP stdio commands
✓ Version files consistent (0.21.0)
◆ API Connectivity
  ⚠ OpenRouter API (not configured)
◆ Memory Provider
  ✓ Built-in memory active (no external provider configured — this is fine)

Jedyna wartość obecna w .env na koniec testu: API_SERVER_KEY wygenerowana automatycznie przez kontener, żeby chronić jego własną lokalną bramkę. Nigdy nie pojawia się jawnym tekstem w dziennikach, nikt jej nie wpisał i nie ma związku z kontem u dostawcy modelu.

Umiejętności, i jak zweryfikować jedną przed instalacją

Umiejętności („skills”) żyją w /opt/data/skills/ i podążają za otwartym standardem Agent Skills opisanym szczegółowo w naszym przewodniku po SKILL.md. hermes skills list naliczał 53 wbudowane umiejętności aktywne w tym laboratorium, żadna niezainstalowana z huba. Instalacja odbywa się przez rejestr: hermes skills install official/security/1password albo hermes skills install openai/skills/k8s, na przykład. Zanim cokolwiek zainstalujesz, dwie komendy pozwalają uniknąć ślepego zaufania:

bash
hermes skills inspect openai/skills/k8s   # metadane, repozytorium źródłowe, audyt już dostępny
hermes skills audit                       # ponownie skanuje wszystkie umiejętności zainstalowane z huba

Wbudowany skaner klasyfikuje każdy wynik na trzy poziomy: dangerous blokuje instalację, warn/caution omija się przez --force, advisory pozostaje informacyjny. Według oficjalnej dokumentacji, hub agregował 90 700 umiejętności rozłożonych na 11 rejestrach na 26 sierpnia 2026, nie mylić z „HermesHub”, zewnętrznym indeksem społecznościowym wspomnianym wyżej.

MCP: podłączyć narzędzia albo udostępnić Hermes jako serwer

hermes mcp catalog, uruchomiony w laboratorium, pokazuje już długi katalog gotowych do użycia serwerów (Airtable, Atlassian, Cloudflare, ClickUp, Buildkite…). hermes mcp list potwierdzał, że żaden nie był skonfigurowany, zgodnie z oczekiwaniem dla świeżej instalacji. Dodawanie odbywa się przez znane ustawienie wstępne albo ręczny wpis:

bash
hermes mcp add codex --preset codex
hermes mcp add filesystem --command npx --args "-y @modelcontextprotocol/server-filesystem /projet"

W drugą stronę, hermes mcp serve udostępnia sesję Hermes jako serwer MCP zewnętrznemu klientowi, Claude Code, na przykład, kierując jego konfigurację na komendę hermes mcp serve. Jeśli chodzi o bezpieczeństwo, dokumentacja precyzuje trzy rzeczy. Zdalne tokeny OAuth są zapisywane w cache z uprawnieniami 0600. Odnowienie przechodzi przez PKCE. Dla serwerów w stdio tylko jawnie zadeklarowane zmienne środowiskowe, plus minimalna baza, są przekazywane do podprocesu. To ogranicza wycieki sekretów do źle zaudytowanego zewnętrznego serwera MCP, ryzyko już udokumentowane w naszym artykule o agentach kodu, sandboksie i uprawnieniach.

Hermes Agent kontra OpenClaw: uczciwe porównanie

Oba projekty są open source, instalują się pod Dockerem i obsługują skille oraz MCP, to ich filozofia się rozchodzi. OpenClaw buduje bramkę, która routuje i nadzoruje wielu agentów, konektorów i kanałów. Hermes Agent stawia na jednego agenta, który gromadzi własne umiejętności w miarę użytkowania. Nasz artykuł o utwardzonej instalacji OpenClaw opisuje szczegółowo to samo ćwiczenie po stronie OpenClaw, oba czyta się jak lustrzane odbicie.

Jeśli chodzi o bezpieczeństwo, notatka badawcza Cloud Security Alliance datowana na 4 maja 2026 odnotowuje, w tym samym okresie, dziewięć CVE dla OpenClaw, w tym jedno krytyczne ocenione na 9,9, wobec dwóch dla rdzenia Hermes Agent. CVE-2026-7396 dotyczy przejścia ścieżki w adapterze WeCom (CVSS 4,0), CVE-2026-7397 podążania za dowiązaniem symbolicznym w narzędziach plikowych (CVSS 4,8), oba na wersji 0.8.0 i poprawione już w 0.9.0. Trzecie wymienione CVE dotyczy nie agenta, lecz hermes-webui, zewnętrznego klienta już wspomnianego wyżej. Strona GitHub Security Advisories repozytorium nie odnotowuje z kolei żadnego opublikowanego ostrzeżenia na 7 września 2026: te CVE zostały zgłoszone przez kanały zewnętrzne, nie przez samego Nous Research. Do dziś nie opublikowano żadnego zestawienia narażonych instancji Hermes porównywalnego ze zweryfikowaną liczbą dla OpenClaw (42 900 instancji, 93% bez uwierzytelniania, SecurityScorecard 2026), co nie dowodzi ich braku.

Datowany incydent ilustruje, dlaczego izolacja sieciowa i brak trybu automatycznego liczą się tyle samo, co wybór projektu. The Hacker News udokumentował, 24 lipca 2026, przypadek, w którym atakujący, mający już wstępny dostęp do sieci tajlandzkiego ministerstwa finansów, zainstalował Hermes Agent na wynajętym serwerze, a następnie włączył jego tryb „YOLO”, który pomija potwierdzenia przed ryzykownymi komendami. Agent eksplorował potem sieć bez nadzoru, znalazł usługi Hadoop z domyślnymi danymi uwierzytelniającymi i wdrożył implant. Punkt podkreślony przez samo źródło: Hermes nie spowodował włamania, zautomatyzował jego kolejną fazę. Dedykowana sieć, porty na pętli lokalnej i brak wpisanego klucza w tym laboratorium mają zapobiec dokładnie tej fazie.

Co warto zapamiętać

  • „Hermes Agent” porównywany z OpenClaw w 2026 to ten od Nous Research (NousResearch/hermes-agent, licencja MIT), nie hermes-webui ani „HermesHub”, dwa zewnętrzne projekty o zbliżonej nazwie.
  • Ostatnia testowana wersja z datą: v0.21.0 (tag v2026.8.31, 31 sierpnia 2026), zainstalowana przez Docker w 1 min 47 s (908 MB skompresowanych, 3,93 GB po dekompresji).
  • Sieć oznaczona jako internal: true odcina też opublikowany port, nie tylko wyjście do internetu. Domyślnie bramka nasłuchuje tylko na własnej pętli lokalnej (API_SERVER_HOST=127.0.0.1), do jawnego poprawienia nawet za portem już ograniczonym do 127.0.0.1 po stronie hosta.
  • Tablica odmawia ekspozycji poza pętlą lokalną bez skonfigurowanego uwierzytelniania. Zdrowe zachowanie domyślne, ale zostawiona tak zapętla się w niepowodzeniu, zamiast pozostać po prostu nieaktywna.
  • Uruchamianie zmierzone na około 17 do 19 sekund do rzeczywiście pozytywnego /health, bez żadnego klucza ani identyfikatora wpisanego od początku do końca.
  • W tym samym okresie Cloud Security Alliance odnotowuje dwa drobne CVE dla rdzenia Hermes Agent wobec dziewięciu dla OpenClaw, w tym jedno krytyczne. Różnicę czyta się z tą samą ostrożnością co resztę tego porównania: dla Hermes nie opublikowano równoważnego zestawienia narażenia.

Częste błędy

internal: true blokuje też opublikowany port Oznaczenie sieci jako wewnętrznej odcina wyjście kontenera, ale też port opublikowany przez ports:, przetestowane tutaj: docker exec otrzymuje 200, to samo wywołanie z hosta nie otrzymuje żadnej odpowiedzi.
Bramka domyślnie nasłuchuje tylko na 127.0.0.1 Wewnątrz kontenera, nie tylko po stronie hosta: bez API_SERVER_HOST=0.0.0.0, opublikowany port łączy się, ale zwraca pustą odpowiedź HTTP, nawet poza siecią internal.
Oficjalny compose używa network_mode: host Brak izolacji sieciowej domyślnie, dedykowana sieć i porty na 127.0.0.1 z tego artykułu celowo od tego odchodzą.
Tablica zapętla się w niepowodzeniu bez uwierzytelniania Pozostawienie HERMES_DASHBOARD=1 bez dostawcy uwierzytelniania nie wyłącza jej po cichu: zawodzi i restartuje się w pętli pod s6.
hermes doctor domaga się migracji nawet na świeżej instalacji Komunikat wspomina konfigurację „~2 years old”, mimo że kontener właśnie został utworzony, to wzorzec wbudowany w obraz, bez blokującej konsekwencji.

DockerHermes AgentMCPSécuritéSkills

Damien Flandrin Web developer od 2010 roku, twórca Gekkode i Email Impact. Każdy artykuł jest sprawdzany na prawdziwym projekcie przed publikacją. Kontakt
Newsletter

Nowe testy, poradniki i projekty, e-mailem.

Powtarzalne testy, wersjonowany kod, datowane wyniki. Nigdy spamu.