Czym jest silnik OpenClaw i kiedy hostować go samemu

Co właściwie uruchamiasz, instalując OpenClaw

OpenClaw to demon — jeden długo działający proces o nazwie Gateway, który startuje na Twojej maszynie i domyślnie nasłuchuje na 127.0.0.1:18789. Dokumentacja opisuje go jako most między Twoimi komunikatorami a asystentem dostępnym bez przerwy. Wszystko pozostałe — narzędzie wiersza poleceń, panel w przeglądarce, aplikacja na Maca, telefon w roli node'a — to klienci, którzy dobijają się do tego samego portu po WebSockecie. Zapamiętaj ten układ, bo połowa późniejszych problemów sprowadza się do pytania, kto ma prawo połączyć się z Gateway.

Gateway trzyma połączenia z providerami modeli i z kanałami, a na zewnątrz wystawia typowane API WebSocket: żądania, odpowiedzi i zdarzenia wypychane z serwera. Każda ramka jest sprawdzana względem schematu JSON. Zdarzenia mają nazwy, które zobaczysz potem w logach — agent, chat, session.message, presence, tick, health, heartbeat. Na tym samym porcie stoi serwer HTTP z panelem Control UI oraz canvasem pod ścieżką /__openclaw__/canvas/.

Klient musi się przedstawić, zanim cokolwiek zrobi. Handshake jest obowiązkowy: pierwsza ramka to connect, każdy klient podaje tożsamość urządzenia, a nowe urządzenie czeka na zatwierdzenie parowania, zanim dostanie token. Uwierzytelnianie Gateway jest wymagane domyślnie i działa fail-closed — bez poprawnie ustawionej ścieżki auth połączenia WebSocket są odrzucane. Odmowa bindowania bez auth przy pierwszym starcie jest wpisana w projekt — Gateway ma nie wstać, dopóki nie ustawisz ścieżki auth.

Słowo „silnik” nie jest tu ozdobnikiem. Model językowy nie należy do OpenClawa — dokładasz go sam, kluczem API albo lokalnym modelem z Ollamy czy LM Studio. Projekt jest model-agnostyczny, obsługuje routing per agent i przełączenie na model zapasowy przy awarii providera. FAQ zaznacza rzecz, która myli ludzi przy pierwszym uruchomieniu: ustawienie klucza API włącza poświadczenie, ale nie wybiera za Ciebie modelu.

openclaw gateway status
openclaw config get gateway.port

Clawdbot, Moltbot, OpenClaw — trzy nazwy, jeden projekt

Projekt wystartował w listopadzie 2025 roku pod nazwą Clawdbot. Napisał go austriacki programista Peter Steinberger, wcześniej autor PSPDFKit. Po skardze Anthropic o znak towarowy nazwa poszła najpierw na Moltbot, a 30 stycznia 2026 roku na OpenClaw. Architektura przez ten czas się nie zmieniła — zmieniła się nazwa pakietu i część komend.

14 lutego 2026 Steinberger dołączył do OpenAI. Sam Altman potwierdził wtedy, że OpenClaw zostaje projektem otwartym, a opiekę nad nim przejęła powołana fundacja non-profit. Dzisiejsza dokumentacja podpisuje się dokładnie tak: rozwijany otwarcie przez OpenClaw Foundation, organizację non-profit, której maskotką został Molty. Kod dalej leży na GitHubie na licencji MIT.

Dla Ciebie ma to jeden praktyczny skutek. Szukając odpowiedzi na konkretny błąd, trafisz na materiały pisane pod trzema różnymi nazwami, a część z nich podaje komendy, które już nie istnieją. Instalujesz zawsze pakiet openclaw i tego się trzymaj przy weryfikacji. To akurat wkurza — sporo tekstów z pierwszej połowy 2026 roku nigdy nie zostało poprawionych i wciąż siedzi wysoko w wynikach.

Zasada, która oszczędza godziny: jeśli poradnik podaje komendę, której nie ma w docs.openclaw.ai, nie poprawiaj jej na własną rękę. Sprawdź, jak brzmi dziś, i dopiero wtedy wklej ją do terminala.

Co dostajesz w rdzeniu, a co trzeba doinstalować

W rdzeniu siedzą trzy kanały, każdy inny komunikator to plugin — czym się to różni w konfiguracji, rozbiera lekcja dwudziesta druga.

Poza kanałami rdzeń daje agenta z narzędziami, sesjami i pamięcią oraz routing między wieloma agentami. Do tego cron, webhooki, subagenty do pracy równoległej, automatyzację przeglądarki i skille instalowane z ClawHuba albo z własnego katalogu. Pamięć agenta to zwykłe pliki Markdown w workspace, a stan sesji i routingu leży w bazie SQLite pod ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite.

Czego w środku nie ma: modelu i kogokolwiek, kto odbierze telefon, gdy coś przestanie działać. Obie rzeczy przy self-hoście dokładasz sam. Trzeba to powiedzieć wprost, zanim ktoś porówna „darmowy OpenClaw” z płatną platformą i uzna, że różnica wynosi całą cenę abonamentu.

Katalog stanu ~/.openclaw trzyma poza tym poświadczenia kanałów, profile auth, rejestr modeli i workspace agenta. Dokumentacja bezpieczeństwa zaleca na nim uprawnienia 700, a na samym pliku openclaw.json — 600. Model zaufania jest opisany jako personal assistant: jeden zaufany operator, a nie system wielodostępowy z izolacją między użytkownikami.

• WebChat, Telegram i iMessage — kanały wbudowane
• Agent z narzędziami, sesjami, pamięcią i routingiem między wieloma agentami
• Cron, webhooki, subagenty i automatyzacja przeglądarki
• Skille instalowane z ClawHuba albo z własnego katalogu
• Stan sesji w SQLite: ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite

Licencja MIT: co z niej wynika, a czego nie da

MIT to jedna z najkrótszych i najbardziej liberalnych licencji otwartego oprogramowania. Możesz używać OpenClawa komercyjnie, zmieniać kod, hostować go dla klientów i budować na nim płatną usługę. Realny obowiązek jest jeden: zachować notę licencyjną i informację o prawach autorskich w kopiach oprogramowania. Nie ma tu klauzuli copyleft, więc własnych modyfikacji nie musisz otwierać.

Druga strona MIT jest równie krótka: brak gwarancji i brak odpowiedzialności. Nikt nie obiecuje Ci, że silnik zadziała ani że ktoś odpowie na zgłoszenie w ciągu doby. Wsparcie, jakie masz, to dokumentacja i issues na GitHubie — plus tyle Discorda, ile akurat ktoś czyta. Dla firmy, która postawi na tym obsługę klienta, ma to znaczenie umowne, a nie tylko filozoficzne.

Rachunek za samo oprogramowanie wynosi zero złotych i to się nie zmieni. Płacisz za maszynę, na której to stoi, oraz za tokeny modelu, który dokładasz. Przy 300 turach miesięcznie i 12 000 tokenów wejścia na turę koszt API to około 40 zł; przy 3000 tur — około 400 zł. Najtańszy VPS pod Debiana kosztuje 25 zł miesięcznie.

Fundacja non-profit w roli opiekuna projektu zmienia trochę ryzyko, ale go nie zeruje. Kod jest na MIT, więc nawet gdyby jutro fundacja przestała istnieć, Twoja instalacja działa dalej, a repozytorium można sforkować. Ryzykiem pozostaje tempo — poprawki bezpieczeństwa wychodzą wtedy, kiedy ktoś je napisze, a nie wtedy, kiedy Ci na nich zależy.

Self-host kontra gotowa platforma: granica biegnie po odpowiedzialności

Różnica nie leży w tym, co silnik potrafi. To ten sam OpenClaw, ta sama lista kanałów, ta sama pamięć w plikach Markdown i ten sam port 18789. Granica biegnie tam, gdzie zaczyna się pytanie, kto to podniesie, gdy przestanie działać w piątek o 23:40.

Przy self-hoście po Twojej stronie zostaje cała lista: aktualizacje silnika, kopie zapasowe stanu, rotacja tokenów kanałów, uprawnienia plików, firewall, restart po awarii i czytanie logów. Nic z tego nie jest trudne pojedynczo. Problem polega na tym, że to praca cykliczna, a nie jednorazowa, i wraca niezależnie od tego, czy masz na nią czas.

Przy platformie zarządzanej kupujesz dokładnie tę listę, nie dodatkowe funkcje. ClawLabs stawia instancję w chmurze EU u Hetznera w około 60 sekund, z 13 podpiętymi kanałami, własnym kluczem API w modelu BYOK i umową powierzenia na żądanie, od 399 zł miesięcznie. Sam silnik dalej jest darmowy, więc pytanie brzmi wyłącznie tak: czy chcesz utrzymywać ten stos samodzielnie.

Jest też droga pośrednia, o której mało kto pamięta. Możesz trzymać Gateway lokalnie na własnym komputerze — na Macu przez aplikację w pasku menu, na Windowsie przez aplikację Hub — i nie wystawiać go w ogóle do internetu. Odpada wtedy firewall i cały wątek ekspozycji sieciowej. Cena jest taka, że agent działa tylko wtedy, gdy komputer jest włączony.

Rachunek za self-host jest z czasu, nie z pieniędzy

Wymagania sprzętowe są na tyle niskie, że nie ma o czym dyskutować. Minimum to 1 vCPU, 1 GB RAM, 500 MB wolnego dysku i system 64-bitowy, a tabela zgodności z FAQ pierwszego uruchomienia stawia Raspberry Pi 5 z 4 lub 8 GB jako wariant najlepszy, Pi 4 z 4 GB jako dobry. Wersja z 2 GB działa po dodaniu swapa, a Pi Zero 2W z 512 MB nie jest polecany. Model liczy się po stronie providera, więc maszyna hostuje wyłącznie Gateway.

Pieniądze wyglądają podobnie skromnie. Najmniejszy VPS pod Debiana albo Ubuntu zaczyna się w okolicach 25 zł miesięcznie, Oracle Cloud ma warstwę Always Free za zero, a Raspberry Pi to wydatek jednorazowy rzędu 150–350 zł. Do tego dochodzą tokeny modelu i na tym lista się kończy — po stronie licencji nie ma nic.

Czas jest tym, co naprawdę decyduje. Sama instalacja zajmuje 2–5 minut, kreator kolejne kilka, a pełna ścieżka na VPS z Dockerem według przewodnika Hetznera około 20 minut. To liczby ze scenariusza, w którym nic nie idzie nie tak. Przy pierwszym podejściu zawsze coś idzie.

Utrzymania nie policzysz z dokumentacji, bo tu dokumentacja milczy. Kurs liczy utrzymanie agenta na platformie zarządzanej na półtorej do dwóch godzin miesięcznie — ten przedział wpisaliście do budżetu w lekcji piętnastej. Self-host dokłada aktualizacje silnika, kopie zapasowe, rotację tokenów i restarty po awariach, więc z praktyki wychodzi trzy do czterech godzin miesięcznie. Przy stawce 68 zł za godzinę pełnego kosztu pracodawcy — wyliczenie stoi w lekcji ósmej — daje to 204–272 zł. Tyle mniej więcej wynosi Twoja „darmowa” instalacja, zanim policzysz VPS i tokeny.

Ten rachunek dokłada się do progu, którym kurs posługuje się od lekcji drugiej: agent musi oddawać osiem godzin miesięcznie, żeby wyjść na zero przy abonamencie od 399 zł. Self-host tego progu nie znosi — przesuwa go w górę, bo trzy do czterech godzin utrzymania trzeba najpierw odrobić.

Test, który rozstrzyga sprawę w pół godziny

Zamiast czytać porównania, odpowiedz na cztery konkretne pytania i policz odpowiedzi przeczące. Czy ktoś u Was zareaguje w ciągu doby, gdy Gateway przestanie odpowiadać w sobotę? Czy potraficie wskazać z nazwiska osobę, która robi kopię zapasową i sprawdza, czy da się ją odtworzyć? Czy w kalendarzu jest miejsce na trzy do czterech godzin miesięcznie — półtorej do dwóch na samego agenta i drugie tyle na aktualizacje, kopie i awarie — które nie zejdą z niczego innego? Czy ktoś rozumie różnicę między loopbackiem a bindem na LAN na tyle, żeby nie wystawić panelu do internetu?

Jedno „nie” nie przekreśla self-hostu. Dwa oznaczają, że instalacja powstanie, popracuje trzy tygodnie i zostanie porzucona po pierwszej awarii, której nikt nie umiał odtworzyć. Ta kolejność powtarza się z nudną regularnością.

Jeśli wychodzi Ci self-host, następna lekcja przeprowadzi Cię przez instalację trzema drogami — VPS, Windows i chmura kontenerowa — razem z miejscami, w których ludzie utykają. Jeśli wychodzi platforma, ta ścieżka i tak Ci się przyda: ustawienia z kolejnych lekcji, od polityk dostępu po cron, wyglądają tak samo po obu stronach.

Jedno rozstrzygnięcie zrób teraz, a nie za miesiąc: gdzie mają leżeć dane. OpenClaw jest local-first, więc przy self-hoście wszystko poza zapytaniami do modelu zostaje na Twojej maszynie. Przy platformie pytanie o lokalizację serwerów i umowę powierzenia zadaj przed pierwszym uruchomieniem, nie po pierwszym incydencie.