Open WebUI says its default local embedding model uses roughly 500 MB RAM per worker, while the default pypdf extraction path can leak memory during repeated ingestion. At larger document volumes, external embeddings and Tika/Docling-style extraction reduce pressure on the UI container.
For users moving from a handful of PDFs to hundreds of documents, shared knowledge bases or repeated ingestion jobs.Requisitos de hardware do Open WebUI: CPU, RAM, armazenamento e IA local
Conheça os requisitos de hardware do Open WebUI para RAM, CPU, RAG, Ollama, modelos locais, implementações multiutilizador e opções de hardware do ZimaOS.
Open WebUI hardware requirements at a glance
Separate the Open WebUI application from the model runtime. Open WebUI can stay relatively light when it connects to cloud APIs or a remote Ollama server; local embeddings, document ingestion, multi-user concurrency and local LLM inference add separate resource requirements.
- CPU
- Open WebUI does not publish one official minimum CPU-core count. A single-user UI connected to a remote model is light, while document parsing, embeddings, many concurrent requests and other local tools increase CPU demand.
- RAM
- Open WebUI upstream does not publish a universal minimum or recommended RAM figure. The current ZimaOS App Store metadata lists 512 MB minimum memory for its package, while a 2025 community measurement estimated about 1 GB RAM for Open WebUI by itself. Treat both as application-level floors, not local-LLM requirements.
- Storage
- Open WebUI needs persistent application data for users, chats, files and RAG indexes. Community measurements place the container/update footprint around the 10 GB spare-disk class, but local model files belong to Ollama or another inference runtime and can add tens to hundreds of gigabytes.
- RAG and embeddings
- Open WebUI's default local SentenceTransformers embedding model uses roughly 500 MB RAM per worker. Regular document ingestion can also make the default pypdf extractor grow memory, so external embedding and extraction services become more important as document volume or user count increases.
- GPU
- A GPU is not required for Open WebUI when the chat model and embeddings run through external APIs or another inference server. Open WebUI's CUDA image can accelerate local embeddings, reranking and Whisper, while Ollama or another model runtime has its own separate VRAM requirement.
- Best Zima starting point
- ZimaBoard 2 832 is a strong starting point for a single-user or small-family Open WebUI using cloud or remote models. Choose 1664 for more RAG, local embeddings and co-hosted services, and move to ZimaCube 2 when multi-user data, large document collections, local inference or broader NAS workloads justify it.
From official requirements to the right setup
Open WebUI sizing starts with where model inference runs, then adds RAG, document ingestion, database concurrency, local embeddings and other ZimaOS applications.
-
Official requirements
Decide whether Open WebUI connects to a cloud API, a remote Ollama/vLLM server or a model runtime on the same Zima device. Only the third option makes local LLM RAM and VRAM part of the same hardware budget.
-
Confirm your needs
Size the Open WebUI application layer separately. Upstream documentation publishes performance behavior rather than a universal RAM/CPU minimum; ZimaOS package metadata currently lists 512 MB minimum memory, and community measurements suggest roughly 1 GB RAM and about 10 GB spare disk for the UI by itself.
-
Leave room to grow
Add RAG and concurrency costs. The default local embedding model consumes about 500 MB RAM per worker, document parsing can cause memory growth, and multi-user deployments should move away from default SQLite/local-vector assumptions toward PostgreSQL and scalable external services.
-
Run it on ZimaOS
Install Open WebUI from ZimaOS, connect a representative model provider, upload real documents if RAG is required, then monitor container RAM, database I/O, embedding memory, document-processing behavior and model-server latency before scaling users or models.
Check every playback client
- Cloud API, remote model server or same-machine local inference
- Single-user, household or multi-user deployment
- RAG enabled and approximate document count
- Local SentenceTransformers embeddings or external embedding API
- Document extraction using pypdf, Tika, Docling or another service
- SQLite on local SSD or PostgreSQL for concurrency
- Ollama/model-library storage if inference is local
- Other ZimaOS apps, VMs, NAS and AI services running concurrently
Official minimum requirements
Open WebUI currently does not publish a universal minimum CPU, RAM or disk specification in its upstream documentation. Its official performance guide instead explains how resource use changes with embeddings, document extraction, database choice, workers and concurrency.
Do not present 8 GB, 16 GB or a GPU as an official Open WebUI minimum. The application can run on modest hardware when inference is external, while local RAG and multi-user features add measurable RAM and database demand. Size Ollama or another local model runtime independently.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Official CPU/RAM minimum | No universal upstream figure published | Open WebUI's current docs describe weak-hardware, single-user and high-scale deployment patterns rather than one minimum CPU-core or whole-system RAM number. |
| Default embedding memory | Approximately 500 MB RAM per worker | The default all-MiniLM-L6-v2 SentenceTransformers model loads inside each Open WebUI worker. Eight workers can therefore consume about 4 GB RAM just for embeddings. |
| Document extraction | Default pypdf path can cause persistent memory growth | Open WebUI recommends external extractors such as Tika or Docling for deployments that process documents regularly, moving memory-intensive extraction out of the main process. |
| Database for small deployments | SQLite only on directly attached local SSD/NVMe | Open WebUI says SQLite is appropriate only for single-user or very small deployments and should not live on NFS, SMB or other network filesystems. |
| Database for multi-user scale | PostgreSQL required for multi-user/high-concurrency deployments | Current performance and scaling guidance treats PostgreSQL as mandatory for high concurrency. Multi-worker or multi-replica deployments also need additional shared infrastructure such as Redis. |
| GPU | Not required for the Open WebUI application | The CUDA image primarily accelerates Open WebUI-side workloads such as embeddings, reranking and Whisper. The chat model's GPU/VRAM requirement belongs to Ollama, vLLM or whichever inference backend actually serves the model. |
When to upgrade your hardware
Upgrade Open WebUI hardware when the application layer itself becomes heavier—especially RAG ingestion, concurrent users or same-machine local inference.
RAG grows from a few files to a real knowledge base
More users become active at the same time
Ollama or another model runtime moves onto the same server
Concurrency shifts the bottleneck toward database writes, connection pools, workers and streaming I/O. Open WebUI's current guidance requires PostgreSQL for multi-user/high-concurrency deployments and warns that local SQLite becomes a bottleneck.
For households, teams or shared AI portals with many simultaneous chats, uploads and RAG requests.This is the largest hardware jump because Open WebUI and the model runtime now compete for CPU, system RAM, storage and potentially VRAM. Model size, quantization, context and concurrency should be calculated independently from Open WebUI's own application footprint.
For users replacing cloud APIs or a remote inference machine with fully local models on the Zima device.Plan hardware growth with confidence
Open WebUI scales most cleanly when the UI/database layer, document pipeline and model inference are treated as separate resources.
Keep model inference remote when the UI host should stay lightweight
Open WebUI can connect to Ollama, OpenAI-compatible APIs and other providers over the network. Offloading inference keeps GPU/VRAM requirements away from the always-on interface server.
Use ZimaBoard 2 as the Open WebUI host and point it at a cloud provider or separate GPU server when large local models exceed the Zima device's inference budget.Move persistent application data to local SSD
Open WebUI's database, chat state, uploaded documents and vector data are sensitive to storage latency. Its current performance guide specifically warns against SQLite on NFS/SMB and recommends directly attached SSD/NVMe for small SQLite deployments.
Use SATA or NVMe SSD for Open WebUI application data instead of placing the database on a network share or relying indefinitely on small onboard eMMC.Externalize embeddings and extraction as document usage grows
The official performance guide recommends an external embedding provider for multi-user setups and an external extractor such as Tika or Docling for regular ingestion. This prevents every Open WebUI worker from carrying its own embedding model and isolates parser memory growth.
Add separate containers or APIs for embeddings and extraction before simply multiplying Open WebUI worker count on the same small host.Move to PostgreSQL before scaling workers
SQLite is suitable for a single user or very small deployment on local SSD. For higher concurrency or multiple workers/replicas, Open WebUI requires PostgreSQL and additional shared infrastructure rather than a larger CPU alone.
Use more RAM, SSD IOPS and database capacity for the multi-user application layer; GPU upgrades do not solve database concurrency.Can it run on ZimaOS?
Open WebUI is currently available in the ZimaOS App Store. ZimaOS can host the interface itself and, depending on the deployment, can also run Ollama locally or connect Open WebUI to another model provider.
Install Open WebUI from the ZimaOS App Store
The current ZimaOS App Store lists Open WebUI in the AI category and shows 512 MB as package minimum memory. Treat that figure as a lightweight application floor rather than the hardware requirement for any local LLM that Open WebUI may use.
Open Open WebUI in the ZimaOS App StoreChoose local or remote model inference deliberately
ZimaOS documentation demonstrates Open WebUI with Ollama-backed local models, while Open WebUI itself can also connect to remote or cloud providers. The model location determines whether GPU, VRAM and large model-storage requirements belong on the Zima host.
Read the ZimaOS Open WebUI local-model workflowPut RAG and database state on appropriate storage
Persist Open WebUI data across container updates and keep SQLite on directly attached local SSD/NVMe for small deployments. If several users or workers are expected, use PostgreSQL rather than placing SQLite on a ZimaOS SMB/NFS share.
Read Open WebUI performance guidanceChoose Zima hardware for your Open WebUI workload
First decide whether Zima runs only Open WebUI or also performs local model inference. For remote/cloud models, Open WebUI is a comparatively light home-server service; RAG, multi-user concurrency and local Ollama are the workloads that justify larger configurations.
Will model inference run on a cloud provider or separate inference server?
Yes — Zima runs Open WebUI, RAG and application state
No local LLM GPU is required. Start with ZimaBoard 2 832 for single-user or light household use and move to 1664 when local embeddings, more documents or other containers need additional RAM.
- Single-user/household UI with cloud or remote modelsZimaBoard 2 832
- More RAG, local embeddings and co-hosted servicesZimaBoard 2 1664
No — local inference or heavier multi-user workloads share the server
Use ZimaCube 2 when Open WebUI becomes part of a larger AI/NAS platform. Standard and Pro add CPU/storage headroom; Creator Pack adds a dedicated NVIDIA GPU, but local model fit still depends on the exact model and current GPU VRAM.
- RAG-heavy UI plus multi-drive datasets and normal servicesZimaCube 2 Standard
- More users, containers, PostgreSQL and heavier CPU-side AI workflowsZimaCube 2 Pro
- Same-machine local LLM inference plus genuine GPU workloadsZimaCube 2 Creator Pack
This is a workload guide, not a guaranteed user-count, document-count or local-model benchmark. Results depend on Open WebUI version, model provider, RAG configuration, embedding engine, extraction engine, database, worker count, 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 or household Open WebUI instance using cloud APIs, remote Ollama or another remote model server. | Chats, persistent history, light RAG, a small document collection and ordinary ZimaOS services without same-machine large-model inference. |
|
The 32 GB eMMC is not an ideal long-term location for a large document corpus, local model library or write-heavy database. Heavy local embeddings, many users or local Ollama models can consume the 8 GB memory budget quickly. | Get Now |
| ZimaBoard 2 1664 | Open WebUI with more local RAG work, embeddings, documents and co-hosted ZimaOS applications. | Larger personal knowledge bases, local SentenceTransformers, several AI clients and other always-on Docker services while inference remains cloud/remote or limited to small CPU models. |
|
Sixteen gigabytes improves application-side headroom but does not turn the N150 into a high-performance local LLM GPU system. Size local model inference separately. | Get Now |
| ZimaCube 2 Standard | Open WebUI combined with a larger private document store, RAG datasets, backups and other home-server workloads. | RAG-heavy personal AI, large local document libraries, multi-drive storage and several ZimaOS applications with cloud or remote model inference. |
|
Standard still has 8 GB system RAM, so it is not automatically a better choice than ZimaBoard 2 1664 for memory-heavy RAG. Choose it primarily for stronger CPU and multi-drive storage topology. | Get Now |
| ZimaCube 2 Pro | A larger Open WebUI deployment with more users, PostgreSQL, document services and many other always-on ZimaOS containers. | Multi-user UI, heavier RAG ingestion, external extraction/embedding services, local datasets, backups and broader home-server workloads. |
|
More CPU and 10GbE do not solve local LLM VRAM requirements. If the model runs locally, size that inference backend independently from Open WebUI. | Get Now |
| ZimaCube 2 Creator Pack | Open WebUI combined with same-machine Ollama/local inference, GPU-accelerated AI services and large local datasets. | Local LLM chat, RAG, embeddings, document workflows and other GPU-accelerated services on one multi-drive ZimaOS server. |
|
Do not choose Creator Pack because Open WebUI itself needs a GPU—it does not. Choose it when the actual local model or another AI workload requires dedicated GPU acceleration, and verify the exact current GPU VRAM before promising model fit. | 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 the Open WebUI application from Ollama/local-model requirements and explain where RAG, databases and concurrency change the hardware decision.
How much RAM does Open WebUI need?
Open WebUI does not publish one official universal RAM minimum. ZimaOS currently lists 512 MB minimum memory for its Open WebUI package, while a 2025 GitHub community measurement reported about 491 MB idle and suggested roughly 1 GB RAM for Open WebUI by itself. Those figures exclude local LLM memory and heavier RAG workloads.
Is 8 GB RAM enough for Open WebUI?
Yes for many personal deployments when model inference is remote or cloud-based. Eight gigabytes also leaves room for light RAG and other small services. Local embeddings use roughly 500 MB per Open WebUI worker, so larger document workflows or several users can justify 16 GB or external embedding services.
Does Open WebUI need a GPU?
No. The standard Open WebUI application can use cloud APIs or a remote Ollama/vLLM server without a local GPU. A GPU matters when the same machine also performs local model inference or when you deliberately use CUDA for Open WebUI-side embeddings, reranking or Whisper.
How much storage does Open WebUI need?
Open WebUI upstream does not publish one universal disk minimum. A GitHub community measurement estimated about 10 GB spare disk for the container and update headroom. Uploaded files, vector data and chat history add more. Ollama model files are separate and can increase the complete AI stack by tens or hundreds of gigabytes.
Can ZimaBoard 2 run Open WebUI?
Yes. ZimaOS currently offers an Open WebUI App Store package, and ZimaBoard 2 832 provides 8 GB RAM and a 4-core Intel N150, which is ample for a normal personal UI connected to cloud or remote models. Add SSD storage as documents, database state or model files grow.
Why can Open WebUI use much more RAM after I enable RAG?
The default local SentenceTransformers embedding model uses roughly 500 MB RAM per worker, and each worker loads its own copy. Open WebUI also documents memory growth from the default pypdf extraction path during repeated document ingestion. External embeddings and Tika/Docling can move these costs out of the main process.
When does Open WebUI need PostgreSQL instead of SQLite?
SQLite is appropriate only for a single user or very small deployment on directly attached local SSD/NVMe. Open WebUI's current performance guidance requires PostgreSQL for multi-user or high-concurrency use and warns not to place SQLite on NFS, SMB or other network filesystems.
When should I choose ZimaCube 2 instead of ZimaBoard 2 for Open WebUI?
Choose ZimaBoard 2 for a personal or household Open WebUI service, especially when inference is remote. Choose ZimaCube 2 when the same system needs large multi-drive RAG datasets, more users, PostgreSQL and additional containers, or same-machine local inference. Creator Pack is justified by the GPU/model workload, not by Open WebUI alone.
What sources and further reading informed this Open WebUI hardware guide?
The official Open WebUI performance guide is the primary source for RAM behavior, embeddings, document extraction and database scaling. GitHub Discussion #736 is community evidence: its older 16 GB/50 GB answer describes an Ollama + Open WebUI stack, while a later measurement estimates about 1 GB RAM, 1 CPU core and 10 GB spare disk for Open WebUI alone. SelfHostSpecs independently confirms that upstream publishes no universal RAM/CPU minimum. Angelo Lima, TauCeti and Effloow describe broader Ollama/local-AI systems, so their 16–64 GB RAM, GPU and large-disk recommendations must not be presented as Open WebUI application requirements.
