Sådan selvhoster du OpenClaw i 2026: Gateway, kanaler og sikkerhed

Betragt OpenClaw som et lille system, ikke som et Docker-image. Målet for brugerne af OpenClaw er klart: en AI-assistent-Gateway med mere end 22 kanal-integrationer. Implementeringen er først acceptabel, når du kan parre én messaging-kanal, sende en indgående besked, godkende afsenderen, kalde et ufarligt værktøj og oprette forbindelse til Control UI igen efter en Gateway-genstart.

Denne skelnen afslører den fejltilstand, som operatører møder efter lokal test: Gateway binder kun til loopback, eller proxyen dropper WebSocket-opgraderinger. Den gør også backup- og opgraderingsplanen konkret nok til, at den kan testes.

Vælg den mindst mulige OpenClaw-topologi

Den mindste ansvarlige OpenClaw-topologi består af én privat listener på 18789, en ingress-route og en dokumenteret state-grænse. Det eksterne krav til OpenClaw er en modeludbyder-nøgle og mindst én parret kanal. Test outbound DNS, TLS og udbyderens funktion uden at eksponere endnu en inbound-service.

Validér topologien ved at bede en ren klient om at parre én messaging-kanal, sende en indgående besked, godkende afsenderen, kalde et ufarligt værktøj og oprette forbindelse til Control UI igen efter en Gateway-genstart. Hold øje med parallelle agent-kørsler, modellatens, browser-tool-processer og størrelsen på den akkumulerede sessionshistorik, mens det kører. Resultatet fortæller dig, om den næste forbedring hører hjemme i memory, storage, networking eller en separat worker, i stedet for at tilskynde til tilfældig dimensionering af containeren.

Diagnosticér en OpenClaw, der ser sund ud

Et inaktivt health check siger ikke meget om OpenClaw. Hold øje med parallelle agent-kørsler, modellatens, browser-tool-processer og størrelsen på den akkumulerede sessionshistorik, og sæt derefter alarmer på det symptom, brugerne oplever: at handlingen “parre én messaging-kanal, sende en indgående besked, godkende afsenderen, kalde et ufarligt værktøj og oprette forbindelse til Control UI igen efter en Gateway-genstart” mislykkes. Hold liveness lokal og billig; lad readiness rapportere migrations eller initialisering uden at udløse en restart storm.

Det risikable ved en opgradering er, at en release kan ændre Gateways konfigurationsschema, medfølgende skills, browserafhængigheder eller kanal-adaptere. Læs release notes, tag et snapshot af state, deploy målversionen mod en gendannet kopi, og gentag acceptancetesten. Hvis Gateway kun binder til loopback, eller proxyen dropper WebSocket-opgraderinger, skal du korrelere klientens request med den første relevante applikationslog i stedet for blindt at slette state eller tilføje redirects.

Fem checks, der er stærkere end container health

Release-registreringen for OpenClaw skal indeholde fakta, ikke “ser fint ud”. Gem det valgte image-digest, konfigurations-checksum, offentlige hostname og et tidsstemplet resultat for at parre én messaging-kanal, sende en indgående besked, godkende afsenderen, kalde et ufarligt værktøj og oprette forbindelse til Control UI igen efter en Gateway-genstart. Brug ikke-produktionsdata, så checket kan køres efter hver deployment.

Bevis to lifecycle-hændelser separat. En udskiftning af containeren skal bevare normal drift; en ren recovery skal vise, at den gendannede Gateway kan genåbne sit workspace, genkende den parrede kanal og bruge udbyderens authentication uden onboarding igen. Mål parallelle agent-kørsler, modellatens, browser-tool-processer og størrelsen på den akkumulerede sessionshistorik, mens checkene kører, og gem resultatet som det forventede niveau for denne version.

Test også en afvist eller ugyldig tilstand: Afvis midlertidigt den teststi, der bruges af en modeludbyder-nøgle og mindst én parret kanal. OpenClaw skal fejle på en måde, der kan diagnosticeres, og må ikke overskrive sund state. Gendan den gyldige tilstand, kør eksemplet igen, og vedhæft de relevante redigerede logs. Disse artefakter giver en fremtidig rollback-beslutning konkret evidens.

Kør den første produktionslignende instans

Hold den første OpenClaw-invocation reproducerbar nok til at kunne gennemgås i et 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

Stol ikke på latest, når der først findes rigtige data. Gem det fungerende digest, containerbrugeren og ejerskabet af mountet. Følg applikationsloggen gennem en komplet test — parring af én messaging-kanal, afsendelse af en indgående besked, godkendelse af afsenderen, kald af et ufarligt værktøj og genoprettelse af forbindelsen til Control UI efter en Gateway-genstart — og notér eventuelle migrations, før du sender produktions-trafik gennem routen.

Gør OpenClaw-recovery målbar

Et container-image kan downloades igen; OpenClaw-workspacet, kanal-state og konfigurationen kan ikke. Mount /home/node/.openclaw før bootstrap, skriv ufarlige eksempeldata, og udskift containeren for at bevise, at stien faktisk er persistent. Kontrollér det effektive mount i stedet for at stole på et Compose-filnavn, og tjek, at runtime-brugeren kan skrive dér, hvor OpenClaw forventer det.

Vælg retention og en destination uden for hosten, og øv recovery uden at røre produktionen. Øvelsen er kun godkendt, når den gendannede Gateway kan genåbne sit workspace, genkende den parrede kanal og bruge provider-authentication uden onboarding igen. For databasebaseret state skal storage-snapshots kombineres med application-consistent exports som beskrevet i point-in-time recovery versus snapshots.

Test OpenClaw udefra serveren

Betragt den eksterne OpenClaw-URL som konfiguration, der skal overleve redeployments. Konfigurér først den offentlige Gateway-adresse og en WebSocket-kompatibel proxy, og rout derefter hostnavnet til port 18789 med den oprindelige host og scheme intakt.

Deployment-reachability-checklisten kan bevise, at requests når ind i containeren. Derefter skal den kendte fejl — at Gateway kun binder til loopback, eller at proxyen dropper WebSocket-opgraderinger — undersøges i OpenClaw, dets state eller dets workload, ikke i certificate automation.

Begræns de rettigheder, OpenClaw har

Bootstrap-credentials er midlertidige; trust-modellen er permanent. Med OpenClaw skal du være opmærksom på, om Gateway-tokenet ikke er sat, eller om ukendte kanalparringer godkendes. Brug én trust boundary pr. Gateway, gennemgå hver DM-parring, og sandbox tools, der har adgang til hosten.

Behandl OPENCLAW_GATEWAY_TOKEN i overensstemmelse med dets OpenClaw-rolle: Hold sensitive værdier ude af Git, dokumentér konsekvenserne ved rotation, og brug aldrig et offentligt eksempel i produktion. Kør imaget uden unødvendige Linux-capabilities, og eksponér kun den offentlige application-route. Sørg for, at administratoraktivitet er synlig, uden at secret-værdier logges.

Knyt OpenClaw til Dockups lifecycle

Platformlaget for OpenClaw består af port 18789, ingress, TLS, runtime-konfiguration, storage og dependency-reachability. Dockup kan reproducere disse dele for sin egen infrastruktur eller en server, som kunden forbinder.

Derefter færdiggør operatøren produktlaget: Konfigurér den offentlige Gateway-adresse og en WebSocket-kompatibel proxy; håndhæv denne adgangsregel — brug én trust boundary pr. Gateway, gennemgå hver DM-parring, og sandbox tools, der har adgang til hosten — og kør “parre én messaging-kanal, sende en indgående besked, godkende afsenderen, kalde et ufarligt værktøj og oprette forbindelse til Control UI igen efter en Gateway-genstart”. Når testen registreres sammen med deploymenten, undgår man at forveksle automatiseret provisioning med application readiness.

Ofte stillede spørgsmål

Hvad skal OpenClaw bruge til en produktionsdeployment?

Rout OpenClaw-containeren på port 18789 gennem én HTTPS-origin. Det eksterne leveringskrav er en modeludbyder-nøgle og mindst én parret kanal. Kald ikke OpenClaw klar, før du kan parre én messaging-kanal, sende en indgående besked, godkende afsenderen, kalde et ufarligt værktøj og oprette forbindelse til Control UI igen efter en Gateway-genstart.

Hvilke OpenClaw-data skal med i en backup?

Persistér /home/node/.openclaw, og medtag OpenClaw-workspacet, kanal-state og konfigurationen i det samme recovery-manifest. En ren OpenClaw-restore er først godkendt, når den gendannede Gateway kan genåbne sit workspace, genkende den parrede kanal og bruge provider-authentication uden onboarding igen.

Kræver OpenClaw HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige OpenClaw-origin, og behold port 18789 på den interne route. Anvend OpenClaw-indstillingen korrekt: Konfigurér den offentlige Gateway-adresse og en WebSocket-kompatibel proxy. For OpenClaw beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet klientadfærd, der afhænger af origin.

Hvordan skal en OpenClaw-opgradering testes?

Gendan den aktuelle OpenClaw-state i en isoleret deployment, anvend kandidatversionen, og gentag dens acceptancetransaktion. Vær særligt opmærksom, fordi en release kan ændre Gateways konfigurationsschema, medfølgende skills, browserafhængigheder eller kanal-adaptere. Behold det tidligere OpenClaw-image, indtil grænsen for datamigration og rollback er forstået.