OpenClaw setup: what you need before you start
Most OpenClaw setups fail for the same three reasons, and none of them is the install command. This guide covers the decisions you make before that: where it runs, which model it talks to, and how the chat bridges stay paired.
What OpenClaw is, in one paragraph
OpenClaw is an open-source personal AI assistant. The part that does the work is a small always-on gateway: it holds your configuration, connects to a model provider, and bridges into the places you already talk — WhatsApp, Telegram, Discord, Slack, email. It can browse, run skills, manage files and act on a schedule. Everything else in the project hangs off that process staying up.
The four things you need
1. Somewhere always-on. This is the requirement people underestimate. An assistant that answers at 3am, fires scheduled tasks and keeps chat pairings alive cannot live on a laptop that sleeps. A small server with 4 GB of memory is enough for the gateway plus bridges; add headroom if you plan to use browser automation.
2. A model key. OpenClaw is bring-your-own-key. An Anthropic or OpenAI key is the common choice; a local endpoint such as Ollama also works, with the trade-off that a quantized 7-8B model on CPU is noticeably less capable at multi-step agent work than a frontier model. Start with a commercial key and move parts of the workload local later if cost becomes the issue.
3. The chat accounts you want to bridge. Each bridge is paired once, interactively, and that pairing is the step most likely to need a console rather than a web form. Plan to be at a keyboard for the first run.
4. A decision about file access. OpenClaw can read and write a workspace. Decide up front what lives in it, because “everything” is a bad answer for something that also has a browser and an API key.
Where the first setup usually goes wrong
Pairing does not survive a restart. If the workspace is not on persistent storage, every restart means re-pairing every bridge. Verify persistence before you pair anything.
The gateway is exposed to the internet without authentication. This is the serious one. The gateway holds your model key and can act on your behalf; an open endpoint is a direct route to both. Keep it behind authentication and TLS, always.
Model spend surprises. An agent that retries, browses and summarises can burn tokens quickly. Set a budget at the provider, or route through a gateway such as LiteLLM that enforces caps per key. Do this on day one, not after the invoice.
Skills that assume a desktop. Some community skills expect a graphical session or a local application. On a headless server they fail in ways that look like configuration errors. Check what a skill needs before debugging it for an hour.
Local model or commercial API?
Both work. The practical difference is that agent loops — plan, call a tool, read the result, decide again — punish a weak model badly. Errors compound across steps.
A reasonable arrangement: a commercial model for the assistant’s reasoning, and a local Ollama endpoint for the bulk work behind it — classification, extraction, summarising long documents. A LiteLLM gateway in front lets you route by model name without changing OpenClaw’s configuration.
Running it yourself versus hosting it
The software is MIT-licensed, so running it yourself costs nothing but attention: a VPS, a container runtime, a reverse proxy with TLS, backups of the workspace, and an update routine you actually follow. For a technical user that is an ordinary evening.
The official OpenClaw Cloud is $49/month. A dedicated managed instance here is $9.99 — same software, we keep the process up and patched, you keep the workspace and the keys. The comparison worth making is not cloud-versus-self-host but what your evenings are worth.
Related reading
Questions
How much RAM does OpenClaw need?
Can OpenClaw run without an internet-facing URL?
Does it work with a local model?
Is OpenClaw the same thing as Clawdbot?
Put your AI stack on your own box
Pick an app, pick a size, and have it running today. Month to month, cancel whenever.