OpenClaw Server Requirements

What a self-hosted OpenClaw instance genuinely needs, and why the answer is much smaller than people expect. The short version: no GPU, modest CPU, and a RAM figure decided almost entirely by whether you use browser automation.

Running the assistant is not running the model

This is the distinction that makes every other number on this page make sense, and it is the one most people get wrong before they start. Two very different jobs get talked about as if they were one:

• Running the model means turning tokens into tokens. That is the job that wants a GPU, a lot of VRAM and a large machine.
• Running the assistant means holding conversations, receiving messages from your chat platforms, deciding what to do, calling tools and keeping memory. That is ordinary application work: some CPU, modest RAM, a little disk.

OpenClaw is model-agnostic and you bring your own key, so it only does the second job. When it needs the model to think, it makes an HTTPS request to your provider and waits. Your instance spends most of its life idle on the network, which is exactly why a small server is enough and why a GPU would sit unused.

The tiers, and what separates them

The gap between them is not really about how much you use the assistant. It is about whether you use the two features that change its resource profile: browser automation and local inference.

Browser automation is the expensive feature

Everything else OpenClaw does is light. Browser automation is not, because a headless browser is a full browser: it renders pages, runs their JavaScript and holds their memory, and it does that per session rather than per instance. One automated browsing task is a substantial process sitting alongside your assistant, and two at once is two of them.

If browser automation is central to how you use OpenClaw, size for it directly and treat the assistant itself as a rounding error next to it. If you never touch it, the entry tier has far more headroom than you will use.

Integrations cost less than people assume

Each of the 20+ integrations keeps a persistent connection open to its platform. That is real but small, in the tens of megabytes, so connecting Telegram, WhatsApp, Discord and Slack at once is not four times the load of connecting one.

What does cost you is the content those platforms carry. Voice notes, photographs and documents all arrive as files that have to be received, held in memory while they are processed and then stored. An assistant used mainly for text is a very different tenant from one that people send attachments to all day, even at the same message volume.

CPU: rarely the constraint

Two cores are enough for normal use because the assistant is dominated by waiting: waiting on the model provider, waiting on an API, waiting on a message to arrive. More cores help when several things happen at once, particularly concurrent browser automation or a burst across multiple integrations. They do not make the assistant answer faster, because the thinking is not happening on your machine.

If you want to run the model locally

This is a legitimate setup and it changes the numbers completely. Model weights have to fit in memory alongside everything else: a 7B model quantised to 4 bits is roughly 4 GB before any conversation context and before OpenClaw itself. That rules out the 4 GB tier entirely and makes 8 GB the realistic floor for a small model.

Be clear-eyed about the trade too. Local inference on CPU is slow, and an assistant you have to wait thirty seconds for is one you stop using. The honest reasons to run locally are privacy and independence rather than performance, and if privacy is the goal it is worth knowing that a hosted model with a self-hosted assistant already keeps your conversation history, credentials and integrations on your own server. Read choosing an AI model for the full comparison.

Storage

20 GB covers the application, logs and conversation history comfortably. Media is what grows, and it grows quietly: every voice note, image and document that arrives over a chat integration is stored, and an assistant that generates files as well as receiving them grows faster again. If yours handles attachments rather than only text, 80 GB is the safer starting point.

The requirements that are not hardware

Two of them matter more than any figure above. The first is uptime: a chat assistant has to be connected when somebody messages it, and platforms deliver to a connection that either exists or does not. A machine that sleeps or a connection that changes address turns a working assistant into an unreliable one, which is a worse product than no assistant at all.

The second is a key with credit on it. OpenClaw does not bill you for model usage and cannot, because the account is yours. An assistant on a provider account with an empty balance stops answering with no warning inside OpenClaw itself, which is one of the more confusing failure modes and is covered in why an assistant stops responding.

Sizing it in one paragraph

If you are running a personal assistant on chat integrations with a hosted model, the entry tier is enough and will stay enough. Move up if you use browser automation, if attachments are a large part of what you send it, or if you intend to run a local model. Everything else, including the number of platforms you connect, moves the needle far less than any of those three.

Related reading

Ready to deploy? See the self-host OpenClaw guide and pricing, or read why self-host on a decentralized cloud for what the infrastructure underneath actually is.