Document loaders, text splitting, embeddings and vector-store writes add CPU, memory and storage I/O beyond the visual editor itself. Tencent Cloud's practical guide also warns that in-memory vector data and UI-only uploads are not suitable persistence patterns for production.
For users moving from simple chatflows to document Q&A, persistent vector stores and recurring ingestion.Flowise Hardware Requirements: CPU, RAM, Storage & Local AI
Learn Flowise hardware requirements for RAM, CPU, storage, queue mode, PostgreSQL, RAG, Ollama and ZimaOS hardware.
Flowise hardware requirements at a glance
Flowise itself is a Node.js orchestration platform, not the LLM runtime. A small self-hosted instance can stay modest when models and embeddings are remote; production queue mode, RAG, concurrent agents and same-machine local inference create separate resource requirements.
- CPU
- Flowise does not currently publish one universal CPU minimum for a single self-hosted instance. Tencent Cloud demonstrates a lightweight single-server deployment, while official production guidance starts each main server and worker at 4 vCPU.
- RAM
- There is no official single-node minimum RAM figure. Tencent Cloud reports that a 2 GB RAM server can handle Flowise itself for a basic deployment. Official production guidance instead starts each main server and each worker at 8 GB RAM.
- Storage
- Flowise publishes no universal storage minimum. Plan persistent SSD capacity for SQLite or PostgreSQL, credentials, logs, uploaded files, vector-store data, caches and workflow state; local model files belong to the inference backend and can be much larger.
- Production mode
- Current Flowise production guidance recommends Queue mode with 2 main servers at 4 vCPU/8 GB each and 4 workers at 4 vCPU/8 GB each, then autoscaling according to traffic and workload volume.
- GPU and local models
- A GPU is not required for Flowise when it calls OpenAI, Anthropic, Cerebras or another remote provider. Ollama or another same-machine inference backend adds its own RAM, VRAM, context and model-storage requirements.
- Best Zima starting point
- ZimaBoard 2 832 is a practical personal Flowise host with cloud or remote models. Choose 1664 for heavier RAG and more concurrent flows, and ZimaCube 2 Pro for larger data, more services and production-like workloads. Creator Pack is only justified when local GPU inference is also part of the system.
From official requirements to the right setup
Flowise sizing starts with personal single-node versus production queue mode, then separates application resources from model inference, RAG data and concurrency.
-
Official requirements
Decide whether this is a personal/self-hosted Flowise instance or a production deployment. Current official docs do not give one single-node CPU/RAM minimum, while production guidance explicitly starts multiple 4-vCPU/8-GB main and worker instances.
-
Confirm your needs
Decide where the model and embeddings run. Remote providers such as Cerebras, OpenAI or Anthropic keep the Flowise host focused on orchestration. Same-machine Ollama adds model weights, context/KV cache, RAM/VRAM and model-storage requirements.
-
Leave room to grow
Add workload multipliers from RAG ingestion, file parsing, agents, tools, custom JavaScript/Python nodes, vector stores and concurrent API calls. These can push a small 2-GB-style test deployment well beyond its initial footprint.
-
Run it on ZimaOS
Install Flowise from ZimaOS, build a representative flow and monitor container RAM, CPU, database I/O, uploaded-file/vector storage and execution latency before increasing concurrency or moving local models onto the same device.
Check every playback client
- Single-node personal use or production queue mode
- Cloud/remote model provider or same-machine local inference
- Number of simultaneous chatflows, agentflows and API calls
- RAG document count and ingestion frequency
- SQLite or PostgreSQL deployment
- Redis/queue workers for production scaling
- Persistent files, vector data, logs and database growth
- Other ZimaOS containers, NAS and AI services
Official minimum requirements
Flowise's current official documentation is stronger on production architecture than on single-node minimums. It does not publish one universal CPU/RAM/disk minimum for a personal Docker instance, but it does publish starting resources for queue-mode production.
Do not label 2 GB RAM as an official Flowise minimum: it is a Tencent Cloud single-server observation. For official production planning, use the documented 4-vCPU/8-GB starting point per main server and per worker, plus PostgreSQL and queue infrastructure.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Single-node CPU/RAM minimum | No universal official figure published | Flowise official docs provide installation and deployment paths but do not currently define one minimum CPU/RAM specification for every personal self-hosted instance. |
| Production main servers | 2 servers, each starting at 4 vCPU / 8 GB RAM | Current production guidance recommends load balancing across two main servers. |
| Production workers | 4 workers, each starting at 4 vCPU / 8 GB RAM | Workers execute jobs in Queue mode and can be scaled according to traffic and workload volume. |
| Production execution mode | Queue mode recommended | In Queue mode the main server receives requests and sends jobs to the queue, while one or more workers execute them. This allows independent worker scaling. |
| Database | SQLite by default; PostgreSQL recommended at scale | Official production guidance recommends moving to PostgreSQL rather than relying on the default SQLite database for scaled deployments. |
| GPU | Not required by Flowise itself | Flowise can connect to remote LLM providers such as Cerebras. GPU and VRAM requirements belong to a local model runtime if one is deployed. |
When to upgrade your hardware
Upgrade Flowise hardware when flow execution, RAG or concurrency becomes the bottleneck. Model inference should be diagnosed as a separate resource layer.
RAG and file-processing flows become regular workloads
Concurrent agents and API calls outgrow the main thread
Ollama or another local model moves onto the same server
Flowise runs in the Node.js main thread by default. Official docs recommend Queue mode for production so main servers can dispatch jobs to multiple workers and scale independently.
For shared household/team AI services, public APIs, agent automation and multiple simultaneous workflows.This is the largest hardware change. Flowise itself can stay lightweight with remote inference, but local models consume their own RAM or GPU VRAM. Tencent Cloud's model-size examples are rough local-LLM planning figures, not Flowise hardware requirements.
For users replacing Cerebras, OpenAI, Anthropic or another remote provider with same-machine local inference.Plan hardware growth with confidence
Flowise scales most cleanly when application/database state, RAG storage, queue workers and model inference are treated as separate resource layers.
Move persistent Flowise data to SSD
Database files, uploaded documents, vector-store data, credentials and logs are persistent application state. Fast local storage improves responsiveness and avoids filling a small system volume.
Use SATA or NVMe SSD for Flowise persistent data rather than relying indefinitely on onboard eMMC.Move from SQLite to PostgreSQL as concurrency grows
Flowise uses SQLite by default, but current official production guidance recommends PostgreSQL at scale. Database I/O and connections become an application bottleneck that GPU upgrades do not solve.
Reserve additional RAM, SSD IOPS and backup capacity for PostgreSQL when Flowise becomes a shared or always-on service.Adopt Queue mode before treating one large server as the only scale path
Official Flowise production architecture separates main servers from workers using a queue, allowing workers to scale independently. This is a different topology from simply adding CPU cores to a single container.
For true production traffic, consider multiple hosts or VMs rather than assuming one Zima box reproduces the documented multi-node production layout.Keep model inference remote when possible
Cerebras' official Flowise integration demonstrates that Flowise can use an external inference API with no local model GPU requirement. This keeps the self-hosted orchestration layer substantially lighter.
Use ZimaBoard 2 or ZimaCube 2 for Flowise and RAG, and point it at cloud or separate GPU inference when the desired local model exceeds the host's compute budget.Can it run on ZimaOS?
Flowise is currently listed in the ZimaOS App Store. ZimaOS can host the visual builder, API and persistent workflow state while model inference remains remote or runs in another local service.
Install Flowise from the ZimaOS App Store
ZimaOS currently lists Flowise in the AI category as an open-source platform for building AI agents and LLM workflows. Use the packaged app for the orchestration layer and keep its persistent data on appropriate storage.
Open Flowise in the ZimaOS App StoreUse remote models to keep the Zima host modest
Flowise can call external inference providers such as Cerebras without a local GPU. In this architecture, Zima hardware mainly handles Node.js orchestration, database state, RAG data and workflow execution.
Read the Cerebras Flowise integrationTreat production Queue mode as a separate architecture
Official Flowise production guidance uses multiple main servers, multiple workers and PostgreSQL. A single ZimaOS container is appropriate for personal and smaller shared deployments but should not be described as equivalent to that documented production topology.
Read Flowise production guidanceChoose Zima hardware for your Flowise workload
For remote/cloud models, Flowise is primarily a CPU, memory, database and storage workload. Larger Zima hardware becomes useful when RAG data, concurrent agents, co-hosted services or same-machine local inference grow beyond a personal setup.
Will Flowise use cloud or remote model inference for its primary LLM workloads?
Yes โ Zima runs Flowise, RAG and application state
ZimaBoard 2 832 is a sensible personal starting point and provides much more RAM than Tencent Cloud's 2-GB single-server example. Move to 1664 when larger RAG, more concurrent flows or other containers need additional memory.
- Personal Flowise, remote models and light RAGZimaBoard 2 832
- More RAG, agents and co-hosted servicesZimaBoard 2 1664
No โ heavier shared workloads or local AI share the server
Use ZimaCube 2 when Flowise becomes part of a broader AI/NAS platform. Pro adds CPU/RAM/network headroom, while Creator Pack only makes sense when a dedicated local GPU workload is also required. None of these single-box configurations should be presented as equivalent to Flowise's multi-node production queue architecture.
- Large RAG/document storage with moderate application loadZimaCube 2 Standard
- More agents, PostgreSQL and heavier application concurrencyZimaCube 2 Pro
- Same-machine local LLM plus dedicated GPU workloadsZimaCube 2 Creator Pack
This is a workload guide, not a guaranteed user-count, flow-throughput or production benchmark. Results depend on Flowise version, node types, agent complexity, RAG ingestion, database choice, queue mode, local model size/context and other ZimaOS workloads.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Personal Flowise deployments using cloud or remote models with light RAG and modest concurrency. | Chatflows, Agentflows, API calls, small document Q&A projects and ordinary ZimaOS containers. |
|
32 GB eMMC is small for long-term RAG data and multiple containers. Heavy concurrency or same-machine local LLMs should be sized separately. | Get Now |
| ZimaBoard 2 1664 | Flowise with larger RAG, more agents and additional ZimaOS services while models remain remote. | Multiple workflows, persistent vector stores, PostgreSQL/Redis experiments and other always-on home-server containers. |
|
Extra RAM does not increase CPU capability or provide high-end local LLM acceleration. It is an application/RAG headroom upgrade, not a production-queue replacement. | Get Now |
| ZimaCube 2 Standard | Flowise combined with larger document libraries, backups and integrated multi-drive storage while inference stays remote. | RAG-heavy personal AI, document archives, workflow services and multiple ZimaOS applications. |
|
Standard still has 8 GB RAM, so ZimaBoard 2 1664 can be a better choice when memory-heavy concurrency is the main bottleneck. Choose Standard primarily for CPU and storage topology. | Get Now |
| ZimaCube 2 Pro | A heavier single-box Flowise deployment with more agents, PostgreSQL, RAG services and high-speed document storage. | Shared workflows, persistent vector databases, more concurrent API calls, document processing, backups and other always-on services. |
|
A single Pro does not reproduce the official production recommendation of two 4-vCPU/8-GB main servers plus four 4-vCPU/8-GB workers. Treat it as a strong home/small shared server, not an equivalent production cluster. | Get Now |
| ZimaCube 2 Creator Pack | Flowise combined with same-machine local LLM inference, GPU AI services and large private data storage. | Flowise RAG/agents plus Ollama or another compatible NVIDIA inference backend, local AI tools and multi-drive datasets. |
|
Usually unnecessary for Flowise alone. Choose Creator Pack only when the local model or another GPU workload independently justifies dedicated acceleration, and do not promise a model size without verified VRAM. | 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 Flowise's official production guidance from single-server third-party examples and local-model hardware.
How much RAM does Flowise need?
Flowise does not currently publish one universal minimum RAM figure for a single self-hosted instance. Tencent Cloud reports that a 2 GB RAM server can handle Flowise itself in a basic deployment, but that is a practical third-party observation. Official production guidance starts every main server and worker at 8 GB RAM.
Is 8 GB RAM enough for Flowise?
Yes for many personal or household Flowise deployments using remote model APIs. Eight GB leaves substantially more headroom than Tencent Cloud's 2-GB single-server example. Larger RAG ingestion, multiple agents, PostgreSQL/Redis and other ZimaOS services can justify 16 GB or more.
Does Flowise need a GPU?
No. Cerebras' official integration demonstrates a Flowise setup where inference is handled entirely by the external Cerebras API. The same principle applies to other cloud or remote providers. GPU and VRAM only become a host requirement when a local model backend also runs on that machine.
How much storage does Flowise need?
Flowise does not publish one universal disk minimum. Persistent capacity grows with the SQLite/PostgreSQL database, logs, uploaded files, credentials and vector-store data. If Ollama or another local model runs on the same host, model files should be budgeted separately.
Can ZimaBoard 2 run Flowise?
Yes. ZimaBoard 2 provides a four-core Intel N150 and either 8 GB or 16 GB RAM. The 832 is a sensible personal Flowise host with remote models; add SSD storage for persistent RAG data and move to the 1664 when more concurrent application workloads need memory.
What hardware does Flowise recommend for production?
Current official guidance recommends Queue mode with two load-balanced main servers, each starting from 4 vCPU and 8 GB RAM, plus four workers, each also starting from 4 vCPU and 8 GB RAM. PostgreSQL is recommended at scale, and workers can autoscale with traffic.
Why does one GitHub setup say Flowise needs 16 GB RAM?
The supplied GitHub repository is not a Flowise-only upstream project. It packages Dify and Flowise together on Windows and specifies an Intel Core i5, 16 GB RAM and 20 GB SSD for that combined platform. Those figures should not be presented as Flowise's standalone minimum.
When should I choose ZimaCube 2 instead of ZimaBoard 2 for Flowise?
Choose ZimaBoard 2 for personal Flowise, light RAG and remote models. Choose ZimaCube 2 when the same server also needs larger document stores, stronger CPU, PostgreSQL/shared services or local AI. Creator Pack is justified by the local GPU workload, not Flowise itself.
What sources and further reading informed this Flowise hardware guide?
The official Flowise production guide is the primary source for queue-mode architecture: two 4-vCPU/8-GB main servers and four 4-vCPU/8-GB workers, with PostgreSQL recommended at scale. The supplied GitHub project is a third-party combined Dify + Flowise Windows package and its i5/16-GB/20-GB requirements must not be used as Flowise-only minimums. Tencent Cloud documents a practical 2-GB single-server Flowise deployment and suggests 4 GB when combining it with a small local Ollama model; its local-model RAM examples are implementation guidance rather than Flowise requirements. Cerebras' official integration confirms that Flowise can use remote inference and therefore does not inherently need a local GPU.
