OpenClaw on a VPS: The Full Self-Hosting Setup Guide

OpenClaw is a self-hosted, open-source AI agent. It used to go by Clawdbot, then Moltbot, before landing on its current name. It is not a hosting panel, not a control system, and it doesn't host anything for you. What it does is run on a machine you control, reason through a large language model you connect via API key, and carry out tasks autonomously, from browsing the web to running commands on whatever it can reach. That last part matters more than most setup guides let on, and I'll get to it properly below.

What is OpenClaw actually doing under the hood?

Strip away the agent framing and OpenClaw is a Docker container (or set of containers) that talks to Claude, OpenAI or Gemini through an API you supply the key for. The model does the thinking. OpenClaw does the acting: reading files, hitting URLs, running shell commands, controlling a browser if you've enabled that. It's an orchestration layer, not intelligence in its own right. Every meaningful decision it makes is a round trip to a model provider, which is why your model bill and your server bill are two entirely separate conversations, and usually not close in size.

What are the real OpenClaw requirements?

For basic chat-style use, 2GB of RAM and 2 cores will get you running, though it's a tight fit. 4GB is the figure most people settle on because it gives Docker and the container some breathing room without you watching memory pressure every day. If you're enabling browser automation, budget for around 8GB. A headless browser is memory-hungry on its own, before OpenClaw asks it to do anything.

Storage matters more than people expect. OpenClaw is I/O sensitive during Docker image pulls and when containers start, so a SATA SSD is the practical floor and NVMe is what I'd recommend if you're buying new. HDD-backed VPS plans, the kind still sold cheap by budget hosts, will work but you'll notice the drag every time you pull an image or restart the stack. Ubuntu 24.04 is the commonly recommended base OS, and macOS or Windows via WSL2 will also run it, but if you're deploying to a server rather than your laptop, Ubuntu is the path of least resistance.

Which VPS should you run OpenClaw on?

Don't overthink the provider, overthink the isolation. Any half-decent VPS with NVMe storage, 4GB RAM and a couple of cores will run OpenClaw comfortably for chat and light automation work. What actually varies between providers is how easy they make it to spin up a clean, disposable box, how their network egress is metered, and whether their control panel lets you snapshot before you let an autonomous agent loose on it. I've set clients up on general-purpose VPS providers and on hosts that specifically cater to Docker workloads, and both work, provided the specs are right. If you want the shortlist rather than a lecture on IOPS, our OpenClaw hosting picks cover providers we've actually tested for this exact use case. For the wider landscape of VPS options if you want to compare on your own terms, see our VPS hosting guide, and if you're specifically weighing providers on how well they handle containers, our Docker hosting comparison is the more relevant read.

How do you install Docker before running OpenClaw?

Docker is the standard install path for OpenClaw and there's no point improvising an alternative. On a fresh Ubuntu 24.04 VPS, follow Docker's own installation instructions rather than a copy-pasted script from a random blog post, because Docker changes its recommended install method periodically and the official docs are the only source that stays current. Once Docker's installed, confirm it's running and that your user can execute Docker commands without sudo for every single line, which saves a lot of irritation later. Don't skip the step of setting resource limits on the container. Docker's own guidance on container resource constraints is worth ten minutes of reading, because an unconstrained agent container on a small VPS can quietly eat all your memory and take the box down with it.

How do you actually run OpenClaw once Docker is set up?

Once Docker's confirmed working, you pull the OpenClaw image, set your environment variables (API key, any config flags for browser automation or file access), and bring the container up. This is a five-minute job on paper. In practice, most of the time people lose is spent on the two things this guide has already flagged: insufficient RAM causing the container to crash on startup, or slow disk causing the image pull to hang long enough that people assume something's broken. If your VPS meets the 4GB/NVMe bar, this step is genuinely boring, which is the goal.

Where does the API key go and what will it actually cost?

You'll supply an API key for whichever model provider you're using, Claude, OpenAI or Gemini are the usual choices, and OpenClaw uses that key to make calls on your behalf. Be honest with yourself about what this means financially. The VPS itself is a few pounds a month, genuinely trivial. The model usage is not. An agent running continuously, reading pages, reasoning through multi-step tasks, retrying failed actions, racks up tokens fast against a frontier model, and that bill is what actually surprises people, not the hosting invoice. I've had clients budget carefully for the server and then get blindsided by a model bill several times larger a month in. Set a spending cap on the API key itself if your provider allows it. Don't rely on willpower to notice usage climbing.

What should OpenClaw be allowed to reach?

This is the part of the setup that actually matters, more than RAM or disk speed. OpenClaw is an autonomous process that can read the open web and act on what it reads. That means it can be prompt-injected: a malicious or just poorly-behaved page can contain instructions designed to hijack what the agent does next, and the agent has no inherent way to tell "content I'm reading" from "instructions I should follow". Once that happens, the damage it can do is bounded by what the machine it's running on can reach, nothing more, nothing less.

The standard advice, and the advice I give every client who asks, is to run OpenClaw on a dedicated machine or VPS that holds no sensitive personal data and no private credentials. Not "a folder it can't see", a machine that simply doesn't have anything worth stealing on it. Concretely, that means:

Give it its own cheap VPS. Don't run it alongside your production website, your database, or anything with customer data. The isolation is the point, and a small dedicated box costs little enough that there's no good excuse to share infrastructure.

Use a least-privilege API key with a spending cap. If your model provider supports scoped keys or usage limits, use them. A compromised agent with an uncapped key is a much worse night than a compromised agent with a key that maxes out at a modest ceiling.

Think hard about outbound network access. If OpenClaw doesn't need to reach your internal network, your other servers, or anything beyond the open internet, don't let it. Firewall rules that restrict outbound connections limit the blast radius if something does go wrong, and they cost nothing to set up.

None of this is exotic security practice. It's the same logic you'd apply to any process you didn't fully trust, because functionally, that's what an LLM-driven agent is. Trust the isolation, not the model's good behaviour.

How do you keep OpenClaw running and updated?

Treat it like any other Docker workload: pull updated images periodically, don't let the container drift for months without attention, and keep an eye on disk usage since Docker images accumulate over time if you're not pruning old ones. Because the machine should hold nothing sensitive, updates are low-stakes in the way they wouldn't be on a production server, you can restart, rebuild, or nuke and redeploy the whole box without the usual dread. That's a genuine advantage of the isolated-VPS approach beyond the security argument. If you're still choosing between providers for this, our hosting directory lists providers by the specs that actually matter here rather than marketing copy.

Frequently asked questions

Can I run OpenClaw on shared hosting?

No. Shared hosting doesn't give you Docker or root access, and OpenClaw needs both. You need a VPS or dedicated machine where you control the operating system.

Do I need a GPU to run OpenClaw?

No. OpenClaw doesn't run the model locally, it calls Claude, OpenAI or Gemini over the API, so the reasoning happens on the provider's infrastructure. Your server just needs to run the agent framework itself, which is a CPU and RAM job, not a GPU one.

Is OpenClaw safe to run on my main server?

Standard guidance is no, and I'd second that firmly. Run it on a dedicated machine with no sensitive data or credentials, because a prompt-injected agent can reach whatever the host can reach.

Why is my OpenClaw bill higher than expected?

Almost always the model usage, not the server. Continuous agent activity against a frontier model burns tokens quickly, and that cost is usually the larger of the two by some margin. Set a spending cap on your API key.

Final thoughts

Getting OpenClaw running is the easy part, a decent VPS and an afternoon with Docker will do it. The part worth taking seriously is the isolation: a dedicated box with nothing valuable on it, a capped API key, and restricted outbound access. Get that right and the rest is just server administration. Get it wrong and you've built an autonomous process with access to everything you own.