OpenClaw system requirements: CPU, RAM, disk

OpenClaw itself is light: the gateway is a single Node.js process, and the official docs put the floor at 1 GB RAM, 1 CPU core, 500 MB of free disk and a 64-bit OS. Your real budget depends on what you attach to it: a personal Telegram bot calling a cloud model (OpenAI, Anthropic, avots.ai) runs well on 2 vCPU and 2-4 GB RAM, the browser tool (Chromium) pushes you to 4 vCPU and 8 GB, and a local model through Ollama means 16 GB RAM for an 8B model, or a GPU. Below we separate what the documentation states from what we see in our own deployments.

What the official docs actually say

There is no single "system requirements" page; the numbers sit in the install runbooks. Consolidated, with sources (checked 14 September 2026, docs at release v2026.9.4):

• Runtime: "Node 24.16+ or 26.1+; Node 26 recommended" (install page). The installer script provisions Node if it is missing.
• Minimum hardware: "1 GB RAM, 1 core, 500 MB free disk, 64-bit OS". This is the only explicit minimum in the docs, on the Raspberry Pi runbook, which recommends "2 GB+ RAM, 16 GB+ SD card (or USB SSD), Ethernet" and rates a 512 MB Pi Zero 2 W as "No".
• Docker source builds: "At least 6 GB RAM for a local source image build". Pre-built images from ghcr.io/openclaw/openclaw avoid this; a build ending in Killed or exit code 137 means the server is too small.
• Local models: the Pi page is blunt: "Do not run local LLMs on a Pi, even small models are too slow to be useful". No RAM or VRAM table for Ollama exists in the docs.
• Operating systems: macOS, Linux and Windows, where "WSL2 remains the most Linux-compatible Gateway runtime on Windows".

Requirements by setup

Gateway alone (cloud LLM, no browser, no local model)

This is what most people run: the gateway connects a messaging channel (Telegram uses long polling by default, so nothing listens on a public port) to a hosted model behind an API key. The provider does the heavy lifting; your server parses messages, keeps session files and runs the odd shell command.

In our deployments a fresh gateway with one Telegram bot idles at a few hundred MB of resident memory. We provision 2 vCPU and 2 GB as the practical minimum, because updates and the exec tool spike briefly, and 4 GB if the agent runs cron jobs or holds several long sessions. One vCPU works, but tool calls then compete with the gateway and you feel it as latency.

Gateway in Docker

The official image is ghcr.io/openclaw/openclaw:latest, with -slim and several -browser variants. Docker adds almost no CPU overhead, but two things change the memory maths:

• Do not build the image on the server: the docs' 6 GB is for compiling from source. With the pre-built image a 2 GB box is enough for the gateway alone.
• Sandbox mode needs Docker access inside the gateway container. The setting is agents.defaults.sandbox.mode with the values "off" (default), "non-main" and "all". The docs state that "the Gateway process always stays on the host; only tool execution moves into the sandbox when enabled"; for a Docker gateway the official setup script (OPENCLAW_SANDBOX=1) mounts the host Docker socket into the container. In our deployments of the 2026.6.1 image, mode "all" requires the docker command inside the gateway container. Sandbox containers are created on demand per agent or per session (agents.defaults.sandbox.scope), each with its own memory: budget 1-2 GB extra.

Per the gateway docs, in a container the default bind becomes auto (resolves to 0.0.0.0) instead of loopback, and auth is required by default. Still publish the port only on 127.0.0.1: with plain docker run that is -p 127.0.0.1:18789:18789; with the official compose setup, check the current Docker docs for the port mapping.

Browser variant (Chromium + Playwright)

The browser tool drives a dedicated Chromium (or Chrome, Brave, Edge) profile through Playwright. Keys in openclaw.json: browser.enabled (default true), browser.headless (default false), browser.noSandbox (default false) and browser.executablePath. In Docker you take the latest-browser image, which bakes Chromium in and keeps the Playwright cache under /home/node/.cache/ms-playwright.

The docs give no memory figure for the browser. Our numbers: headless Chromium with a couple of tabs takes 1-2 GB and spikes beyond that on heavy pages. In our deployments the browser variant is only enabled on servers with 6 GB or more total memory, and the container is capped at 5 GB. Below that, Chromium and the gateway fight for RAM and the gateway gets killed, the "Gateway exits during high memory use" symptom from the official troubleshooting guide. For comfort we recommend 4 vCPU and 8 GB.

Local models via Ollama

OpenClaw talks to Ollama through its native API: set baseUrl: "http://host:11434" with no /v1 suffix, because the OpenAI-compatible endpoint "breaks tool calling and models can emit raw tool-call JSON as plain text". Models are addressed as ollama/<model>.

The docs stay out of inference hardware. The table is our rule of thumb from running 4-bit quantised models (the default Ollama pulls) on our own GPU node, on top of the gateway's needs. Agent workloads need long contexts (tool schemas, long conversations), and the KV cache for that context is memory on top of the weights.

CPU-only inference of an 8B model on a 4 vCPU VPS gives a few tokens per second: fine for one question, frustrating when the agent loops through several tool calls. An 8-9B model at 4-bit fits a 16 GB GPU with room for a long context, hence our 16 GB GPU baseline. Our guide on what server to run a local AI model on covers the RAM-versus-GPU trade-off, and the AI servers page lists GPU configurations.

Sizing table

The first row is what the docs support; the rest is our provisioning guidance:

Any plan in our VPS catalogue from the 2 vCPU tier up covers the first three rows; the local-model rows belong on a GPU server.

Disk: images, logs and workspace

The docs' 500 MB is the bare install floor. On a real server the disk goes to:

• State directory ~/.openclaw (in the container /home/node/.openclaw): openclaw.json, the .env with secrets, session transcripts and the workspace (agents.defaults.workspace, default ~/.openclaw/workspace). Sessions grow with use.
• Docker images: the gateway and, in the browser variant, Chromium plus the Playwright cache.
• Logs: with --verbose they grow fast; set logrotate or Docker's max-size from day one.
• Ollama models, if local: 5 GB for an 8B at 4-bit, 40 GB for a 70B.

We start at 20 GB for a gateway-only server and 30 GB with the browser image, on SSD or NVMe; the Pi runbook says the same for its own reason, "SD cards are slow and wear out".

Network: outbound only

The gateway needs no inbound port: Telegram is fetched by long polling (webhook mode is optional) and model providers are called outbound over HTTPS. The gateway's own port, 18789 by default, serves the control UI and WebSocket API, and the docs are explicit: "Keep the Gateway loopback-only unless you are sure you need a bind". To reach the UI from your laptop, tunnel it:

ssh -N -L 18789:127.0.0.1:18789 user@gateway-host

This matters more than for a typical web app: the agent executes shell commands by design, and the project has already had a 1-click remote code execution issue (CVE-2026-25253, token theft) plus origin-validation flaws. A public gateway is a shell on your server for whoever finds it.

Firewall: SSH in, everything out, nothing else. Run openclaw security audit to confirm you have not drifted from secure defaults, and lock the bot to yourself with channels.telegram.allowFrom (the default DM policy is pairing: unknown senders wait for approval).

Operating system support

• Linux is the reference platform for a server: "the CLI remains the simplest option for a headless server or VPS", and openclaw gateway install renders a systemd user unit named openclaw-gateway.service. We run Ubuntu 24.04; any 64-bit distribution with Node 24 or 26 should do, x86_64 or ARM64.
• macOS works as a personal gateway (LaunchAgent ai.openclaw.gateway) on an always-on Mac.
• Windows has three documented paths: the native Windows Hub app, the PowerShell installer (iwr -useb https://openclaw.ai/install.ps1 | iex), or a gateway inside WSL2 (wsl --install -d Ubuntu-24.04, then the Linux quickstart). WSL2 takes its RAM from the host, so add what Windows itself needs.
• Phones and tablets are not gateway hosts. In OpenClaw terms they are "nodes", companion devices (macOS, iOS, watchOS, Android) for camera, screen or notifications; the docs state that nodes "don't run the gateway service".

How to check a server before you install

On Linux, confirm the box meets the floor:

nproc            # CPU cores
free -h          # RAM
df -h /          # free disk
uname -m         # must be 64-bit: x86_64 or aarch64
node --version   # 24.16+ or 26.1+ if already installed

Then install, run the onboarding, and let doctor check the result:

curl -fsSL https://openclaw.ai/install.sh | bash
# or
npm install -g openclaw@latest --allow-scripts=openclaw
openclaw onboard --install-daemon

openclaw --version
openclaw doctor
openclaw gateway status

If memory is tight, add swap before the first run; the Pi runbook's recipe (fallocate -l 2G /swapfile, vm.swappiness=10) works on any Linux VPS. If you would rather skip the sizing exercise, our ready OpenClaw server from 9.35 EUR a month is an Ubuntu 24.04 VM with the gateway already running in Docker, loopback-only: add a model key and connect your Telegram bot. The manual route is in our step-by-step install guide.

Questions

Can OpenClaw run on 1 GB of RAM?

Yes, for the gateway alone with a cloud model: the official minimum is 1 GB RAM, 1 core and 500 MB disk, and the Pi runbook rates 1 GB boards as "Tight" or "Slow", possible with swap and a minimal config. In our experience 1 GB leaves no room for the browser, sandbox containers or updates; 2 GB is the realistic start.

Does OpenClaw need a GPU?

No. A GPU only matters if you run the model locally through Ollama. With a hosted provider (OpenAI, Anthropic, avots.ai or any OpenAI-compatible gateway) the model runs elsewhere and the gateway is a small Node.js process.

How much RAM does the browser tool add?

The docs do not say. In our deployments headless Chromium under Playwright uses 1-2 GB and spikes higher, so we enable the browser variant only on servers with at least 6 GB total memory, cap the container at 5 GB, and recommend 8 GB.

Does the gateway need a public IP or open port?

No. Telegram uses outbound long polling and model calls are outbound HTTPS. Keep port 18789 on loopback, reach the UI through an SSH tunnel, and never publish it: the gateway can execute commands, and past CVEs targeted exactly that exposure.