OpenClaw on Docker
What the setup script does, and what it does not
Docker is the middle road for OpenClaw: not the one-line install on your laptop, not a managed host, but an isolated Gateway you can throw away and rebuild. Upstream calls it optional, and that is the right word. Here is what the official flow does, where it bites, and when it stops being worth it.
What the setup script actually does
The official script builds the image locally or pulls a pre-built one, runs onboarding, which prompts for provider keys and writes a generated Gateway token to the .env file, and starts the Gateway with Docker Compose. Pre-built images are published to the GitHub Container Registry first, with a Docker Hub mirror, in slim and browser variants; a local build wants at least 6 GB of RAM.
- Sandboxing is off by default, and the Gateway itself does not need to run in a container for it to work.
- The Control UI is on port 18789; you paste the token from the .env file into its settings.
- Channels are added from the CLI container: a WhatsApp QR login, or a bot token for Telegram or Discord.
Where it bites
Three traps, all from the upstream page itself. Re-running setup with an empty shell rewrites the .env file from the current shell and its defaults, so changing only the image means editing .env and recreating the container instead. A home volume that covers the Playwright cache can hide the image’s bundled Chromium, so the browser stops being found after you switch to a browser variant. And when a new image cannot complete its startup migrations safely, the Gateway exits rather than reporting healthy, so a restart policy shows a container that keeps restarting until you run the doctor command against the same mounted state.
None of these are bugs. They are the shape of running a stateful service in a container: state lives in mounts, config lives in a file the script owns, and upgrades are your job. Our page on your own server sets out when that trade is still the right one.
Installs technically finishing, but still not being truly usable.
When Docker stops being worth it
Docker earns its keep when you want isolation on a machine you already run, or a Gateway you can rebuild from scratch. It stops earning it the moment the questions become about keeping it up: who restarts it, who upgrades the image, who backs up the state volume, who watches the logs. Hosted OpenClaw on Diali is what the same runtime looks like when those questions have answers: an isolated instance per agent, updates tested on our own agents first, backups, and a dashboard instead of a compose file.
A short checklist if you go ahead
- Use the official image names and pin a release tag for anything you rely on.
- Keep the state volume, and back it up before every image change.
- Read the security hardening page before exposing the Gateway on a VPS.
- Decide up front who owns the upgrade, because the container will not.
And whichever way you run it, the model bill is the same size: what OpenClaw actually costs.
Stop reading about it, build one
Set up an agent, pick a channel, and have it working inside the app you already keep open.
