Skip to main content
Use this runtime flow after provisioning a VM and installing Docker. Provider guides such as GCP and Hetzner own VM creation, firewall rules, SSH access, and the tunnel back to your laptop. This page owns the Docker setup shared by those hosts.

​
Before you begin

You need:
  • A Debian or Ubuntu VM with Docker Engine and Docker Compose v2
  • At least 6 GB RAM for a source image build; smaller hosts should use the official pre-built image below
  • The OpenClaw source checkout on the VM
  • Provider and model credentials for onboarding
  • An SSH-only or otherwise restricted provider firewall; do not expose the Gateway port directly to the public Internet
From the VM:

​
Prepare persistent host state

The maintained setup script defaults state to the current VM user’s home:
Override those paths before setup if your VM uses a dedicated data disk. Keep all three directories in backups. Current OAuth token material is stored as plaintext in SQLite under OPENCLAW_CONFIG_DIR, including access, refresh, and ID-token values. Treat the config directory and its backups or copies as credentials. The auth-profile secret directory contains only the local key used to recover legacy encrypted OAuth sidecar credentials. It must persist for that recovery path and remain separate from OPENCLAW_CONFIG_DIR, but it does not encrypt current SQLite rows or protect a state-only backup or copy.

​
Run the maintained Docker setup

The script creates the host directories, builds openclaw:local, runs onboarding, generates a Gateway token, synchronizes .env, and starts the Gateway through the repository’s docker-compose.yml. The Compose file pins container-side state to /home/node/.openclaw while using the host paths above as bind-mount sources. To use an official prebuilt image instead of building from source:
For unattended setup, provider SecretRefs, extra mounts, sandbox setup, and all supported environment variables, use the full Docker guide.
OPENCLAW_GATEWAY_BIND=lan is the normal container setting: loopback would limit the Gateway to the container’s own network namespace. Keep the published host port private with the cloud firewall, then reach it through the SSH tunnel from the provider guide.

​
Bake required binaries into the image

Installing binaries inside a running container is a trap: anything installed at runtime is lost when the container is recreated. Bake every external binary a skill needs into the image at build time. The examples below cover three binaries only, alphabetically:
  • gog (from gogcli) for Gmail access
  • goplaces for Google Places
  • wacli for WhatsApp
These are examples, not a complete list. Docker Compose builds the repo-root Dockerfile, so extend that file rather than creating a standalone example or replacing its contents. The repository Dockerfile has required manifest extraction, build, production dependency, runtime-assets, and final runtime stages. Build and production installs share the same manifests and lockfile, including packages/* and selected plugin workspaces. For Debian packages, prefer the existing build argument:
For downloaded release binaries such as gog, goplaces, or wacli, add the download and install commands to the repo-root Dockerfile final runtime stage, after its package-install blocks and before USER node. Preserve the existing non-root uid 1000 setup, tini entrypoint, health check, and openclaw symlink.
The repository Dockerfile digest-pins its Node and Bun base images. Keep those reviewed pins instead of changing them to floating FROM node:24-bookworm references. For ARM-based VMs, choose arm64 release assets for extra binaries; for reproducible builds, use versioned asset URLs and verify their checksums.
Rebuild the customized image without repeating onboarding:
If the build fails with Killed or exit code 137 during dependency installation or bundling, the VM is out of memory. Resize it before retrying. Verify baked binaries:

​
Verify and administer the Gateway

/healthz returning a 200 response confirms that the Gateway process is listening. The image HEALTHCHECK polls the same endpoint. If the Control UI requires device approval:

​
What persists where

OpenClaw runs in Docker, but the container filesystem is not the source of truth. Long-lived state must survive restarts, rebuilds, and reboots.

​
Common pitfall: never file-bind openclaw.json

Mount the gateway state as a directory, never as a single file. The repo docker-compose.yml already does this:
A single-file bind remains attached to the mounted file. Normal OpenClaw configuration saves replace openclaw.json. If a host-side save replaces the source of a single-file bind after the container starts, the container can keep reading the old file while the host path points to the new one. The host-side save can succeed without updating what the container sees. An edit that writes to the same file in place does not cause this divergence. Fix: keep the directory mount from Compose. Edit openclaw.json on the host inside that directory.

​
Update OpenClaw

For a source-built image:
For a pinned or prebuilt image, update OPENCLAW_IMAGE to the intended tag or digest before rerunning the setup script. Routine image upgrades run startup-safe migrations against the mounted state; see Upgrading container images for recovery when a migration cannot complete automatically.