If you want to run OpenClaw yourself instead of on a managed host, Docker is the cleanest path: the upstream repo ships everything you need to bring the whole stack up with one command. This guide walks the real setup, calls out the numbers that actually bite, and is honest about the point where a managed host like ShipClaw costs less all-in than your own time.

OpenClaw is the open-source, self-hosted personal AI assistant Gateway at github.com/openclaw/openclaw — MIT-licensed and written in TypeScript. It is an independent project (not Anthropic's), and you can run it on any box you control.

What the Docker setup gives you (6 min)

The repository includes a Dockerfile and a docker-compose.yml, so you are not assembling a container spec by hand. The compose file defines two services:

openclaw-gateway — the long-running Gateway process. It binds the LAN by default and listens on port 18789, with a healthcheck that polls /healthz every 30 seconds. Two more ports are mapped for optional channels: 18790 (bridge) and 3978 (Microsoft Teams).
openclaw-cli — a companion container that shares the gateway's network for running one-off CLI commands against the same state.

Both services build from the same local image, tagged openclaw:local by default (overridable via the OPENCLAW_IMAGE variable), and mount three directories you care about:

Mounted path (in container)	What lives there
`/home/node/.openclaw`	State + your `openclaw.json` config
`/home/node/.openclaw/workspace`	The agent's working files
`/home/node/.config/openclaw`	Auth secrets

Steps

Clone the repository. Pull github.com/openclaw/openclaw to the host that will run the agent.
```
git clone https://github.com/openclaw/openclaw.git
cd openclaw
```
Build and start the stack. Compose builds the image and starts the gateway in the background.
```
docker compose up -d --build
```
You should see the openclaw-gateway container become healthy once /healthz responds — check with docker compose ps.
Point the config at a model. OpenClaw reads ~/.openclaw/openclaw.json (mounted to /home/node/.openclaw in the container). The minimal file is just your provider and model:
```
{
  "agent": {
    "model": "<provider>/<model-id>"
  }
}
```
Self-hosting is bring-your-own-key: this is where you decide which provider you pay directly. See OpenClaw hardware requirements for why the API relationship — not the box — is usually the constraint.
Connect a channel. For Telegram, create a bot with @BotFather, then paste the token into your channel config following the upstream channel docs at docs.openclaw.ai/channels/telegram. Our connect a Telegram bot walkthrough covers the BotFather half step by step.
Keep it healthy. Re-pull the repo and re-run docker compose up -d --build whenever OpenClaw ships a new version — the upgrade treadmill is the recurring cost of self-hosting.

Verification

Confirm the gateway is up and reachable:

curl -fsS http://localhost:18789/healthz && echo " gateway healthy"

A healthy gateway returns a success response; if curl fails, the container is still building, crashed on a bad config, or the port isn't published — check docker compose logs openclaw-gateway.

The number that bites: browser memory

The single most important operational fact when you self-host: the stealth browser is Chromium, and it is the cost center, not OpenClaw itself. OpenClaw's own process fits in roughly 300 MB; Chromium is everything above that. On our pool nodes we watchdog-kill at 1.5 GB, and the built image is around 1.5 GB on disk. That means:

Give it 2 GB of RAM. A 1 GB box will technically boot but will thrash the moment the agent does real browser work.
The second user costs as much as the first. Each active session holds its own Chromium process, so you cannot pack many users onto one host without writing orchestration yourself.

Docker vs. the global install

Docker isn't the only self-host route. OpenClaw also ships as a global npm package, which some people prefer for a single-user box:

npm install -g openclaw@latest
openclaw onboard --install-daemon

That path needs a recent Node (24.15+ is the recommended line) and installs a background daemon directly on the host. Use it when you want the agent welded to one machine and don't care about container isolation. Reach for the Docker compose route instead when you want reproducible builds, the state and workspace volumes kept tidy, and a clean docker compose down to tear everything back out — which is why compose is the path this guide recommends.

Troubleshooting

Symptom	Likely cause	Fix
`curl /healthz` refuses connection	Gateway still building, or port 18789 not published	`docker compose logs openclaw-gateway`; confirm the port mapping and wait for the healthcheck
Container gets OOM-killed under load	Chromium exceeded available RAM	Move to a 2 GB+ host; the browser, not OpenClaw, is the memory hog
Agent boots but never answers messages	Channel token missing or `agent.model` unset in `openclaw.json`	Re-check the config file and the channel setup

When managed hosting is the cheaper path

Docker makes the install easy. It does nothing about the operations: image upgrades, browser-fingerprint churn, memory watchdogs, and the Anthropic (or other provider) tier limits that throttle a fresh key under agent load. That recurring tax is the honest argument for managed hosting.

On ShipClaw you skip all of it: agents run on shared pool nodes, idle processes suspend so you're not paying for a sleeping browser, memory is watchdogged for you, and the provider relationship is pooled. There's no monthly fee — you buy credits and the agent is live in about 60 seconds.

Self-host with Docker if you enjoy the operational work or your token spend dwarfs any hosting margin. If you'd rather never think about a Chromium memory leak again, see how managed OpenClaw hosting compares.

OpenClaw Docker: self-host with docker compose