How to Self-Host OpenClaw in 2026: Gateway, Channels and Security

Treat OpenClaw as a small system, not a Docker image. The user-facing goal for OpenClaw is clear: AI assistant gateway with 22+ channel integrations; the deployment is acceptable only when you can pair one messaging channel, send an inbound message, approve the sender, invoke a harmless tool and reconnect the Control UI after a Gateway restart.

That distinction catches the failure mode operators meet after local testing: the Gateway binds only to loopback or the proxy drops WebSocket upgrades. It also makes the backup and upgrade plan specific enough to test.

Choose the smallest viable OpenClaw topology

The smallest responsible OpenClaw topology contains one private listener on 18789, an ingress route and a documented state boundary. The external requirement for OpenClaw is a model-provider key and at least one paired channel. Test outbound DNS, TLS and provider behavior without publishing another inbound service.

Validate the topology by asking a clean client to pair one messaging channel, send an inbound message, approve the sender, invoke a harmless tool and reconnect the Control UI after a Gateway restart. Watch parallel agent turns, model latency, browser-tool processes and the size of accumulated session history while it runs. The result tells you whether the next improvement belongs in memory, storage, networking or a separate worker instead of encouraging arbitrary container sizing.

Diagnose a healthy-looking OpenClaw

An idle health check says little about OpenClaw. Watch parallel agent turns, model latency, browser-tool processes and the size of accumulated session history, then alert on the symptom users experience: failure of the action “pair one messaging channel, send an inbound message, approve the sender, invoke a harmless tool and reconnect the Control UI after a Gateway restart”. Keep liveness local and cheap; let readiness report migrations or initialization without causing a restart storm.

The risky upgrade area is that a release can change the Gateway configuration schema, bundled skills, browser dependencies or channel adapters. Read release notes, snapshot state, deploy the target version against a restored copy and repeat the acceptance action. If the Gateway binds only to loopback or the proxy drops WebSocket upgrades, correlate the client request with the first relevant application log rather than deleting state or adding redirects blindly.

Five checks stronger than container health

The release record for OpenClaw needs facts, not “looks good.” Store the selected image digest, configuration checksum, public hostname and a timestamped result for: pair one messaging channel, send an inbound message, approve the sender, invoke a harmless tool and reconnect the Control UI after a Gateway restart. Use non-production sample data so the check can run after every deployment.

Prove two lifecycle events separately. A container replacement must preserve normal operation; a clean recovery must show that the restored Gateway can reopen its workspace, recognize the paired channel and use provider authentication without onboarding again. While the checks run, measure parallel agent turns, model latency, browser-tool processes and the size of accumulated session history and retain the result as the expected envelope for this version.

Test a denied or invalid condition as well: temporarily deny the test path used by a model-provider key and at least one paired channel. OpenClaw should fail in a diagnosable way and should not overwrite healthy state. Return the valid condition, rerun the sample and attach the relevant redacted logs. Those artifacts give a future rollback decision concrete evidence.

Run the first production-shaped instance

Keep the initial OpenClaw invocation reproducible enough to review in a 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

Do not rely on latest after real data exists. Capture the working digest, container user and mount ownership. Follow the application log through a complete test — pair one messaging channel, send an inbound message, approve the sender, invoke a harmless tool and reconnect the Control UI after a Gateway restart — and note any migrations before putting the route behind production traffic.

Make OpenClaw recovery measurable

A container image can be downloaded again; the OpenClaw workspace, channel state and configuration cannot. Mount /home/node/.openclaw before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. Inspect the effective mount instead of trusting a Compose filename, and check that the runtime user can write where OpenClaw expects.

Choose retention and an off-host destination, then rehearse recovery without touching production. The drill passes only when the restored Gateway can reopen its workspace, recognize the paired channel and use provider authentication without onboarding again. For database-backed state, pair storage snapshots with application-consistent exports as described in point-in-time recovery versus snapshots.

Test OpenClaw from outside the server

Treat the external OpenClaw URL as configuration that survives redeploys. First configure the public Gateway address and WebSocket-capable proxy; then route the hostname to port 18789 with the original host and scheme intact.

The deployment reachability checklist can prove that requests enter the container. After that point, the known failure — the Gateway binds only to loopback or the proxy drops WebSocket upgrades — should be investigated in OpenClaw, its state or its workload rather than in certificate automation.

Reduce the authority held by OpenClaw

Bootstrap credentials are temporary; the trust model is permanent. With OpenClaw, watch for leaving the Gateway token unset or approving unknown channel pairings, and use one trust boundary per Gateway, review every DM pairing and sandbox tools that touch the host.

Treat OPENCLAW_GATEWAY_TOKEN according to its OpenClaw role: keep sensitive values out of Git, document rotation effects and never substitute a public example in production. Run the image without unnecessary Linux capabilities and expose only the public application route. Keep administrator activity visible without recording secret values.

Attach OpenClaw to Dockup's lifecycle

The platform layer for OpenClaw consists of port 18789, ingress, TLS, runtime configuration, storage and dependency reachability. Dockup can reproduce those pieces for its own infrastructure or a server the customer connects.

Then the operator finishes the product layer: configure the public Gateway address and WebSocket-capable proxy; enforce this access rule — use one trust boundary per Gateway, review every DM pairing and sandbox tools that touch the host; and run “pair one messaging channel, send an inbound message, approve the sender, invoke a harmless tool and reconnect the Control UI after a Gateway restart”. Recording that test alongside the deployment avoids confusing automated provisioning with application readiness.

Frequently asked questions

What does OpenClaw need for a production deployment?

Route the OpenClaw container on port 18789 through one HTTPS origin. The external delivery requirement is a model-provider key and at least one paired channel. Do not call OpenClaw ready until you can pair one messaging channel, send an inbound message, approve the sender, invoke a harmless tool and reconnect the Control UI after a Gateway restart.

Which OpenClaw data belongs in a backup?

Persist /home/node/.openclaw and include the OpenClaw workspace, channel state and configuration in the same recovery manifest. A clean OpenClaw restore passes only when the restored Gateway can reopen its workspace, recognize the paired channel and use provider authentication without onboarding again.

Does OpenClaw require HTTPS behind a reverse proxy?

Use HTTPS for the public OpenClaw origin and keep port 18789 on the internal route. Apply the OpenClaw setting correctly: configure the public Gateway address and WebSocket-capable proxy. For OpenClaw, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should an OpenClaw upgrade be tested?

Restore current OpenClaw state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because a release can change the Gateway configuration schema, bundled skills, browser dependencies or channel adapters. Keep the previous OpenClaw image until its data-migration and rollback boundary are understood.