n8n's official prerequisites explain that most nodes pass data onward, while the Code node can create pre/post-processing copies. Large binary or structured payloads can therefore consume much more memory than a simple webhook/API workflow.
For document, media, scraping, transformation and data-heavy automations.Requisitos de hardware de n8n: RAM, CPU, almacenamiento y escala de los flujos de trabajo
Conoce los requisitos de hardware de n8n para RAM, CPU, almacenamiento, SQLite, PostgreSQL, el modo de cola, los flujos de trabajo de IA y el hardware de ZimaOS.
n8n hardware requirements at a glance
n8n is usually light at idle, but workflow design and execution data can change memory use dramatically. Current official OEM/Embed prerequisites provide illustrative cloud sizing rather than one universal self-hosted minimum.
- CPU
- n8n's current official prerequisites say the application is not especially CPU intensive and that small cloud instances can handle many use cases. There is no universal Community Edition CPU-core minimum that applies to every self-hosted workflow.
- RAM
- The current official OEM/Embed prerequisites show 320 MB–2 GB as an illustrative memory range and note that an idle n8n Cloud instance uses roughly 100 MB. Actual memory depends on workflow structure and the data processed, especially large binary payloads and nodes that copy data.
- Storage
- The same OEM/Embed example shows 512 MB–4 GB SSD for the database layer, not total long-term server capacity. Persistent workflow history, credentials, logs, binary data, PostgreSQL and backups can require much more over time.
- Database
- n8n uses SQLite by default and also supports PostgreSQL. SQLite is suitable for a simple single-instance start; PostgreSQL becomes the more appropriate path for larger or scaled deployments.
- AI and GPU
- n8n itself does not require a GPU to call OpenAI, Claude, Gemini, DeepSeek or other remote APIs. GPU/VRAM only becomes a host requirement if the same machine also runs a local model backend such as Ollama.
- Best Zima starting point
- ZimaBoard 2 832 is already a strong personal/self-hosted n8n starting point with 8 GB RAM. Choose 1664 when many workflows, PostgreSQL and other containers share the host. ZimaCube 2 is justified by broader storage, high-concurrency or local-AI workloads rather than n8n alone.
From official requirements to the right setup
n8n sizing starts with workflow type and execution frequency, then checks data volume, concurrency, database growth, AI backend location and the other services sharing the ZimaOS host.
-
Official requirements
Classify the workflows first: lightweight API/webhook automations use far less memory than image, document, binary-file, scraping or large Code-node workflows. Do not size n8n from workflow count alone.
-
Confirm your needs
Estimate concurrent executions and trigger frequency. n8n can scale with workers and queue mode, but concurrency increases working memory, database activity and external-service load.
-
Leave room to grow
Plan persistent SSD capacity for the database, execution history, credentials, logs, binary data and backups. Default SQLite is simple for a single instance; larger deployments should evaluate PostgreSQL.
-
Run it on ZimaOS
Separate n8n orchestration from local model inference. If AI nodes call remote APIs, n8n remains an ordinary automation workload. If Ollama or another model runtime runs locally, size that model's RAM/VRAM and storage independently.
Check every playback client
- Number of active workflows and execution frequency
- Peak concurrent workflow executions
- Large JSON, image, audio or other binary payloads
- Code-node and data-copying workflow behavior
- SQLite versus PostgreSQL database
- Execution-history retention and pruning policy
- Remote AI APIs versus same-machine local models
- Other ZimaOS containers, databases and home-server workloads
Official minimum requirements
The supplied official n8n prerequisites page is specifically for OEM/Embed deployment planning and states that its resource examples are based on n8n Cloud and are illustrative. They should not be presented as one universal Community Edition self-hosted minimum.
Use the official 320 MB–2 GB memory and 512 MB–4 GB SSD database figures as evidence that n8n itself can be lightweight, not as a guaranteed production specification. Real ZimaOS sizing should follow workflow data volume, concurrency, database growth and co-hosted services.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Memory example | 320 MB–2 GB | This is the current official OEM/Embed illustrative range, based on n8n Cloud examples. It is not a universal minimum/recommended pair for all self-hosted Community Edition deployments. |
| Idle memory example | About 100 MB for an idle n8n Cloud instance | The same official page says actual memory is determined by workflow nature and the amount of data processed. |
| Database storage example | 512 MB–4 GB SSD | This refers to the database sizing example in the OEM/Embed prerequisites, not total long-term storage for execution history, binary data and backups. |
| CPU | No universal core-count minimum on this page | n8n says it is not CPU intensive and that small AWS/GCP-style instances are sufficient for many use cases, while memory is often the more important resource. |
| Database engines | SQLite or PostgreSQL | n8n uses SQLite by default and also supports PostgreSQL; larger and scaled deployments should evaluate PostgreSQL. |
| Storage best practice | SSD and persistent volumes | The official prerequisites recommend SSD storage and persistent mounted volumes so container restarts do not lose database data. |
When to upgrade your hardware
Upgrade n8n hardware when monitoring shows sustained memory pressure, execution backlog or database/storage growth. Workflow shape matters more than a generic workflow-count threshold.
Large payloads or Code nodes create memory spikes
Concurrent executions approach the current host's limits
Execution history and database data grow continuously
More simultaneous workflows increase working memory and database activity. When execution latency or memory pressure grows under concurrency, add RAM, control concurrency or move toward worker/queue-mode architecture.
For higher-frequency webhooks, scheduled automations and multi-user self-hosted n8n.n8n stores credentials, workflows and past executions in its database. Long retention, frequent executions and binary data can make storage/database growth the limiting resource before CPU.
For long-running production-like deployments with frequent workflow executions.Plan hardware growth with confidence
n8n scales best when execution memory, persistent database storage and optional AI inference are treated as separate resource layers.
Move n8n data to SSD and keep it persistent
The official prerequisites recommend SSD storage and persistent container volumes. This protects workflows, credentials and database state across restarts and improves database responsiveness.
Use SATA or NVMe SSD for permanent n8n application/database data instead of relying only on small onboard eMMC.Use PostgreSQL as the deployment grows
SQLite is the default and works well for simple single-instance setups. n8n also supports PostgreSQL, and multi-main queue-mode scaling requires Postgres plus Redis.
Reserve additional SSD, RAM and backup capacity for PostgreSQL when n8n becomes a larger shared service.Control concurrency before assuming more CPU is required
Current n8n scaling documentation supports concurrency controls and worker execution. This can keep bursts from exhausting memory and lets scaled deployments add workers deliberately.
Measure per-execution memory and backlog before moving to a larger CPU tier.Separate local AI inference from n8n orchestration
Remote LLM APIs do not require local GPU hardware. If local Ollama or another inference runtime is added, its model weights, context and VRAM requirements should be sized separately.
Keep n8n on ZimaBoard 2 or ZimaCube 2 and use a separate GPU server when the desired local model exceeds the host's practical resources.Can it run on ZimaOS?
n8n is currently listed in the ZimaOS App Store. ZimaOS provides the packaged deployment path, while current n8n documentation remains the authority for database, scaling and resource behavior.
Install n8n from the ZimaOS App Store
ZimaOS currently lists n8n as a workflow automation and conversational-AI platform. The current App Store page does not expose a separate universal CPU/RAM hardware minimum.
Open n8n in the ZimaOS App StoreKeep n8n data on persistent SSD storage
n8n's database stores workflows, credentials and execution history. Persistent SSD-backed app data is a better long-term layout than treating container-local ephemeral storage as permanent.
Read n8n database guidanceTreat queue mode as a scaled architecture, not a bigger single container
Current n8n docs scale executions through workers and queue mode; multi-main setups require Postgres and Redis. A larger Zima host can run more components, but it is not automatically equivalent to a distributed worker deployment.
Read n8n queue-mode guidanceChoose Zima hardware for your n8n workload
n8n is light enough that ZimaBoard 2 832 is a strong personal automation starting point. Larger Zima systems should be selected for more concurrent workflows, databases, many co-hosted services, storage growth or local AI rather than because n8n has a fixed high hardware floor.
Are your workflows mainly lightweight API/webhook automations with remote services, or do they process larger data and share the host with more infrastructure?
Light/personal automation with remote APIs
Start with ZimaBoard 2 832. Its Intel N150 and 8 GB RAM provide substantial headroom compared with n8n's illustrative cloud memory figures. Choose 1664 when PostgreSQL, many containers or more concurrent workflows share the server.
- Personal n8n, webhooks, schedules and remote APIsZimaBoard 2 832
- More workflows, PostgreSQL and larger Docker stackZimaBoard 2 1664
Heavier data workflows, larger shared stack or local AI
Choose ZimaCube 2 from the broader workload. Standard adds integrated storage, Pro adds CPU/RAM/network headroom, and Creator Pack is only justified when a separately sized local GPU model workload requires dedicated acceleration.
- Storage-heavy workflows with moderate application loadZimaCube 2 Standard
- More concurrent services, PostgreSQL and heavier workflowsZimaCube 2 Pro
- Compatible same-machine local GPU inferenceZimaCube 2 Creator Pack
This is a workload guide, not a guaranteed workflow-count or executions-per-second benchmark. Results depend on n8n version, node types, payload size, concurrency, database, execution retention, external API latency and other ZimaOS services.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | The best-value current Zima option for personal n8n, webhooks, schedules, API orchestration and light AI workflows using remote models. | n8n, reverse proxy, lightweight databases and several ordinary ZimaOS containers. |
|
The 32 GB eMMC can become the first long-term constraint once Docker data, execution history and other apps accumulate. Use persistent SSD and monitor memory during data-heavy workflows. | Get Now |
| ZimaBoard 2 1664 | A compact n8n server with more memory for PostgreSQL, higher concurrency and a larger self-hosted application stack. | More active workflows, databases, automation tools, reverse proxy and other always-on Docker services. |
|
Do not claim 16 GB makes individual n8n workflows inherently faster. CPU is unchanged; memory helps when concurrent executions, Postgres or other containers create pressure. | Get Now |
| ZimaCube 2 Standard | Storage-heavy n8n workflows and a broader NAS where automation manages local files, backups or media. | n8n plus large local datasets, file automation, backups and moderate home-server services. |
|
Standard has 8 GB RAM, so it is not automatically a better n8n host than ZimaBoard 2 1664 when memory/concurrency is the main issue. Choose it primarily for storage. | Get Now |
| ZimaCube 2 Pro | A larger all-in-one automation/NAS server running n8n, PostgreSQL and many other services with more concurrency headroom. | Higher-frequency workflows, local databases, file processing, backups, many containers and broader homelab services. |
|
A single Pro box should not be described as equivalent to n8n's distributed queue-mode architecture. At larger scale, Postgres, Redis and worker processes remain separate architectural concerns. | Get Now |
| ZimaCube 2 Creator Pack | n8n combined with separately justified local NVIDIA model inference, AI processing or creator workloads. | Workflow orchestration plus compatible local LLM/AI services, large storage and other GPU applications. |
|
Extreme overkill for n8n alone. Verify exact GPU VRAM and model requirements before claiming that Creator Pack fits a specific Ollama/local-model workload. | 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
The supplied sources mix official OEM/Embed planning examples with third-party VPS recommendations. These answers preserve that distinction instead of promoting one provider's server tier into a universal n8n requirement.
How much RAM does n8n need?
There is no single universal self-hosted RAM minimum that fits every n8n workload. The current official OEM/Embed prerequisites show an illustrative 320 MB–2 GB memory range and about 100 MB for an idle n8n Cloud instance, while explicitly saying actual needs depend on workflows and data.
Is 2 GB RAM enough for n8n?
It can be enough for light workflows and testing. ScalaHosting and Latenode both use 2 GB as a low-end planning point, but these are third-party recommendations. Data-heavy workflows, concurrent executions and other services can require much more memory.
Why does Latenode say n8n officially needs 2 cores, 2 GB RAM and 20 GB storage?
Latenode presents 2 cores, 2 GB RAM and 20 GB storage as an 'official minimum,' but the current n8n OEM/Embed prerequisites supplied for this audit instead show illustrative 320 MB–2 GB memory and 512 MB–4 GB SSD database sizing and explicitly limit those examples to n8n Cloud-based guidance. Therefore Latenode's 2/2/20 tier is kept as third-party planning, not current universal upstream fact.
Is 4 GB or 8 GB RAM better for a production-like n8n server?
Third-party guides commonly land in this range: ScalaHosting says 4–8 GB for production, while Sliplane recommends 4 GB minimum and 8 GB preferred for its self-hosting setup. These are reasonable practical tiers, but n8n's actual memory use depends more on payload size, Code nodes, concurrency and co-hosted services than on a fixed label such as 'production.'
Does n8n need a GPU for AI workflows?
No when AI nodes call remote providers such as OpenAI, Claude or Gemini. A GPU/VRAM requirement only appears if the same server also runs a local inference backend such as Ollama. That model runtime must be sized separately from n8n.
Can ZimaBoard 2 run n8n?
Yes. ZimaOS currently lists n8n in its App Store, and ZimaBoard 2 832 provides an Intel N150, 8 GB RAM and dual 2.5GbE, giving substantial headroom for personal n8n and light-to-moderate automation. Add SSD storage for permanent database/execution data.
When should n8n use PostgreSQL instead of SQLite?
SQLite is the default and is appropriate for a simple single-instance start. PostgreSQL becomes more appropriate as the deployment grows, and n8n's current multi-main queue-mode documentation requires Postgres plus Redis for that scaled architecture.
When should I choose ZimaBoard 2 1664 or ZimaCube 2 Pro?
Choose 1664 when the same compact server needs more RAM for concurrent workflows, PostgreSQL and other containers. Choose ZimaCube 2 Pro when n8n is part of a broader storage-heavy homelab with more services and stronger CPU/network needs. Neither upgrade is required just because n8n is installed.
What sources and further reading informed this n8n hardware guide?
The official n8n OEM/Embed prerequisites are the highest-authority supplied source and provide illustrative 320 MB–2 GB memory and 512 MB–4 GB SSD database sizing while explicitly stating that the examples are based on n8n Cloud and actual needs depend on users, workflows and executions. Latenode claims 2 cores/2 GB/20 GB as an official minimum and 4+ cores/8 GB/50 GB+ for production, but those values are treated here as third-party guidance because they do not match the scope or wording of the current official prerequisites. ScalaHosting recommends 2 GB/2 cores/20 GB for light use and 4–8 GB RAM for production-like use. Andrew Kushnerov's Medium tutorial says 2–4 GB RAM, 2 cores and a few dozen GB are enough and uses a 4-GB/40-GB Hetzner example. Sliplane recommends at least 2 vCPU, 4 GB RAM and 40 GB SSD, with 8 GB RAM preferred. None of those third-party tiers is promoted into a universal n8n requirement.
