Self-host OpenClaw with Docker: secure VPS setup

To self-host OpenClaw with Docker, use the project’s official Compose setup, keep its state directories persistent, and expose the gateway only through an authenticated private path. Treat the container as isolation, not immunity: limit mounts, verify backups, audit the configuration, and test recovery before trusting it with real accounts.

Decide whether Docker is the right boundary

Docker suits a repeatable gateway on a VPS or a disposable evaluation host. It is less appealing for the quickest local development loop, where the normal installer leaves fewer moving parts to inspect.

Define the risk first. OpenClaw is a tool-using personal assistant, so the meaningful boundary is the host and operator account. The project documents one trusted operator per gateway. Do not place unrelated or mutually untrusted users behind the same gateway and expect containers to provide tenant isolation.

For a VPS, start with a clean Linux host, Docker Engine, and Compose v2. The official build needs at least 2 GB of RAM; a smaller machine may terminate dependency installation during the image build. Leave extra disk space for source, images, logs, state, and backups. Rent boring infrastructure with headroom.

If you prefer a VPS whose catalog already recognizes the workload, Forpsi lists both OpenClaw and Docker among its software choices. That is provisioning convenience, not evidence that the resulting gateway is hardened.

Build with the official Compose flow

Clone the official repository, inspect the checkout, and run the setup helper from its root:

git clone https://github.com/openclaw/openclaw.git
cd openclaw
./scripts/docker/setup.sh

The helper builds a local image, prompts for model-provider credentials, generates a gateway token, prepares the persistent directories, and starts the gateway. Keep the generated environment file private and away from shell history, chat messages, and backup destinations without encryption.

The Compose configuration persists OpenClaw state, workspace data, and authentication profiles outside the replaceable container. Confirm those mounts before adding channels. A container that restarts cleanly but forgets its state is not reliable; it is merely punctual.

Use the CLI container to retrieve the dashboard link rather than guessing the address:

docker compose run --rm openclaw-cli dashboard --no-open

Paste the generated token into the Control UI. Do not publish the gateway port directly to the internet. Prefer loopback plus an SSH tunnel or a private overlay network. If a non-loopback bind is necessary, keep gateway authentication enabled and review Docker’s forwarding firewall path.

If the Control UI reports that pairing is required, approve the browser device instead of weakening authentication:

docker compose run --rm openclaw-cli devices list
docker compose run --rm openclaw-cli devices approve <requestId>

Fetch a fresh dashboard link after approval. Avoid community fixes that disable secure authentication or trust arbitrary host headers; that only widens the boundary to hide a pairing symptom.

Harden before connecting real accounts

Start with the smallest authority that supports the intended task. A personal assistant that can read files, execute commands, browse, and send messages has a broader failure radius than a chat window.

• Mount narrowly: expose only the workspace directories the assistant genuinely needs.
• Keep credentials separate: avoid mounting a home directory or broad secrets folder.
• Restrict senders: use pairing or allowlists before enabling messaging channels.
• Trim tools: deny execution, filesystem, automation, and elevated actions unless the workflow requires them.
• Review extensions: treat every plugin and skill as trusted code with local authority.

Run the project’s security audit after configuration changes and before widening network access:

docker compose run --rm openclaw-cli security audit --deep

Read every finding in context. An automatic fix can tighten a known default, but it cannot decide which files, contacts, or commands your assistant should reach.

Verify operations, backup, and recovery

Check container state and logs first:

docker compose ps
docker compose logs --tail=100 openclaw-gateway
docker compose run --rm openclaw-cli gateway status --require-rpc
docker compose run --rm openclaw-cli channels status --probe

A running container is only the first checkpoint. Require an RPC health check, confirm each configured channel, send a harmless test message, and verify that an unapproved sender cannot trigger the assistant.

Create a verified backup before an upgrade or major configuration change:

docker compose run --rm openclaw-cli backup create --verify

Move the archive to encrypted storage outside the live state directory. Then test the restore into a fresh target. A backup is evidence that bytes were written; a restore test is the fire drill that proves recovery can happen without improvisation during an outage.

For updates, keep the state mounts, rebuild or replace the image using the official Docker guidance, and watch readiness. If startup migration cannot complete safely, the gateway exits rather than claiming health. Repair it against the same mounted state before returning to normal service.

When to choose another setup

Choose Docker when you value a reproducible gateway, clean image replacement, and a visible boundary around persistent state. Use the normal local install when development speed on a private workstation matters more.

Avoid a self-hosted gateway if you cannot maintain host updates, private access, encrypted backups, and an allowlist for people who can message it. Managed convenience may reduce setup work, but it does not remove your responsibility for accounts, tools, and recovery.