Headless browser sessions add Chromium processes, page rendering and browser-state memory on top of the Gateway. Multiple third-party 2026 guides move browser-heavy OpenClaw deployments from the 4 GB class toward 8–16 GB RAM and additional CPU cores.
For agents that repeatedly browse sites, fill forms, scrape pages or keep multiple browser sessions active.OpenClaw-Hardwareanforderungen: CPU, RAM, Speicher und lokale KI
Erfahre mehr über die OpenClaw-Hardwareanforderungen für Cloud-LLMs, Browserautomatisierung, Docker-Sandboxes, lokale Modelle und Zima-Heimserver-Optionen.
OpenClaw hardware requirements at a glance
Size OpenClaw in two layers: the Gateway and tools run on your server, while model inference can run either through a cloud provider or on separate local-model hardware. Browser automation, sandbox containers, multiple agents and local inference change the requirement far more than the basic Gateway alone.
- CPU
- OpenClaw does not publish one universal CPU-core minimum. With a cloud LLM, the Gateway is usually a lighter orchestration workload; browser automation, tool execution and multiple concurrent agents create the main local CPU demand.
- RAM
- OpenClaw does not publish one universal whole-server RAM minimum for normal native installs. Its official Docker guide requires at least 2 GB RAM to build the image locally. Third-party 2026 guides commonly place a practical cloud-model host around 4–8 GB, with more for browsers and multi-agent work.
- Storage
- Official documentation specifies enough disk for images and logs rather than one fixed capacity. For an always-on home server, SSD storage with headroom for Docker images, workspaces, sessions, browser data and logs is safer than sizing only for the application package.
- Runtime and OS
- Current OpenClaw supports macOS, Linux and Windows. The current runtime requirement is Node.js 22.22.3+, 24.15+ or 25.9+, with Node 26 recommended. Older third-party pages that say Node 20+ or Node 22.12+ are no longer current.
- GPU and local models
- A GPU is not required when OpenClaw uses cloud model APIs. Local inference is a separate hardware workload: OpenClaw's current official local-model guidance sets a much higher bar for a comfortable agent loop than simply loading a small quantized model.
- Best Zima starting point
- ZimaBoard 2 832 is a strong starting point for one or a few cloud-model agents and light browser/tool workloads. Choose 1664 for more memory headroom, ZimaCube 2 Pro for heavier multi-agent and co-hosted server workloads, and Creator Pack only when local GPU inference or another GPU workload is genuinely required.
From official requirements to the right setup
OpenClaw hardware selection starts with where the LLM runs, then adds browser automation, sandboxing, simultaneous agents, persistent workspace data and any other services sharing ZimaOS.
-
Official requirements
Decide whether model inference stays in the cloud or runs locally. Cloud providers keep the OpenClaw host relatively light because the server mainly runs the Gateway, channels, tools and state; local models move the much larger model-memory and inference workload onto your hardware.
-
Confirm your needs
Check the current official software baseline before sizing hardware: use a supported Node.js release and a supported macOS, Linux or Windows installation path. For Docker builds, OpenClaw currently requires at least 2 GB RAM because a 1 GB host can be OOM-killed during pnpm install.
-
Leave room to grow
List the local workload multipliers: Playwright/browser sessions, Docker sandboxes, multiple agents, cron jobs, file processing and other tool execution can consume substantially more CPU and RAM than a headless single-agent Gateway.
-
Run it on ZimaOS
Install OpenClaw from the ZimaOS App Store, connect the chosen model provider, configure channels and permissions, then monitor memory, CPU, disk growth and tool/browser concurrency during real workflows before adding local inference or more agents.
Check every playback client
- Cloud LLM API or local model inference
- Number of agents and messaging channels
- Browser automation and simultaneous Chromium sessions
- Docker sandboxing enabled or disabled
- Tool execution, cron jobs and file-processing workload
- Workspace, session, browser-data and log growth
- Always-on remote access and security boundary
- Other ZimaOS apps, VMs, storage and AI services running concurrently
Official minimum requirements
OpenClaw's current official documentation publishes software prerequisites and a Docker-build memory floor, but it does not define one universal whole-server CPU/RAM/storage minimum for every deployment. Hardware sizing depends heavily on cloud versus local inference and the tools enabled.
Use the current Node.js and platform requirements as the official software baseline, and use 2 GB RAM only as the official Docker image-build prerequisite—not as a universal recommended OpenClaw server size. For sustained cloud-model use, browser automation and local models, size from the actual workload.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Node.js runtime | Node.js 22.22.3+, 24.15+ or 25.9+; Node 26 recommended | OpenClaw changes quickly, so use the current official installation page rather than older third-party Node.js version claims. |
| Operating systems | macOS, Linux and Windows supported | Current official installation documentation includes native Windows paths as well as WSL2 options, so older claims that native Windows is unsupported are stale. |
| Docker image build | At least 2 GB RAM | The official Docker guide says pnpm install may be OOM-killed on a 1 GB host. This requirement applies to locally building the image and is not a general recommended RAM figure for every runtime workload. |
| Storage | Enough disk for images, workspaces and logs; no universal official capacity | Docker images, browser data, sessions, skills and logs can grow over time. Third-party 10–80 GB figures are workload planning estimates rather than official fixed minimums. |
| GPU | Not required for cloud-model OpenClaw | The Gateway can call hosted model providers, so local GPU hardware is unnecessary unless the same system also runs local model inference or another GPU-accelerated workload. |
| Local-model hardware | Separate high-end inference workload | OpenClaw's current official local-model guide says a comfortable local agent loop should target roughly two maxed-out Mac Studios or an equivalent GPU rig, and that a single 24 GB GPU is limited to lighter prompts at higher latency. This is far above merely being able to load a small quantized model. |
When to upgrade your hardware
Upgrade OpenClaw hardware for a specific workload multiplier—browser automation, multi-agent concurrency or local inference—not simply because the Gateway is installed.
Browser automation becomes a daily workload
Several agents, sandboxes or cron workflows run concurrently
You move model inference onto the same server
Multiple agent sessions and Docker sandboxes increase process count, memory pressure and disk use. The official sandbox architecture can create isolated containers for tool execution, so concurrency should be sized from the number of simultaneous jobs rather than the number of configured agents alone.
For always-on multi-channel agents, parallel automation, scheduled workflows and security-conscious sandboxed deployments.Local LLM inference is the largest hardware jump. Small quantized models can technically run on modest systems, but OpenClaw's own current local-model guidance warns that smaller or heavily quantized checkpoints can reduce context quality and prompt-injection resilience and recommends substantially higher-end hardware for a comfortable agent loop.
For users replacing cloud APIs with Ollama, LM Studio or another local OpenAI-compatible model server.Plan hardware growth with confidence
OpenClaw scales most cleanly when the Gateway, browser/sandbox workload, persistent workspace and model inference are treated as separate resources.
Keep the Gateway lightweight with cloud inference
When Anthropic, OpenAI, Google or another hosted provider performs inference, the local server mainly handles channels, sessions, tools and orchestration. This is the most hardware-efficient way to run an always-on OpenClaw home server.
Use ZimaBoard 2 for the Gateway and add RAM only when browser sessions, multiple agents or other ZimaOS services create measured pressure.Use SSD storage for persistent agent state
OpenClaw persists workspaces, session history, logs and tool data, while Docker and browser automation add images and caches. Third-party capacity estimates vary widely, which is why free-space monitoring matters more than one universal disk number.
Use SATA or NVMe SSD storage for sustained agent workloads instead of depending only on small onboard system storage.Separate local inference from the Gateway when necessary
OpenClaw can connect to Ollama, LM Studio and other model servers over a provider interface. Keeping the Gateway on a small always-on host and placing the model on a separate GPU system avoids forcing the control plane and inference workload to compete for the same resources.
Use ZimaBoard 2 or ZimaCube 2 as the Gateway and point it at a separate higher-end inference system when the local model exceeds the available GPU or memory.Budget resources for sandboxing and security
OpenClaw tools can access files, commands and external services. Docker or other sandbox backends can reduce the blast radius of tool execution but add container images, processes and browser runtimes that need CPU, memory and disk headroom.
Do not disable sandboxing purely to fit an undersized host; size the system so the security boundary required by the workflow can remain enabled.Can it run on ZimaOS?
OpenClaw is currently available in the ZimaOS App Store, making Zima hardware a direct always-on Gateway host. The key architecture decision is whether Zima only runs the Gateway and tools or also carries browser sandboxes and local model inference.
Install OpenClaw from the ZimaOS App Store
Use the current OpenClaw App Store package to keep the Gateway on an always-on ZimaOS system, then configure the model provider, channels and access controls for the workflows you actually need.
Open OpenClaw in the ZimaOS App StoreUse cloud providers to keep hardware requirements low
OpenClaw is model-agnostic and the Gateway can route requests to hosted providers. In this architecture Zima hardware runs the control plane, state and tools while model inference happens elsewhere, so no local GPU is required.
Read the OpenClaw getting-started guideKeep tool and network exposure intentionally constrained
OpenClaw agents can execute tools and access sensitive data. Use the official security and sandboxing controls, avoid unnecessary public Gateway exposure, review third-party skills/plugins and run security audits instead of treating a home LAN as a sufficient security boundary.
Read OpenClaw security guidanceChoose Zima hardware for your OpenClaw workload
The largest decision is cloud versus local inference. For cloud models, RAM and CPU mainly support browsers, tools and concurrency; for local models, inference memory and GPU capability quickly dominate the hardware decision.
Will the primary LLM inference stay on a cloud provider or separate inference server?
Yes — Zima runs the Gateway, tools and browser workloads
No local GPU is required. Start with 8 GB for an always-on cloud-model agent and move to 16 GB when browser automation, several agents or other containers need more headroom.
- Single/few cloud-model agents with light-to-moderate browser and tool useZimaBoard 2 832
- More browser automation, agents, channels or co-hosted servicesZimaBoard 2 1664
No — local AI or much heavier agent workloads share the server
Use ZimaCube 2 for more CPU, storage and expansion headroom. Creator Pack adds a dedicated GPU, but do not assume it meets OpenClaw's high-end official local-model target for every model; validate model size, context and GPU memory separately.
- Cloud-model agents plus heavier browser/NAS/home-server workloadsZimaCube 2 Standard
- Multi-agent automation, more containers and high local concurrencyZimaCube 2 Pro
- Local-model experimentation plus genuine GPU/AI workloadsZimaCube 2 Creator Pack
This is a workload guide, not a guaranteed agent-count, browser-session or tokens-per-second benchmark. Results depend on OpenClaw version, model provider, browser pages, sandbox policy, tool workloads, simultaneous agents, local model size/context, quantization and other ZimaOS services.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | An always-on OpenClaw Gateway using cloud model APIs, with one or a few agents and light-to-moderate browser or tool workloads. | Messaging channels, scheduled tasks, API-driven tools, light browser automation and ordinary ZimaOS services without local LLM inference. |
|
Eight gigabytes is practical for cloud-model use but can become constrained by several concurrent browser sessions, multiple sandboxes or other memory-heavy ZimaOS apps. The onboard 32 GB eMMC should not be treated as unlimited long-term agent storage. | Get Now |
| ZimaBoard 2 1664 | A cloud-model OpenClaw host with more browser automation, agents, channels and co-hosted services. | Always-on multi-channel use, moderate browser automation, multiple scheduled workflows and a broader compact ZimaOS homelab. |
|
Sixteen gigabytes helps Gateway-side concurrency but does not turn the N150 into a high-end local LLM platform. Keep serious local inference on separate GPU hardware. | Get Now |
| ZimaCube 2 Standard | OpenClaw cloud-model workloads combined with a larger NAS, persistent datasets, backups and heavier CPU-side home-server services. | Gateway, browser/tool automation, local document/workspace storage, backups and multiple ZimaOS apps where integrated multi-drive capacity matters. |
|
The Standard model has the same 8 GB system-memory class as ZimaBoard 2 832, so choose it for CPU/storage topology and expansion—not because it automatically gives more memory for multi-agent OpenClaw. | Get Now |
| ZimaCube 2 Pro | Heavier multi-agent OpenClaw automation combined with many containers, large local datasets and broader NAS/home-server workloads. | Several cloud-model agents, browser automation, Docker sandboxes, scheduled workflows, file processing and other always-on ZimaOS services. |
|
More cores and 10GbE do not substitute for GPU memory when the LLM itself runs locally. Local-model sizing must be done separately from Gateway sizing. | Get Now |
| ZimaCube 2 Creator Pack | OpenClaw combined with local-model experimentation, GPU-accelerated AI services, creator applications or heavy virtual machines. | Gateway and automation plus local AI inference or other GPU workloads where 64 GB system memory and a dedicated NVIDIA GPU are independently useful. |
|
Do not present Creator Pack as meeting OpenClaw's official comfortable-local-model target for every agent workload. Current OpenClaw guidance sets a very high bar for high-quality local agent loops; large models may still require a separate higher-end inference server. | Get Now |
What the Press Says
Highlights from trusted reviewers worldwide.
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”Read full review
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”Read full review
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”Read full review
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”Read full review
Loved by the Community
Stories and reviews from people who build with Zima every day.
★★★★★
Zima Blade Little yet Powerful
Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.
★★★★★
Very good!!
I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.
★★★★★
Great innovation for mini server!
It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.
★★★★★
Avaliação ZimaBoard 2
Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.
Frequently asked questions
These answers separate OpenClaw Gateway requirements from browser, sandbox and local-model workloads so third-party minimum figures are not mistaken for one official specification.
How much RAM does OpenClaw need?
OpenClaw does not publish one universal whole-server RAM minimum for every deployment. The official Docker guide requires at least 2 GB RAM to build the image locally. Third-party 2026 guidance varies widely—from sub-2 GB minimalist headless examples to 4 GB or more for daily use—so 4–8 GB is better treated as a practical cloud-model planning range, not an official minimum.
Is 8 GB RAM enough for OpenClaw?
Yes for many cloud-model personal deployments. Eight gigabytes gives substantially more headroom than the official Docker-build floor and aligns with several third-party recommendations for browser-capable or comfortable single-user setups. Several concurrent browsers, sandboxes, agents or other ZimaOS services can justify 16 GB.
Does OpenClaw need a GPU?
No when it uses Anthropic, OpenAI, Google or another hosted model provider. The local machine runs the Gateway, tools and state while inference happens remotely. A GPU becomes relevant only when you also run local model inference or another GPU-accelerated workload.
Can ZimaBoard 2 run OpenClaw?
Yes. OpenClaw is currently available in the ZimaOS App Store, and ZimaBoard 2 provides an Intel N150 with 8 GB or 16 GB RAM and dual 2.5GbE. The 832 is a strong cloud-model starting point; the 1664 adds memory headroom for more browser/tool concurrency and other services.
Can ZimaBoard 2 run a local LLM for OpenClaw?
It can run some small or heavily quantized CPU-based models, but that is different from a strong local OpenClaw agent experience. Current official OpenClaw local-model guidance recommends far more inference hardware for a comfortable agent loop and warns that small or aggressively quantized models can reduce context quality and prompt-injection resilience.
How much hardware does OpenClaw browser automation need?
There is no official fixed browser-RAM formula because page complexity and concurrency vary. Practical 2026 guides commonly move browser automation into the 8 GB class and recommend 16 GB for more comfortable or concurrent browser use. Size from the number of simultaneous browser sessions rather than simply enabling the feature.
Should I use cloud models or a local model with OpenClaw?
Use a cloud provider when you want the smallest, simplest always-on Gateway host. Use local inference when privacy, offline control or model ownership justifies the additional GPU and memory. A split design—small OpenClaw Gateway plus a separate local inference server—is often cleaner than forcing both workloads onto one box.
When should I choose ZimaCube 2 instead of ZimaBoard 2 for OpenClaw?
Choose ZimaBoard 2 for an efficient cloud-model Gateway and normal home-agent automation. Choose ZimaCube 2 when OpenClaw shares the machine with multi-drive storage, many containers, heavier browser/tool concurrency or local AI workloads. Creator Pack is the local-GPU option, but high-end local models may still need a larger dedicated inference system.
What sources and further reading informed this OpenClaw hardware guide?
The six references below are useful third-party workload examples, not a single authoritative hardware specification. SFAI Labs uses a 2-core/4 GB/10 GB floor, BoostedHost uses 2 GB as a fragile minimum and 4 GB as recommended, and the GitHub Gist documents much lighter headless Gateway profiles. ClawBox, Macaron and SafeClaw publish their own 2026 tiers for cloud and local AI. Several software-version statements in these pages are already stale: for example, Node 20+ or Node 22.12+ is older than OpenClaw's current official runtime requirement, and older claims that native Windows is unsupported no longer match current official installation documentation. Current OpenClaw docs take precedence whenever these sources conflict.
