Kako samostalno hostati OpenClaw 2026.: Gateway, kanali i sigurnost

OpenClaw tretirajte kao mali sustav, a ne kao Docker image. Korisnički cilj OpenClawa jasan je: AI assistant gateway s više od 22 integracije kanala; implementacija je prihvatljiva tek kada možete povezati jedan kanal za razmjenu poruka, poslati ulaznu poruku, odobriti pošiljatelja, pozvati bezopasan alat i ponovno se povezati s Control UI-jem nakon ponovnog pokretanja Gatewaya.

Ta razlika otkriva način kvara s kojim se operatori susreću nakon lokalnog testiranja: Gateway se veže samo na loopback ili proxy odbacuje WebSocket nadogradnje. Također plan sigurnosnih kopija i nadogradnji postaje dovoljno konkretan za testiranje.

Odaberite najmanju održivu topologiju OpenClawa

Najmanja odgovorna topologija OpenClawa sadržava jedan privatni listener na portu 18789, ingress rutu i dokumentiranu granicu stanja. Vanjski preduvjet za OpenClaw jest ključ pružatelja modela i barem jedan povezani kanal. Testirajte odlazni DNS, TLS i ponašanje pružatelja bez objavljivanja dodatne ulazne usluge.

Topologiju provjerite tako da od čistog klijenta zatražite povezivanje jednog kanala za razmjenu poruka, slanje ulazne poruke, odobravanje pošiljatelja, pozivanje bezopasnog alata i ponovno povezivanje s Control UI-jem nakon ponovnog pokretanja Gatewaya. Tijekom rada pratite paralelne izvršavanja agenata, latenciju modela, procese browser-toolova i veličinu nakupljene povijesti sesija. Rezultat pokazuje treba li sljedeće poboljšanje biti u memoriji, pohrani, mreži ili zasebnom workeru, umjesto da vas potiče na proizvoljno dimenzioniranje containera.

Dijagnosticirajte OpenClaw koji izgleda zdravo

Idle health check govori malo o OpenClawu. Pratite paralelna izvršavanja agenata, latenciju modela, procese browser-toolova i veličinu nakupljene povijesti sesija, a zatim postavite alert na simptom koji korisnici doživljavaju: neuspjeh radnje „povežite jedan kanal za razmjenu poruka, pošaljite ulaznu poruku, odobrite pošiljatelja, pozovite bezopasan alat i ponovno se povežite s Control UI-jem nakon ponovnog pokretanja Gatewaya”. Liveness neka ostane lokalna i jeftina; readiness neka prijavljuje migracije ili inicijalizaciju bez izazivanja oluje ponovnih pokretanja.

Rizično područje kod nadogradnji jest mogućnost da izdanje promijeni shemu konfiguracije Gatewaya, uključene skillove, browser dependencies ili channel adaptere. Pročitajte release notes, napravite snapshot stanja, implementirajte ciljnu verziju nad obnovljenom kopijom i ponovite prihvatnu radnju. Ako se Gateway veže samo na loopback ili proxy odbacuje WebSocket nadogradnje, povežite zahtjev klijenta s prvim relevantnim zapisom aplikacijskog loga umjesto da naslijepo brišete stanje ili dodajete redirekcije.

Pet provjera snažnijih od health checka containera

Zapis o izdanju za OpenClaw treba sadržavati činjenice, a ne „izgleda dobro”. Spremite odabrani image digest, checksum konfiguracije, javni hostname i vremenski označen rezultat za: povezivanje jednog kanala za razmjenu poruka, slanje ulazne poruke, odobravanje pošiljatelja, pozivanje bezopasnog alata i ponovno povezivanje s Control UI-jem nakon ponovnog pokretanja Gatewaya. Koristite ogledne podatke koji nisu iz produkcije kako bi se provjera mogla pokrenuti nakon svake implementacije.

Dokažite zasebno dva događaja životnog ciklusa. Zamjena containera mora očuvati uobičajen rad; uredan oporavak mora pokazati da obnovljeni Gateway može ponovno otvoriti svoj workspace, prepoznati povezani kanal i koristiti autentikaciju pružatelja bez ponovnog onboardinga. Dok provjere traju, mjerite paralelna izvršavanja agenata, latenciju modela, procese browser-toolova i veličinu nakupljene povijesti sesija te rezultat zadržite kao očekivani raspon za ovu verziju.

Testirajte i odbijeni ili nevažeći uvjet: privremeno onemogućite testnu putanju koju upotrebljava ključ pružatelja modela i barem jedan povezani kanal. OpenClaw bi trebao otkazati na način koji omogućuje dijagnostiku i ne bi smio prebrisati ispravno stanje. Vratite važeći uvjet, ponovno pokrenite ogledni test i priložite relevantne redigirene logove. Ti artefakti budućoj odluci o vraćanju na prethodnu verziju daju konkretne dokaze.

Pokrenite prvu instancu oblikovanu prema produkciji

Početno pokretanje OpenClawa neka bude dovoljno reproducibilno za pregled u pull requestu.

docker run -d \
  --name openclaw \
  --restart unless-stopped \
  -p 127.0.0.1:18789:18789 \
  -v openclaw-data:/home/node/.openclaw \
  -e OPENCLAW_GATEWAY_TOKEN=replace-with-a-long-random-value \
  -e OPENCLAW_GATEWAY_BIND=lan \
  ghcr.io/openclaw/openclaw:latest node dist/index.js gateway --bind lan --port 18789

Nakon što postoje stvarni podaci nemojte se oslanjati na latest. Zabilježite radni digest, korisnika containera i vlasništvo nad mountom. Pratite aplikacijski log kroz cijeli test — povezivanje jednog kanala za razmjenu poruka, slanje ulazne poruke, odobravanje pošiljatelja, pozivanje bezopasnog alata i ponovno povezivanje s Control UI-jem nakon ponovnog pokretanja Gatewaya — te zabilježite sve migracije prije usmjeravanja produkcijskog prometa na rutu.

Oporavak OpenClawa učinite mjerljivim

Container image može se ponovno preuzeti; OpenClaw workspace, stanje kanala i konfiguracija ne mogu. Montirajte /home/node/.openclaw prije bootstrapa, zapišite bezopasne ogledne podatke i zamijenite container kako biste dokazali da je ta putanja doista trajna. Pregledajte stvarni mount umjesto da vjerujete nazivu Compose datoteke i provjerite može li runtime user pisati ondje gdje OpenClaw to očekuje.

Odaberite politiku zadržavanja i odredište izvan hosta, a zatim uvježbajte oporavak bez diranja produkcije. Vježba je uspješna samo kada obnovljeni Gateway može ponovno otvoriti svoj workspace, prepoznati povezani kanal i koristiti autentikaciju pružatelja bez ponovnog onboardinga. Za stanje u bazi podataka kombinirajte snapshotove pohrane s izvozima konzistentnima s aplikacijom, kao što je opisano u članku oporavak u određenom trenutku nasuprot snapshotovima.

Testirajte OpenClaw izvan servera

Vanjski URL OpenClawa tretirajte kao konfiguraciju koja preživljava redeploy. Najprije konfigurirajte javnu adresu Gatewaya i proxy koji podržava WebSocket; zatim usmjerite hostname na port 18789 uz očuvane izvorne host i scheme vrijednosti.

Kontrolni popis dostupnosti nakon implementacije može dokazati da zahtjevi ulaze u container. Nakon toga poznati kvar — Gateway se veže samo na loopback ili proxy odbacuje WebSocket nadogradnje — treba istražiti u OpenClawu, njegovu stanju ili workloadu, a ne u automatizaciji certifikata.

Smanjite ovlasti koje OpenClaw ima

Bootstrap vjerodajnice su privremene; model povjerenja je trajan. Kod OpenClawa pazite da Gateway token ne ostane nedefiniran i da ne odobravate nepoznata povezivanja kanala; koristite jednu granicu povjerenja po Gatewayu, pregledajte svako DM povezivanje i sandboxirajte alate koji dodiruju host.

Prema OPENCLAW_GATEWAY_TOKEN postupajte u skladu s njegovom ulogom u OpenClawu: osjetljive vrijednosti držite izvan Gita, dokumentirajte učinke rotacije i u produkciji nikada ne zamjenjujte javnim primjerom. Pokrenite image bez nepotrebnih Linux capabilities i izložite samo javnu aplikacijsku rutu. Aktivnosti administratora neka budu vidljive, ali bez bilježenja tajnih vrijednosti.

Povežite OpenClaw s Dockupovim životnim ciklusom

Platformski sloj za OpenClaw čine port 18789, ingress, TLS, runtime konfiguracija, pohrana i dostupnost ovisnosti. Dockup može reproducirati te komponente za vlastitu infrastrukturu ili server koji korisnik poveže.

Operator zatim dovršava produktni sloj: konfigurira javnu adresu Gatewaya i proxy koji podržava WebSocket; provodi ovo pravilo pristupa — koristite jednu granicu povjerenja po Gatewayu, pregledajte svako DM povezivanje i sandboxirajte alate koji dodiruju host — te pokreće „povežite jedan kanal za razmjenu poruka, pošaljite ulaznu poruku, odobrite pošiljatelja, pozovite bezopasan alat i ponovno se povežite s Control UI-jem nakon ponovnog pokretanja Gatewaya”. Bilježenje tog testa uz deployment sprječava miješanje automatiziranog provisioninga s pripravnošću aplikacije.

Često postavljana pitanja

Što je OpenClawu potrebno za produkcijski deployment?

Usmjerite OpenClaw container na portu 18789 kroz jednu HTTPS origin adresu. Vanjski preduvjet isporuke jest ključ pružatelja modela i barem jedan povezani kanal. Nemojte OpenClaw smatrati spremnim dok ne možete povezati jedan kanal za razmjenu poruka, poslati ulaznu poruku, odobriti pošiljatelja, pozvati bezopasan alat i ponovno se povezati s Control UI-jem nakon ponovnog pokretanja Gatewaya.

Koji OpenClaw podaci trebaju biti u sigurnosnoj kopiji?

Učinite /home/node/.openclaw trajnim i uključite OpenClaw workspace, stanje kanala i konfiguraciju u isti recovery manifest. Uredan OpenClaw restore uspješan je samo kada obnovljeni Gateway može ponovno otvoriti svoj workspace, prepoznati povezani kanal i koristiti autentikaciju pružatelja bez ponovnog onboardinga.

Zahtijeva li OpenClaw HTTPS iza reverse proxija?

Za javni OpenClaw origin koristite HTTPS, a port 18789 zadržite na internoj ruti. Ispravno primijenite OpenClaw postavku: konfigurirajte javnu adresu Gatewaya i proxy koji podržava WebSocket. Za OpenClaw HTTPS štiti vjerodajnice ili korisnički sadržaj tijekom prijenosa i održava dosljedno ponašanje klijenta osjetljivo na origin.

Kako testirati nadogradnju OpenClawa?

Obnovite trenutačno stanje OpenClawa u izoliranom deploymentu, primijenite kandidatsku verziju i ponovite njegovu prihvatnu transakciju. Obratite posebnu pozornost jer izdanje može promijeniti shemu konfiguracije Gatewaya, uključene skillove, browser dependencies ili channel adaptere. Zadržite prethodni OpenClaw image dok ne razjasnite njegove granice migracije podataka i vraćanja na prethodnu verziju.