Så kör du OpenClaw själv 2026: Gateway, kanaler och säkerhet

Se OpenClaw som ett litet system, inte som en Docker-avbild. Målet för användaren är tydligt: en AI-assistent-Gateway med fler än 22 kanal­integrationer. Distributionen är bara godtagbar när du kan para ihop en meddelandekanal, skicka ett inkommande meddelande, godkänna avsändaren, anropa ett ofarligt verktyg och återansluta Control UI efter en omstart av Gateway.

Den skillnaden fångar det fel som operatörer stöter på efter lokal testning: Gateway binder endast till loopback eller så släpper proxyn inte igenom WebSocket-uppgraderingar. Den gör också planen för säkerhetskopiering och uppgraderingar tillräckligt specifik för att kunna testas.

Välj den minsta användbara OpenClaw-topologin

Den minsta ansvarsfulla OpenClaw-topologin innehåller en privat listener på 18789, en ingress-route och en dokumenterad state-gräns. Det externa kravet för OpenClaw är en nyckel till en model provider och minst en parkopplad kanal. Testa utgående DNS, TLS och provider-beteende utan att publicera ytterligare en inkommande tjänst.

Validera topologin genom att låta en ren klient para ihop en meddelandekanal, skicka ett inkommande meddelande, godkänna avsändaren, anropa ett ofarligt verktyg och återansluta Control UI efter en omstart av Gateway. Följ parallella agentkörningar, modellens fördröjning, browser-tool-processer och storleken på den ackumulerade sessionhistoriken medan den körs. Resultatet visar om nästa förbättring hör hemma i minne, lagring, nätverk eller en separat worker, i stället för att uppmuntra till godtycklig dimensionering av containern.

Diagnostisera en OpenClaw som verkar frisk

En inaktiv health check säger inte mycket om OpenClaw. Följ parallella agentkörningar, modellens fördröjning, browser-tool-processer och storleken på den ackumulerade sessionhistoriken, och larma sedan på det symptom användarna faktiskt upplever: att åtgärden ”para ihop en meddelandekanal, skicka ett inkommande meddelande, godkänna avsändaren, anropa ett ofarligt verktyg och återansluta Control UI efter en omstart av Gateway” misslyckas. Håll liveness lokal och billig; låt readiness rapportera migreringar eller initiering utan att orsaka en omstartsloop.

Det riskfyllda området vid uppgraderingar är att en release kan ändra Gateways konfigurationsschema, inkluderade skills, browser-beroenden eller kanaladaptrar. Läs release notes, skapa en snapshot av state, distribuera målversionen mot en återställd kopia och upprepa acceptanstestet. Om Gateway binder endast till loopback eller proxyn släpper inte igenom WebSocket-uppgraderingar, korrelera klientförfrågan med den första relevanta applikationsloggen i stället för att blint radera state eller lägga till redirects.

Fem kontroller som är bättre än container health

Release-dokumentationen för OpenClaw behöver fakta, inte ”ser bra ut”. Spara vald image digest, konfigurationschecksumma, offentligt hostname och ett tidsstämplat resultat för att para ihop en meddelandekanal, skicka ett inkommande meddelande, godkänna avsändaren, anropa ett ofarligt verktyg och återansluta Control UI efter en omstart av Gateway. Använd icke-produktionsdata så att kontrollen kan köras efter varje deployment.

Bevisa två lifecycle-händelser separat. Ett byte av container måste bevara normal drift; en ren återställning måste visa att den återställda Gateway kan öppna sin workspace igen, känna igen den parkopplade kanalen och använda provider-autentisering utan onboarding igen. Mät parallella agentkörningar, modellens fördröjning, browser-tool-processer och storleken på den ackumulerade sessionhistoriken medan kontrollerna körs, och spara resultatet som det förväntade intervallet för den här versionen.

Testa även ett nekat eller ogiltigt tillstånd: neka tillfälligt den testväg som används av en nyckel till en model provider och minst en parkopplad kanal. OpenClaw ska misslyckas på ett diagnostiserbart sätt och får inte skriva över fungerande state. Återställ det giltiga tillståndet, kör exemplet igen och bifoga relevanta, avidentifierade loggar. Dessa artefakter ger ett framtida beslut om rollback konkret underlag.

Kör den första produktionsliknande instansen

Håll den första OpenClaw-starten tillräckligt reproducerbar för att kunna granskas i en pull request.

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

Förlita dig inte på latest när riktiga data finns. Spara den fungerande digest-en, container-användaren och ägarskapet för mounten. Följ applikationsloggen genom ett komplett test — para ihop en meddelandekanal, skicka ett inkommande meddelande, godkänn avsändaren, anropa ett ofarligt verktyg och återanslut Control UI efter en omstart av Gateway — och notera eventuella migreringar innan routen placeras bakom produktionstrafik.

Gör OpenClaw-återställning mätbar

En container image kan laddas ned igen; OpenClaw-workspacen, kanalstate och konfigurationen kan inte det. Montera /home/node/.openclaw före bootstrap, skriv ofarliga exempeldata och byt ut containern för att bevisa att sökvägen faktiskt är persistent. Kontrollera den effektiva mounten i stället för att lita på ett Compose-filnamn, och verifiera att runtime-användaren kan skriva där OpenClaw förväntar sig det.

Välj retention och en destination utanför hosten och öva sedan på återställning utan att röra produktionen. Övningen är godkänd först när den återställda Gateway kan öppna sin workspace igen, känna igen den parkopplade kanalen och använda provider-autentisering utan onboarding igen. För databaserad state kombinerar du storage snapshots med applikationskonsistenta exporter enligt beskrivningen i point-in-time recovery jämfört med snapshots.

Testa OpenClaw utanför servern

Behandla den externa OpenClaw-URL:en som konfiguration som ska överleva redeploys. Konfigurera först den publika Gateway-adressen och en proxy med stöd för WebSocket; routa sedan hostnamnet till port 18789 med ursprungligt host och schema intakta.

Checklistan för deployment reachability kan bevisa att förfrågningar når containern. Därefter ska det kända felet — att Gateway binder endast till loopback eller att proxyn släpper inte igenom WebSocket-uppgraderingar — utredas i OpenClaw, dess state eller dess workload, inte i automatiseringen för certifikat.

Minska den behörighet OpenClaw har

Bootstrap-uppgifter är tillfälliga; trust-modellen är permanent. Med OpenClaw ska du se upp med att lämna Gateway-token tom eller godkänna okända kanalparkopplingar. Använd en trust boundary per Gateway, granska varje DM-parkoppling och sandboxa verktyg som påverkar hosten.

Hantera OPENCLAW_GATEWAY_TOKEN utifrån dess roll i OpenClaw: håll känsliga värden borta från Git, dokumentera effekterna av rotation och ersätt aldrig ett offentligt exempel i produktion. Kör imagen utan onödiga Linux capabilities och exponera endast den publika applikationsrouten. Håll administratörsaktivitet synlig utan att logga hemliga värden.

Koppla OpenClaw till Dockups lifecycle

Plattformslagret för OpenClaw består av port 18789, ingress, TLS, runtime-konfiguration, lagring och dependency reachability. Dockup kan återskapa dessa delar för sin egen infrastruktur eller för en server som kunden ansluter.

Därefter slutför operatören produktlagret: konfigurera den publika Gateway-adressen och en proxy med stöd för WebSocket; tillämpa denna åtkomstregel — använd en trust boundary per Gateway, granska varje DM-parkoppling och sandboxa verktyg som påverkar hosten; och kör ”para ihop en meddelandekanal, skicka ett inkommande meddelande, godkänn avsändaren, anropa ett ofarligt verktyg och återanslut Control UI efter en omstart av Gateway”. Om testet sparas tillsammans med deploymenten undviker man att blanda ihop automatiserad provisionering med applikationsberedskap.

Vanliga frågor

Vad behöver OpenClaw för en produktionsdeployment?

Routa OpenClaw-containern på port 18789 via en HTTPS-origin. Det externa leveranskravet är en nyckel till en model provider och minst en parkopplad kanal. Kalla inte OpenClaw redo förrän du kan para ihop en meddelandekanal, skicka ett inkommande meddelande, godkänna avsändaren, anropa ett ofarligt verktyg och återansluta Control UI efter en omstart av Gateway.

Vilka OpenClaw-data ska ingå i en säkerhetskopia?

Gör /home/node/.openclaw persistent och inkludera OpenClaw-workspacen, kanalstate och konfigurationen i samma återställningsmanifest. En ren OpenClaw-återställning är godkänd först när den återställda Gateway kan öppna sin workspace igen, känna igen den parkopplade kanalen och använda provider-autentisering utan onboarding igen.

Kräver OpenClaw HTTPS bakom en reverse proxy?

Använd HTTPS för den publika OpenClaw-originen och behåll port 18789 på den interna routen. Tillämpa OpenClaw-inställningen korrekt: konfigurera den publika Gateway-adressen och en proxy med stöd för WebSocket. För OpenClaw skyddar HTTPS uppgifter eller användarinnehåll under överföring och ser till att klientbeteende som är känsligt för origin förblir konsekvent.

Hur bör en OpenClaw-uppgradering testas?

Återställ aktuell OpenClaw-state till en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom en release kan ändra Gateways konfigurationsschema, inkluderade skills, browser-beroenden eller kanaladaptrar. Behåll den tidigare OpenClaw-imagen tills gränserna för datamigrering och rollback är förstådda.