Document extraction, embedding and vector indexing run through Dify workers and storage services. A 2026 third-party deployment guide measured about 2.5 GB idle for its stack and roughly 4–6 GB during active RAG indexing, showing why the official 4-GiB minimum leaves little headroom for knowledge-heavy use.
For users building recurring PDF/document ingestion, larger knowledge bases and RAG-heavy workflows.Dify Hardware Requirements: CPU, RAM, Storage & Local AI
Learn Dify hardware requirements for CPU, RAM, storage, RAG, Ollama, local models, Docker Compose and ZimaOS hardware choices.
Dify hardware requirements at a glance
Separate the Dify application stack from model inference. Dify Community Edition runs the web/API, workers, database, cache, vector/RAG and sandbox services; the LLM can run through a cloud provider, a remote inference server or locally on the same machine.
- CPU
- Current Dify Community Edition officially requires at least 2 CPU cores. More cores become useful when document indexing, workflows, plugins, code execution, concurrent users and background workers run at the same time.
- RAM
- Current Community Edition officially requires at least 4 GiB RAM. That is a startup floor for the Dify stack, not a production or same-machine local-LLM target. Third-party 2026 guides commonly move practical self-hosting toward 8 GB or more.
- Storage
- The current Community Edition README does not publish one universal disk minimum. Plan SSD space for Docker images, PostgreSQL, Redis, vector/RAG data, uploaded files, plugin/sandbox state and logs. Third-party self-hosting guides commonly use about 20 GB free as a practical floor.
- RAG and database
- Dify is not a single container. RAG ingestion and workflow execution create worker, database, cache and vector-store activity. Large knowledge bases and concurrent indexing can justify more RAM, CPU and SSD IOPS than a simple chat workflow.
- GPU and local models
- Dify itself does not require a GPU when it calls OpenAI, Anthropic, DeepSeek, hosted MaaS or a remote Ollama/vLLM endpoint. GPU and model-memory requirements belong to the local inference backend and must be added separately.
- Best Zima starting point
- ZimaBoard 2 832 exceeds Dify Community Edition's official 2-core/4-GiB minimum and is a practical cloud/remote-model starting point. Choose 1664 for RAG, more workers and co-hosted services; choose ZimaCube 2 when larger datasets, multi-user load, storage growth or same-machine local AI justify it.
From official requirements to the right setup
Dify sizing starts with Community versus Enterprise and remote versus local inference, then adds RAG ingestion, workers, database/cache load, concurrency and persistent storage.
-
Official requirements
Choose the deployment edition first. Current Dify Community Edition has an official minimum of 2 CPU cores and 4 GiB RAM, while Enterprise Docker Compose and Enterprise Kubernetes publish much larger requirements and should not be used as Community Edition minimums.
-
Confirm your needs
Decide where the model runs. Hosted providers and remote inference keep the Dify host focused on orchestration, RAG, workers and state. Same-machine Ollama or another local LLM adds its own model RAM/VRAM, context and storage requirements on top.
-
Leave room to grow
Estimate Dify-side workload multipliers: document ingestion, embeddings, vector indexing, multiple workers, plugins, code/agent sandbox execution and concurrent workflows can push real usage well above the official 4-GiB floor.
-
Run it on ZimaOS
Deploy Dify, connect a representative model provider, ingest a real knowledge base and run representative workflows while monitoring container RAM, CPU, PostgreSQL/vector-store I/O, worker queues and model-server latency before increasing concurrency.
Check every playback client
- Community Edition or Dify Enterprise
- Cloud/remote model provider or same-machine local inference
- Number of simultaneous users and workflow executions
- Knowledge-base size and document-ingestion frequency
- Embedding and vector-database workload
- Plugin, code execution and agent-sandbox usage
- PostgreSQL/vector data, uploads and log growth
- Other ZimaOS containers, NAS, VMs and AI services
Official minimum requirements
Dify publishes different hardware requirements for different editions. The open-source Community Edition README gives a small self-hosting minimum, while Enterprise Docker Compose and Enterprise Kubernetes publish separate production-oriented resource requirements.
For this home-server hardware page, use 2 CPU cores and 4 GiB RAM as the current official Community Edition minimum. Treat 4 cores/16 GB/100 GB as Enterprise Docker Compose requirements and the larger Kubernetes resource matrix as Enterprise deployment guidance, not as Dify Community minimums.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Community Edition CPU | At least 2 CPU cores | This is the current minimum published in the official langgenius/dify repository for the Docker Compose quick-start path. |
| Community Edition RAM | At least 4 GiB | This is an official minimum for the Community Edition host. It does not include the memory required by a same-machine local LLM such as Ollama. |
| Docker Compose | Docker + Docker Compose v2.24.0 or later | The current Community Edition quick start uses Docker Compose. Older third-party guides can list earlier Docker/Compose versions. |
| Community Edition disk | No universal official capacity published in the current README | Docker images, PostgreSQL, Redis, vector data, uploads, plugin/sandbox state and logs all consume persistent storage. Third-party guides commonly use about 20 GB as a practical starting point. |
| Enterprise Docker Compose | 4 CPU cores, 16 GB memory, 100 GB disk minimum | This requirement belongs to Dify Enterprise Docker Compose, not Community Edition. |
| Enterprise Kubernetes test environment | 1 worker node: 4 cores/16 GB, plus separate PostgreSQL, Redis, vector DB and storage | Dify Enterprise 3.12.x separately specifies PostgreSQL at 2 cores/4 GB/256 GB, Redis at 1 GB, Qdrant at 4 cores/8 GB/100 GB and 100 GB persistent object storage for its cluster test environment. |
When to upgrade your hardware
Upgrade Dify hardware when orchestration, RAG or concurrency becomes the bottleneck. Model inference and Dify-side resource pressure should be diagnosed separately.
RAG ingestion regularly pushes memory and workers
More users and workflows execute concurrently
Ollama or another LLM moves onto the same machine
Simultaneous API requests, worker tasks, plugin calls and database/vector-store operations increase CPU, RAM and queue pressure. Move beyond the 2-core/4-GiB floor when latency rises or workers compete with database and other services.
For shared household/team portals, multiple agents and always-on automation workloads.This creates a second hardware budget. Dify's own DeepSeek deployment guide recommends at least 16 GiB GPU/RAM for its combined Dify + Ollama + local DeepSeek workflow, but that figure describes the complete local-AI setup rather than Dify Community Edition alone.
For users replacing hosted model APIs with same-server Ollama, vLLM or another local model runtime.Plan hardware growth with confidence
Dify scales most cleanly when orchestration, persistent data, RAG storage and model inference are treated as separate resources.
Put Dify state on SSD or NVMe
PostgreSQL, vector data, uploaded files, plugin state and worker activity create many small reads and writes. Responsive local storage helps the application layer even when large source documents live on capacity HDDs.
Use SATA or NVMe SSD for the active Dify stack and database/vector state; use larger HDD pools for source archives and backups when needed.Keep local model inference separate when possible
Dify is model-agnostic and can connect to hosted or remote model endpoints. A separate Ollama or GPU server prevents model RAM/VRAM pressure from competing with Dify workers, PostgreSQL and RAG ingestion.
Use ZimaBoard 2 or ZimaCube 2 as the always-on Dify platform and point it at another GPU machine when the desired local model exceeds the host's memory or GPU budget.Add memory before scaling RAG and worker concurrency
The official 4-GiB floor is suitable for getting Community Edition running, but database, vector-store and worker processes all share the same host in a compact Docker Compose deployment.
Move to 16 GB when several Dify services, RAG indexing and other ZimaOS apps routinely overlap rather than relying on swap.Separate application data from long-term knowledge archives
Dify needs fast application/database/vector state, while source documents, exported datasets and backups can grow independently. Treat these as separate storage tiers so dataset growth does not crowd the system volume.
Use ZimaCube 2 when integrated multi-drive storage and backup retention become larger requirements than the Dify application itself.Can it run on ZimaOS?
Dify is currently listed in the ZimaOS App Store as an AI application. The current App Store changelog references Dify 0.15.8 images, so verify the exact installed package version before assuming parity with the newest upstream Community Edition.
Install Dify from the ZimaOS App Store
ZimaOS currently lists Dify in its App Store. This is the simplest home-server deployment path, but the App Store package should be treated as its own packaged version and checked before relying on current upstream features or migration instructions.
Open Dify in the ZimaOS App StoreUse hosted or remote models to keep the Zima host lighter
Dify supports many commercial and self-hosted model providers. When inference happens remotely, Zima hardware primarily carries the Dify stack, RAG, data and worker workloads rather than LLM weights and VRAM.
Read the Dify Community Edition repositoryTreat Ollama as a separate resource layer
Dify's own DeepSeek tutorial runs Ollama as the local model server and connects Dify to it over the network. If both run on ZimaOS, add Ollama's model RAM/VRAM and model-storage requirements on top of the Dify application stack.
Read Dify's local DeepSeek deployment guideChoose Zima hardware for your Dify workload
The first decision is whether the Zima device runs only Dify's application/RAG stack or also runs local model inference. For remote models, Dify is mainly a CPU/RAM/database workload; same-machine LLMs can make GPU or system memory the dominant constraint.
Will model inference run on a cloud provider or separate inference server?
Yes — Zima runs Dify, RAG, database and workers
ZimaBoard 2 832 exceeds the official Community Edition minimum and is suitable for personal/light deployments. Move to 1664 when RAG, workers, plugins and other containers need more memory headroom.
- Personal Dify with cloud/remote models and light RAGZimaBoard 2 832
- More RAG, workers, plugins and co-hosted applicationsZimaBoard 2 1664
No — local AI or larger shared workloads run on the same server
Use ZimaCube 2 when Dify becomes part of a broader AI/NAS system. Standard and Pro add CPU/storage headroom; Creator Pack adds a dedicated NVIDIA GPU path, but the exact local model still has to be sized independently.
- RAG datasets plus integrated multi-drive storageZimaCube 2 Standard
- Higher worker/user concurrency and broader AI servicesZimaCube 2 Pro
- Same-machine local LLM inference plus GPU workloadsZimaCube 2 Creator Pack
This is a workload guide, not a guaranteed user-count, workflow-throughput or RAG-ingestion benchmark. Results depend on Dify version, worker settings, plugins, knowledge-base size, vector database, model provider, local LLM size/context, storage latency and other ZimaOS services.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | A personal or family Dify Community Edition deployment using hosted or remote models. | Visual workflows, API apps, light RAG, plugins and small knowledge bases with modest concurrency. |
|
The 32 GB eMMC is small for a growing Dify stack with RAG data and Docker images. Eight GB can also become tight when active RAG indexing, many workers and other ZimaOS applications overlap. | Get Now |
| ZimaBoard 2 1664 | A Dify home server with more RAG, plugins, workers and co-hosted services while model inference remains remote or modest. | Larger personal knowledge bases, several workflows, background indexing, multiple AI clients and other always-on containers. |
|
Sixteen GB improves Dify-side concurrency but does not turn the N150 into a high-performance local LLM platform. Size Ollama or another same-machine model separately. | Get Now |
| ZimaCube 2 Standard | Dify combined with a larger local knowledge archive, backups and integrated multi-drive storage. | RAG-heavy personal AI, document archives, Dify workflows and several ZimaOS services with remote/cloud inference. |
|
Standard still has 8 GB RAM, so it is not automatically better than ZimaBoard 2 1664 for memory-heavy RAG. Choose it mainly for stronger CPU and integrated multi-drive storage. | Get Now |
| ZimaCube 2 Pro | A heavier Dify deployment with more workers, users, RAG ingestion and other always-on ZimaOS services. | Shared workflows, larger knowledge bases, indexing, plugins, local data services, backups and higher local network throughput. |
|
More CPU and 10GbE do not replace GPU VRAM for same-machine local models. Local inference must be sized independently from Dify. | Get Now |
| ZimaCube 2 Creator Pack | Dify combined with same-machine local LLM inference, GPU AI services and large local datasets. | Dify RAG/workflows plus Ollama or another compatible NVIDIA-accelerated inference backend on one multi-drive server. |
|
Do not choose Creator Pack because Dify itself requires a GPU—it does not. Choose it only when the local model or another AI workload genuinely needs 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 Dify Community Edition, Dify Enterprise and local-model hardware so edition-specific numbers are not mixed together.
How much RAM does Dify need?
Current Dify Community Edition officially requires at least 4 GiB RAM. That is a minimum host requirement, not a production recommendation. RAG, worker concurrency, plugins and other Docker services can justify 8 GB or 16 GB, while a same-machine local LLM needs its own additional memory budget.
Is 8 GB RAM enough for Dify?
Yes for many personal Community Edition deployments using hosted or remote models. Eight GB is double the current official minimum and leaves some headroom for RAG and background workers. Heavy indexing, many workflows, multi-user use or co-hosted apps can justify 16 GB.
Does Dify need a GPU?
No. Dify can call OpenAI, Anthropic, DeepSeek, other hosted providers or a remote self-hosted model server. A GPU is only required when the same machine also runs a model backend or another GPU-accelerated workload.
How much storage does Dify need?
The current Community Edition README does not publish one universal disk minimum. Third-party self-hosting guides commonly use about 20 GB free as a practical starting point. Real capacity grows with Docker images, PostgreSQL, vector/RAG data, uploads, plugins, logs and any local model files.
Can ZimaBoard 2 run Dify?
Yes. ZimaBoard 2 has a 4-core Intel N150 and 8 GB or 16 GB RAM, exceeding the current Community Edition minimum of 2 cores and 4 GiB. Add SSD storage for a growing Dify database, vector data and uploads.
How much RAM do Dify and Ollama need together?
There is no single number because the Ollama model determines most of the extra memory. Dify's own DeepSeek tutorial recommends at least 16 GiB GPU/RAM for its combined Dify + Ollama + DeepSeek R1 setup and starts with a 7B model. Treat that as a workload-specific combined recommendation, not Dify's standalone minimum.
Why does Dify Enterprise require much more hardware?
Enterprise targets high availability, multi-tenancy and larger production deployments. Its Docker Compose release requires at least 4 cores, 16 GB RAM and 100 GB disk, while the 3.12.x Kubernetes checklist separates worker nodes, PostgreSQL, Redis, Qdrant and object storage. These requirements must not be applied to a small Community Edition home server.
When should I choose ZimaCube 2 instead of ZimaBoard 2 for Dify?
Choose ZimaBoard 2 for personal/light Dify with remote models. Choose ZimaCube 2 when the same server also needs large RAG datasets, multi-drive document storage, heavier concurrency or same-machine local AI. Creator Pack is justified by the model/GPU workload, not by Dify itself.
What sources and further reading informed this Dify hardware guide?
The official langgenius/dify repository is the primary Community Edition source and currently specifies 2 CPU cores and 4 GiB RAM minimum. Dify Enterprise 3.12.x and the Enterprise Docker Compose site describe different enterprise deployment tiers and should not define Community Edition minimums. Dify's DeepSeek article is an official combined Dify + Ollama + DeepSeek workflow whose 16-GiB recommendation includes local inference. The Dify-AI Hugging Face organization repeats the older 2-core/4-GB Community baseline and explains model neutrality, but the canonical GitHub repository takes precedence. Local AI Master and RamNode provide practical 2026 self-hosting estimates; Linux Server Admin is retained as deployment-oriented further reading, not as the authority for the hardware baseline.
