OpenHands executes real shell commands inside Docker sandboxes, so dependency installation, compilers, test suites and browser tools can make a nominally light 4-GB host run out of memory or become CPU-bound.
For larger Python, Node.js, Rust, Java, C/C++ or monorepo projects with substantial build and test workloads.OpenHands Hardware Requirements: CPU, RAM, Storage & Local LLM
Learn OpenHands hardware requirements for RAM, CPU, Docker sandboxes, local LLMs, VRAM, coding agents and ZimaOS hardware choices.
OpenHands hardware requirements at a glance
Separate the OpenHands controller and Docker sandbox from model inference. OpenHands itself can run on modest hardware when it calls a cloud or remote model; local coding models, long context and concurrent agent sandboxes create a much larger hardware requirement.
- CPU
- Current OpenHands local setup documentation recommends a modern processor but does not publish a universal minimum core count. Repository builds, tests, browser work and multiple Docker sandboxes can make extra CPU cores useful.
- RAM
- Current OpenHands documentation recommends a system with at least 4 GB RAM for the local GUI. That is the application/sandbox baseline, not the memory required by a local LLM. Eight or 16 GB gives more practical headroom for builds, tests and other ZimaOS services.
- Storage
- OpenHands publishes no universal disk-capacity minimum. Plan SSD space for Docker images, runtime containers, cloned repositories, build dependencies, package caches, logs and persistent workspaces; local model weights add a separate and often much larger storage requirement.
- Docker sandbox
- OpenHands runs agent code in isolated Docker runtime containers. The controller needs Docker access and each active task can create its own sandbox, so real RAM, CPU and disk use depends strongly on the repository and commands the agent executes.
- Local model hardware
- Current OpenHands local-LLM guidance recommends Qwen3.6-35B-A3B as the first model to try. Quantized variants require a recent GPU with at least 24 GB VRAM, or Apple Silicon with at least 64 GB unified memory; larger context or full precision can need more.
- Best Zima starting point
- ZimaBoard 2 832 is a strong starting point for a single-user OpenHands controller using cloud or remote models. Choose 1664 or ZimaCube 2 Pro for heavier builds and more concurrent containers. Same-machine local LLM inference should be sized from the model's VRAM requirement, not from OpenHands alone.
From official requirements to the right setup
OpenHands sizing starts with cloud versus local inference, then adds Docker sandbox workloads, repository size, build/test behavior, concurrency and persistent workspace storage.
-
Official requirements
Use the current official OpenHands host baseline first: macOS with Docker Desktop, Linux, or Windows through WSL/Docker, with a modern processor and at least 4 GB RAM recommended.
-
Confirm your needs
Decide where the LLM runs. A cloud provider or remote inference server keeps the Zima host focused on the controller and sandboxes. A same-machine local model adds its own model weights, KV cache, GPU/VRAM and long-context requirements.
-
Leave room to grow
Estimate the code-execution workload. OpenHands can clone repositories, install dependencies, compile code, run tests and browse the web inside Docker sandboxes. Large builds and parallel tasks can consume much more RAM, CPU and SSD space than an idle controller.
-
Run it on ZimaOS
Install OpenHands from ZimaOS, connect a representative model, mount a real repository and monitor CPU, RAM, Docker-disk growth and task latency during actual builds/tests before increasing concurrency or adding local inference.
Check every playback client
- Cloud API, remote inference server or same-machine local LLM
- Repository size and build dependency footprint
- Compile/test workload and CPU intensity
- Number of simultaneous agent tasks and sandboxes
- Browser automation and network-heavy tools
- Persistent repositories, Docker images and package caches
- Local-model VRAM, context length and quantization
- Other ZimaOS containers, NAS, VMs and development services
Official minimum requirements
OpenHands publishes a small local-host baseline for the controller and sandbox environment, while its separate local-LLM guide publishes much higher hardware guidance for capable coding models. These two layers should not be merged into one minimum specification.
Use a modern processor and at least 4 GB RAM as the current official OpenHands local-host baseline. No local GPU is required when model inference is remote. If the model runs locally, size it separately; current OpenHands guidance recommends a quantized Qwen3.6-35B-A3B deployment with at least 24 GB VRAM or 64 GB Apple unified memory.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Processor | Modern processor recommended | OpenHands does not publish a universal minimum CPU model or core count for the local GUI. Build and test workloads determine practical CPU demand. |
| System RAM | At least 4 GB recommended | This is the current official local OpenHands host guidance and covers the application/controller environment, not a local LLM. |
| Operating system | macOS, Linux, or Windows with WSL and Docker Desktop | The current local GUI guide lists these paths and notes Linux testing with Ubuntu 22.04. |
| Sandbox runtime | Docker required for the local GUI/runtime path | OpenHands uses Docker runtime containers for isolated code execution. The controller needs access to the Docker daemon/socket to launch agent sandboxes. |
| Local coding model | Current recommended starting model: Qwen3.6-35B-A3B | OpenHands' current local-LLM guide recommends this model for agentic coding rather than treating older OpenHands-LM 7B/32B models as the present default. |
| Local-model hardware | โฅ24 GB VRAM for quantized recommended model, or โฅ64 GB Apple unified memory | OpenHands recommends at least ~22K context on constrained hardware and 32K context for better performance. Full precision or larger context can require multiple GPUs or substantially more memory. |
When to upgrade your hardware
Upgrade OpenHands hardware when sandbox execution, concurrency or local inference becomes the measured bottleneck. The controller itself is rarely the reason to buy a large GPU system.
Repository builds and tests repeatedly exhaust the host
Several agent sessions run at the same time
You move the coding model onto the same server
Each active agent task can require its own runtime sandbox plus repository/workspace state. More concurrent sessions increase CPU, memory and Docker-storage pressure even when every LLM request is sent to a cloud provider.
For parallel coding tasks, automated maintenance, multiple repositories and headless/batch agent workflows.This is the largest hardware jump. Current OpenHands guidance recommends Qwen3.6-35B-A3B and at least 24 GB VRAM for quantized variants, while Lemonade independently recommends at least 16 GB VRAM for a lower-latency local integration. The current OpenHands upstream recommendation should take precedence.
For users replacing Claude, GPT, Gemini or another hosted model with LM Studio, Ollama, vLLM, SGLang or Lemonade.Plan hardware growth with confidence
OpenHands scales most cleanly when controller/sandbox resources, repository storage and LLM inference are treated as separate hardware layers.
Keep repositories and Docker data on SSD
Agent sandboxes repeatedly install packages, edit files and run tests. Docker images, package caches and cloned repositories can grow quickly and benefit from low-latency local storage.
Use SATA or NVMe SSD for OpenHands workspaces, Docker data and active repositories rather than relying indefinitely on small onboard eMMC.Keep model inference remote when the controller should stay small
OpenHands can connect to hosted providers and OpenAI-compatible local endpoints. Separating inference lets a low-power Zima host manage agent sandboxes without also carrying model weights and KV cache.
Use ZimaBoard 2 or ZimaCube 2 as the always-on controller and point it at a cloud provider or separate GPU inference server.Add system RAM for build/test headroom
The official 4-GB baseline is enough to get OpenHands running, but modern compilers, package managers, test runners and browser-based tools can consume several additional gigabytes inside the sandbox.
Move from 8 GB to 16 GB when real repositories regularly cause swapping, OOM failures or competition with other ZimaOS services.Size local GPU hardware from the current model, not old OpenHands-LM checkpoints
The supplied Hugging Face OpenHands-LM 7B v0.1 checkpoint dates from 2024 and is useful historical context, but current OpenHands documentation recommends Qwen3.6-35B-A3B for local use. Hardware planning should follow the current model and context target.
Verify exact GPU VRAM and 22Kโ32K+ context capability before selecting a local-inference configuration.Can it run on ZimaOS?
OpenHands is currently listed in the ZimaOS App Store. ZimaOS can host the OpenHands controller and persistent workspaces while model inference runs through a cloud API, a separate local inference server or, where hardware permits, the same machine.
Install OpenHands from the ZimaOS App Store
ZimaOS currently lists OpenHands in the AI category. Use the package as the always-on controller/UI layer, then configure the model provider and persistent project storage for the repositories you want the agent to work on.
Open OpenHands in the ZimaOS App StoreReserve resources for Docker sandboxes
OpenHands does not only serve a web UI: it launches isolated agent environments where code, package managers and tests actually run. Monitor Docker image growth and sandbox resource use rather than sizing the Zima host from idle OpenHands memory alone.
Read the OpenHands local setup guideUse remote inference when local model hardware is insufficient
Current upstream local-model guidance sets a high barโat least 24 GB VRAM for the recommended quantized Qwen3.6-35B-A3B path. If the installed Zima GPU does not meet the exact model requirement, keep OpenHands on ZimaOS and serve the model from another machine.
Read the OpenHands local-LLM guideChoose Zima hardware for your OpenHands workload
For cloud or remote inference, OpenHands is mainly a controller, Docker-sandbox and development-workload problem. CPU, RAM and fast workspace storage matter first. Local LLM inference is a separate high-memory GPU workload.
Will the primary coding model run on a cloud provider or separate inference server?
Yes โ Zima runs OpenHands and Docker sandboxes
ZimaBoard 2 832 already has twice the official 4-GB RAM baseline and is suitable for a single-user controller with light-to-moderate repositories. Choose 1664 or ZimaCube 2 Pro when builds, tests and concurrent sandboxes need more headroom.
- Single-user OpenHands with cloud models and normal repositoriesZimaBoard 2 832
- Heavier builds, more sandboxes and co-hosted development servicesZimaBoard 2 1664
No โ local model inference is also expected on the same system
Treat the model as the dominant hardware requirement. Current OpenHands guidance targets at least 24 GB VRAM for its recommended quantized local model. ZimaCube 2 Creator Pack provides a dedicated NVIDIA GPU path, but do not claim it meets this target until the exact installed GPU VRAM is verified; an external inference server may still be required.
- Stronger CPU/storage controller with remote local-model serverZimaCube 2 Standard
- More RAM/CPU for heavy sandboxes plus remote inferenceZimaCube 2 Pro
- Dedicated NVIDIA GPU experimentation; verify VRAM against โฅ24 GB targetZimaCube 2 Creator Pack
This is a workload guide, not a guaranteed repository size, agent-count, build-time or tokens-per-second benchmark. Results depend on OpenHands version, repository dependencies, test workload, sandbox concurrency, browser use, model provider, local model size/context and other ZimaOS services.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | A single-user OpenHands controller using cloud or remote models with light-to-moderate coding repositories. | Web UI, one active sandbox, normal package installation, tests, repository edits and ordinary ZimaOS developer services. |
|
Eight GB can become tight for memory-heavy compilers, browser tools or several containers, and 32 GB eMMC is too small for a growing Docker/repository workspace. Same-machine local coding models should not be assumed. | Get Now |
| ZimaBoard 2 1664 | OpenHands with heavier repositories, more build/test headroom and additional development containers while inference remains remote. | Larger dependency trees, multiple services, longer test runs, browser tooling and occasional parallel agent/container work. |
|
Extra RAM does not turn the N150 into a high-end local-LLM inference platform. Use it for controller-side workload headroom rather than as a substitute for a large-VRAM GPU. | Get Now |
| ZimaCube 2 Standard | OpenHands combined with larger code/data repositories, backups and multi-drive project storage while model inference stays remote. | Agent coding, project datasets, build artifacts, repository backups and several ZimaOS services where stronger CPU and storage topology matter. |
|
Standard still has 8 GB RAM, so it is not automatically better than ZimaBoard 2 1664 for memory-heavy sandboxes. Choose it mainly for CPU and integrated storage growth. | Get Now |
| ZimaCube 2 Pro | Heavier OpenHands controller workloads with multiple development services, larger repositories and faster shared storage. | Concurrent containers, compilation, tests, browser tools, project archives, CI-like automation and broader home-lab services. |
|
More CPU and 10GbE do not solve the โฅ24-GB-VRAM target of the current recommended local OpenHands model. Use remote inference or separately sized GPU hardware. | Get Now |
| ZimaCube 2 Creator Pack | OpenHands combined with GPU-based AI experimentation, large-memory development workloads and multi-drive project storage. | Agent controller, heavy sandboxes and a compatible local inference backend when the installed GPU is sufficient for the chosen model and context. |
|
Do not claim Creator Pack meets the current OpenHands recommended local-model target solely because it has a dedicated GPU. If the exact GPU has less than the required VRAM, keep inference on a separate larger GPU 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 OpenHands controller/sandbox requirements from the much larger hardware needs of local coding models.
How much RAM does OpenHands need?
Current OpenHands documentation recommends a modern processor and at least 4 GB RAM for the local GUI. That is the host/controller baseline. Real repositories, compilers, tests and Docker sandboxes can need more, while a local LLM requires a completely separate memory and GPU budget.
Is 8 GB RAM enough for OpenHands?
Yes for many single-user deployments using cloud or remote model inference. Eight GB is double the current official 4-GB baseline. Heavier builds, browser tooling, multiple containers or concurrent agent sessions can justify 16 GB or more.
Does OpenHands need a GPU?
No when the LLM runs through OpenHands Cloud, Anthropic, OpenAI, Gemini or another remote provider. OpenHands itself can run on CPU. A GPU becomes relevant only when you also run the coding model locally or deliberately expose GPU hardware to the sandbox.
How much VRAM does a local OpenHands model need?
Current OpenHands local-LLM guidance recommends Qwen3.6-35B-A3B and says quantized variants need a recent GPU with at least 24 GB VRAM, or Apple Silicon with at least 64 GB unified memory. It also recommends about 32K context for better performance, so VRAM requirements can rise with larger context or precision.
Can ZimaBoard 2 run OpenHands?
Yes. ZimaBoard 2 has a four-core Intel N150 and 8 GB or 16 GB RAM, exceeding the current OpenHands local-host baseline. It is best used as the OpenHands controller/sandbox host with a cloud or remote LLM, plus SSD storage for repositories and Docker data.
Why does OpenHands use more resources than a normal chat UI?
OpenHands is an autonomous coding agent, not only a chat frontend. It creates Docker sandboxes where the agent can clone repositories, install packages, edit files, run shell commands and execute tests. The workload inside those sandboxes can be heavier than the OpenHands controller itself.
Is OpenHands-LM 7B still the hardware target for local OpenHands?
No. The supplied Hugging Face OpenHands-LM 7B v0.1 checkpoint is an older OpenHands model from 2024 and remains useful for historical or experimental use. Current OpenHands documentation instead recommends Qwen3.6-35B-A3B as the first local model to try, so new hardware planning should follow the current upstream recommendation.
When should I choose ZimaCube 2 instead of ZimaBoard 2 for OpenHands?
Choose ZimaBoard 2 for a compact single-user controller using cloud/remote models. Choose ZimaCube 2 when you also need stronger CPU, larger project storage, more containers or heavier build/test workloads. Creator Pack adds a GPU path, but verify its exact VRAM before assuming it meets the current โฅ24-GB local-model recommendation.
What sources and further reading informed this OpenHands hardware guide?
The supplied Lemonade integration recommends at least 16 GB VRAM or 64 GB RAM for its low-latency local-model setup and uses 32K context; these are Lemonade/OpenHands local-inference recommendations, not the OpenHands controller minimum. Local AI Master correctly uses 4 GB RAM plus Docker for cloud-model OpenHands but its 16-GB-VRAM and older OpenHands-LM 32B hardware tiers are third-party planning examples; current upstream local-model guidance now recommends Qwen3.6-35B-A3B with at least 24 GB VRAM. Spheron's 8โ16-vCPU/32-GB controller plus H100/H200 design is a high-scale GPU-cloud architecture, not a home-server minimum. Clore.ai provides a GPU-server deployment example around an RTX 3090-class machine and should be treated as a provider template rather than canonical OpenHands requirements. The OpenHands-LM 7B v0.1 Hugging Face page is an older model artifact, not today's recommended local model baseline.
