Slik selvhoster du OpenClaw i 2026: Gateway, kanaler og sikkerhet

Se på OpenClaw som et lite system, ikke som et Docker-image. Målet for brukeren av OpenClaw er tydelig: en AI-assistent-Gateway med over 22 kanalintegrasjoner. Deploymenten er først akseptabel når du kan koble sammen én meldingskanal, sende en innkommende melding, godkjenne avsenderen, kjøre et ufarlig verktøy og koble Control UI til på nytt etter en omstart av Gateway.

Dette skillet avdekker feilen operatører møter etter lokal testing: Gateway binder bare til loopback, eller proxyen slipper ikke gjennom WebSocket-oppgraderinger. Det gjør også planen for sikkerhetskopiering og oppgradering konkret nok til å kunne testes.

Velg den minste brukbare OpenClaw-topologien

Den minste ansvarlige OpenClaw-topologien består av én privat listener på 18789, en ingress-rute og en dokumentert state-grense. Det eksterne kravet for OpenClaw er en nøkkel for model provider og minst én sammenkoblet kanal. Test utgående DNS, TLS og provider-atferd uten å publisere enda en inngående tjeneste.

Valider topologien ved å be en ren klient om å koble sammen én meldingskanal, sende en innkommende melding, godkjenne avsenderen, kjøre et ufarlig verktøy og koble Control UI til på nytt etter en omstart av Gateway. Følg med på parallelle agentkjøringer, modell-latens, prosesser for browser-verktøy og størrelsen på akkumulert session history mens den kjører. Resultatet viser om neste forbedring hører hjemme i minne, lagring, nettverk eller en separat worker, i stedet for å oppmuntre til vilkårlig dimensjonering av containeren.

Diagnostiser en OpenClaw som ser frisk ut

En inaktiv health check sier lite om OpenClaw. Følg med på parallelle agentkjøringer, modell-latens, prosesser for browser-verktøy og størrelsen på akkumulert session history, og varsle på symptomet brukerne faktisk opplever: at handlingen «koble sammen én meldingskanal, sende en innkommende melding, godkjenne avsenderen, kjøre et ufarlig verktøy og koble Control UI til på nytt etter en omstart av Gateway» mislykkes. Hold liveness lokal og rimelig; la readiness rapportere migreringer eller initialisering uten å utløse en restart-storm.

Det risikable ved en oppgradering er at en release kan endre konfigurasjonsskjemaet for Gateway, inkluderte skills, browser-avhengigheter eller kanaladaptere. Les release notes, ta et snapshot av state, deploy målversjonen mot en gjenopprettet kopi og gjenta akseptansetesten. Hvis Gateway bare binder til loopback, eller proxyen slipper ikke gjennom WebSocket-oppgraderinger, bør du knytte klientforespørselen til den første relevante applikasjonsloggen i stedet for å slette state eller legge til redirects ukritisk.

Fem kontroller som er bedre enn container health

Release-registreringen for OpenClaw trenger fakta, ikke «ser bra ut». Lagre det valgte image-digestet, konfigurasjonens checksum, offentlig hostname og et tidsstemplet resultat for å koble sammen én meldingskanal, sende en innkommende melding, godkjenne avsenderen, kjøre et ufarlig verktøy og koble Control UI til på nytt etter en omstart av Gateway. Bruk eksempeldata uten produksjonsinnhold, slik at kontrollen kan kjøres etter hver deployment.

Bevis to lifecycle-hendelser separat. En utskifting av containeren må bevare normal drift; en ren recovery må vise at den gjenopprettede Gateway kan åpne workspace på nytt, gjenkjenne den sammenkoblede kanalen og bruke provider-autentisering uten ny onboarding. Mens kontrollene kjører, måler du parallelle agentkjøringer, modell-latens, prosesser for browser-verktøy og størrelsen på akkumulert session history, og tar vare på resultatet som forventet intervall for denne versjonen.

Test også en avvist eller ugyldig tilstand: blokker midlertidig testbanen som brukes av en nøkkel for model provider og minst én sammenkoblet kanal. OpenClaw skal feile på en måte som er mulig å diagnostisere, og skal ikke overskrive fungerende state. Gjenopprett den gyldige tilstanden, kjør eksempelet på nytt og legg ved relevante redigerte logger. Disse artefaktene gir en fremtidig rollback-beslutning konkret dokumentasjon.

Kjør den første produksjonslignende instansen

Hold den første OpenClaw-invokeringen reproduserbar nok til å kunne gjennomgås 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

Ikke stol på latest etter at du har fått reelle data. Ta vare på det fungerende digestet, container-brukeren og eierskapet til mountet. Følg applikasjonsloggen gjennom en fullstendig test — koble sammen én meldingskanal, send en innkommende melding, godkjenn avsenderen, kjør et ufarlig verktøy og koble Control UI til på nytt etter en omstart av Gateway — og noter eventuelle migreringer før du legger ruten bak produksjonstrafikk.

Gjør OpenClaw-recovery målbar

Et container-image kan lastes ned på nytt; OpenClaw-workspace, kanalstate og konfigurasjon kan ikke det. Mount /home/node/.openclaw før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Inspiser det effektive mountet i stedet for å stole på et Compose-filnavn, og kontroller at runtime-brukeren kan skrive der OpenClaw forventer det.

Velg retention og en destinasjon utenfor verten, og øv på recovery uten å berøre produksjon. Øvelsen er bare bestått når den gjenopprettede Gateway kan åpne workspace på nytt, gjenkjenne den sammenkoblede kanalen og bruke provider-autentisering uten ny onboarding. For databasebasert state kan du kombinere storage snapshots med applikasjonskonsistente exporter, som beskrevet i point-in-time recovery versus snapshots.

Test OpenClaw utenfra serveren

Se på den eksterne OpenClaw-URL-en som konfigurasjon som skal overleve redeployments. Konfigurer først den offentlige Gateway-adressen og en WebSocket-kompatibel proxy; rout deretter hostnavnet til port 18789 med opprinnelig host og scheme intakt.

Checklist for deployment-reachability kan bevise at forespørsler kommer inn i containeren. Etter dette bør den kjente feilen — at Gateway bare binder til loopback, eller at proxyen slipper ikke gjennom WebSocket-oppgraderinger — undersøkes i OpenClaw, state-en eller workloaden, ikke i sertifikatautomatiseringen.

Begrens rettighetene OpenClaw har

Bootstrap-credentials er midlertidige; tillitsmodellen er permanent. Med OpenClaw bør du passe på at Gateway-tokenet ikke står tomt, at ukjente kanalsammenkoblinger ikke godkjennes, og bruke én trust boundary per Gateway, gjennomgå hver DM-sammenkobling og sandbox-verktøy som berører verten.

Behandle OPENCLAW_GATEWAY_TOKEN i tråd med OpenClaw-rollen: hold sensitive verdier ute av Git, dokumenter effekten av rotasjon og bruk aldri et offentlig eksempel i produksjon. Kjør imaget uten unødvendige Linux capabilities og eksponer bare den offentlige applikasjonsruten. Sørg for at administratoraktivitet er synlig uten at secret-verdier logges.

Knytt OpenClaw til Dockups lifecycle

Plattformlaget for OpenClaw består av port 18789, ingress, TLS, runtime-konfigurasjon, lagring og avhengighetstilgjengelighet. Dockup kan reprodusere disse delene for sin egen infrastruktur eller en server kunden kobler til.

Deretter fullfører operatøren produktlaget: konfigurer den offentlige Gateway-adressen og en WebSocket-kompatibel proxy; håndhev denne tilgangsregelen — bruk én trust boundary per Gateway, gjennomgå hver DM-sammenkobling og sandbox-verktøy som berører verten; og kjør «koble sammen én meldingskanal, send en innkommende melding, godkjenn avsenderen, kjør et ufarlig verktøy og koble Control UI til på nytt etter en omstart av Gateway». Når denne testen registreres sammen med deploymenten, unngår man å forveksle automatisert provisioning med readiness for applikasjonen.

Vanlige spørsmål

Hva trenger OpenClaw for en produksjonsdeployment?

Rout OpenClaw-containeren på port 18789 gjennom én HTTPS-origin. Det eksterne leveringskravet er en nøkkel for model provider og minst én sammenkoblet kanal. Ikke regn OpenClaw som klar før du kan koble sammen én meldingskanal, sende en innkommende melding, godkjenne avsenderen, kjøre et ufarlig verktøy og koble Control UI til på nytt etter en omstart av Gateway.

Hvilke OpenClaw-data bør inngå i en sikkerhetskopi?

Gjør /home/node/.openclaw persistent, og inkluder OpenClaw-workspace, kanalstate og konfigurasjon i det samme recovery-manifestet. En ren OpenClaw-restore er bare vellykket når den gjenopprettede Gateway kan åpne workspace på nytt, gjenkjenne den sammenkoblede kanalen og bruke provider-autentisering uten ny onboarding.

Krever OpenClaw HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige OpenClaw-originen, og behold port 18789 på den interne ruten. Bruk OpenClaw-innstillingen riktig: konfigurer den offentlige Gateway-adressen og en WebSocket-kompatibel proxy. For OpenClaw beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for at origin-sensitiv klientatferd forblir konsistent.

Hvordan bør en OpenClaw-oppgradering testes?

Gjenopprett gjeldende OpenClaw-state i en isolert deployment, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom, fordi en release kan endre konfigurasjonsskjemaet for Gateway, inkluderte skills, browser-avhengigheter eller kanaladaptere. Behold det forrige OpenClaw-imaget til datamigreringen og rollback-grensen er forstått.