ERPNext is database-centric. Larger working sets, reports and transactional activity can drive database cache and CPU demand; Frappe recommends monitoring and adding resources when utilization remains high.
Growing accounting, inventory, manufacturing and CRM databases.ERPNext-Hardwareanforderungen: RAM, CPU, Datenbank und Speicherplatz
Plane die Hardware für ERPNext hinsichtlich RAM, CPU, MariaDB oder PostgreSQL, Redis, Workern, Dateien und Backups mit praxisnaher Docker-Dimensionierung für eine benutzerdefinierte ZimaOS-Installation.
ERPNext requirements at a glance
Current Frappe documentation does not publish one universal production CPU/RAM/disk minimum for an entire ERPNext server. Official production guidance now recommends Docker rather than bare-metal deployment, while separate Frappe guidance recommends at least 2 vCPU and 8 GB RAM as a database-server starting point. For a single-box ZimaOS deployment, treat 16 GB host RAM as a practical small-production class rather than an official ERPNext minimum.
- CPU
- No universal ERPNext production minimum published. Frappe's database optimization guide recommends starting a database server with at least 2 vCPU.
- RAM
- No universal whole-stack production minimum published. Official database guidance recommends starting with at least 8 GB RAM; the Frappe Docker development environment recommends allocating at least 4 GB to Docker.
- Storage
- No universal numerical minimum published for production. Capacity grows with database records, attachments, private files, logs, backups and document generation.
- Database & services
- ERPNext runs on Frappe with a database, Redis/Valkey, web/socket services, background workers and scheduler jobs. All of them count toward host sizing.
- GPU
- No GPU is required for standard ERPNext business workloads.
- Best Zima starting point
- ZimaBoard 2 1664 is the practical minimum class for a small all-in-one ERPNext deployment; choose ZimaCube 2 Pro when database growth, workers, backups or broader business services need stronger CPU and storage.
From official requirements to the right setup
Size ERPNext as a complete Frappe stack. The database, Redis/Valkey, web processes, background workers, scheduler, file storage and backups can consume more resources than the front-end web service itself.
-
Official requirements
Do not invent a universal ERPNext production minimum. Current Frappe install docs define supported software dependencies, while production guidance recommends Docker. Use the official 2 vCPU/8 GB database starting point only as database guidance, not as a whole-ERPNext minimum.
-
Confirm your needs
Estimate active users and business workload: reports, imports, accounting transactions, manufacturing operations, background queues, scheduled jobs, PDF generation and integrations can all increase CPU and worker demand.
-
Leave room to grow
Plan storage for both the transactional database and files. Attachments, private files, backups, logs and database growth should live on persistent SSD-backed storage with independent backup copies.
-
Run it on ZimaOS
On ZimaOS, use Install Custom App with the official frappe_docker stack or a carefully adapted Compose definition. Persist sites, database and queues, secure secrets, configure HTTPS, then monitor database memory, worker queues and disk growth before scaling.
Check every playback client
- ERPNext/Frappe major version
- Expected active and concurrent users
- Modules in use and background-job volume
- MariaDB or PostgreSQL database choice
- Report/import/PDF generation workload
- Attachment and private-file growth
- Backup frequency and retention
- Other ZimaOS business apps sharing the host
Official minimum requirements
Frappe's current documentation provides software prerequisites and workload-specific hardware guidance, but not one numerical production minimum for the entire ERPNext stack. Numeric figures below are therefore labeled by their actual scope.
Do not call 4 GB, 8 GB or 2 vCPU 'the ERPNext minimum.' Four gigabytes is a Docker development allocation recommendation; 2 vCPU and 8 GB are Frappe's database-server starting recommendations. A single-box production ERPNext deployment also needs memory and CPU for web, queue, scheduler and system services.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Whole-stack production CPU minimum | No universal numerical minimum published | Frappe production sizing depends on the database, worker count, users, reports, integrations and background jobs. |
| Whole-stack production RAM minimum | No universal numerical minimum published | Do not reinterpret development or database-specific guidance as a complete ERPNext server minimum. |
| Docker development allocation | At least 4 GB RAM recommended for Docker | This is from the official frappe_docker development guide and is not a production-server requirement. |
| Database CPU starting point | At least 2 vCPU recommended | Frappe's database optimization guide recommends this for the database server and advises scaling when CPU utilization stays high. |
| Database RAM starting point | At least 8 GB RAM recommended | This is database guidance, not the whole ERPNext host requirement. Frappe also advises against relying on swap for the database server. |
| Production deployment method | Docker recommended | Current Frappe production guidance warns against bare-metal installation and points users to Docker images. |
| Storage minimum | No universal numerical production minimum published | Size for the database, site files, private files, logs, backups and update/build working space. |
When to upgrade your hardware
ERPNext should scale when the database, background queues or user-facing request latency shows sustained pressure, not because an arbitrary employee count has been reached.
Database memory or CPU stays under sustained pressure
Background workers and reports fall behind
Files and backups outgrow the current storage plan
Imports, scheduled jobs, integrations, email, PDF generation and long-running tasks can build queue delay and compete with interactive web requests for CPU and memory.
Businesses using automation, bulk imports, heavy reporting or multiple integrations.Site files, private attachments, database backups and logs accumulate over time. Capacity and restore windows can become the constraint even when web performance still looks acceptable.
Long-running deployments with attachments, compliance retention or frequent backups.Plan hardware growth with confidence
Scale ERPNext by separating persistent data from the system disk, protecting database memory and adding worker/CPU headroom only where workload evidence supports it.
Put the database and site data on SSD storage
ERPNext performs continuous transactional database I/O and serves many small files. SSD-backed persistence improves responsiveness and reduces contention compared with a small boot device.
Use SATA/NVMe storage with ZimaBoard 2 or ZimaCube 2; keep the onboard eMMC/system disk for the OS rather than the only production database copy.Start small production with 16 GB host RAM
Frappe's database guidance alone recommends an 8 GB starting point. A single-box host also needs web, queue, Redis/Valkey, scheduler, Docker and ZimaOS memory, so 16 GB is a practical whole-host class.
ZimaBoard 2 1664 or ZimaCube 2 Pro; this is a practical recommendation, not an official ERPNext minimum.Scale workers and CPU when queues or reports are slow
Add worker concurrency only when the host has enough RAM and monitoring shows CPU/queue pressure. More workers on a memory-starved host can make latency worse.
Move to ZimaCube 2 Pro when sustained multi-threaded business workloads exceed the compact N150 class.Separate backup retention from active database storage
Keep fast storage for the live database and site files, while placing long-retention backup copies on larger disks or another system.
ZimaCube 2's multi-drive layout is useful when ERPNext becomes part of a broader business-data and backup platform.Can it run on ZimaOS?
ERPNext is not currently presented as a one-click ZimaOS App Store app. It can be deployed through Install Custom App using the official Frappe Docker stack, but it is a multi-container application and requires more careful persistence, secrets and database planning than a single-container app.
Custom install ERPNext in ZimaOS
Use Install Custom App with an adapted configuration from the official frappe_docker project. Persist site files and the database, configure Redis/Valkey and workers, set database passwords/secrets, and verify the public port, HTTPS proxy and backup path before production use.
Custom install ERPNext in the ZimaOS app ↗Use the official Frappe Docker deployment model
Frappe's current production documentation recommends Docker rather than bare-metal deployment. The official frappe_docker repository provides the container images and orchestration patterns for Frappe applications including ERPNext.
Open the official Frappe Docker project ↗Protect the database, sites and backups
ERPNext's useful data spans the transactional database plus site files and private files. Custom-install volume mappings and backup/restore procedures should be validated before moving real business data to the system.
Review Frappe production guidance ↗Choose Zima hardware for ERPNext
ERPNext benefits from memory and SSD-backed database storage more than from graphics hardware. A compact 16 GB host suits small all-in-one deployments; stronger CPU, multi-drive storage and faster networking matter as the business workload grows.
Is this a small all-in-one ERPNext deployment or a growing business system with heavier database and worker load?
Small team, pilot or light production
Use 16 GB RAM and SSD-backed persistence so the database and Frappe services have room beyond development-level allocations.
- Compact 16 GB starting pointZimaBoard 2 1664
Growing production workload, heavier reports or business-data consolidation
Use the stronger Core i5 platform, 16 GB RAM, SSD expansion and multi-drive capacity, then scale beyond one host if availability or database demand requires it.
- Best larger starting pointZimaCube 2 Pro
These are workload-based recommendations, not guaranteed user-count or transaction-throughput benchmarks. ERPNext version, enabled modules, worker count, report complexity, database size, integrations, attachments, backups and other ZimaOS services can substantially change resource use.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 1664 | Small-team ERPNext, pilots and light all-in-one production with careful database/storage planning. | ERPNext web, database, Redis/Valkey, workers, scheduler, reverse proxy and regular backups on one ZimaOS host. |
|
Use an added SSD for the live database and site data. The N150 is a compact low-power CPU, so heavy reports, imports, integrations or worker concurrency can justify a stronger platform. | Get Now |
| ZimaCube 2 Pro | Growing ERPNext deployments with heavier database, worker and storage requirements. | Business ERP with larger MariaDB/PostgreSQL working set, multiple workers, integrations, reports, backups and additional self-hosted services. |
|
Sixteen gigabytes is a practical starting class, not a guaranteed ceiling. Large organizations, HA databases or sustained heavy reporting may need more RAM or separate database/app nodes. | 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 cover ERPNext RAM, CPU, storage, database, SSD, GPU and ZimaOS custom-install questions while keeping official Frappe guidance separate from practical whole-host sizing.
How much RAM does ERPNext need?
Frappe does not publish one universal whole-stack production RAM minimum for ERPNext. Its official Docker development guide recommends at least 4 GB allocated to Docker, while its database optimization guide recommends starting the database server with at least 8 GB RAM. For a single-box ZimaOS production deployment, 16 GB is a practical starting class because web, workers, Redis/Valkey, Docker and the OS also need memory.
Can ERPNext run on 4 GB RAM?
Four gigabytes appears in the official Frappe Docker development guidance, not as a universal ERPNext production minimum. It may be enough for development or a very constrained test, but a production all-in-one host can be squeezed by the database, workers, Redis/Valkey and background jobs.
How many CPU cores does ERPNext need?
There is no universal official whole-stack CPU minimum. Frappe's database optimization guide recommends starting a database server with at least 2 vCPU. Interactive requests, reports, imports and background workers can justify more CPU as the workload grows.
How much storage does ERPNext need?
Frappe does not publish one universal production disk minimum. Plan for the database, public and private site files, attachments, logs, update/build working space and multiple backup copies. Long-running business data can make storage growth more important than the initial application footprint.
Does ERPNext need an SSD?
An SSD is not presented as a universal formal minimum, but it is a strong practical recommendation for the active database and site data because ERP workloads depend on transactional database latency. Large backup archives can be moved to slower secondary storage.
Does ERPNext need a GPU?
No dedicated GPU is required for standard ERPNext accounting, CRM, inventory, manufacturing, HR and reporting workloads. Spend the hardware budget on CPU, RAM, database I/O and reliable backups instead.
Can ZimaBoard 2 run ERPNext?
Yes, especially the 16 GB ZimaBoard 2 1664 for a pilot, small team or light all-in-one deployment. Add SSD-backed persistent storage and monitor database memory, queue latency and CPU. Heavy reports, integrations or larger business workloads can justify ZimaCube 2 Pro or separate service nodes.
Why does ERPNext need more resources than a simple web app?
ERPNext runs on the Frappe stack, which includes the web application, transactional database, Redis/Valkey, background workers, scheduler and real-time services. Reports, imports, PDF jobs, integrations, attachments and backups create additional CPU, RAM and storage pressure.
What sources informed this ERPNext hardware guide?
The guide uses current Frappe installation and production documentation, the official frappe_docker project and Frappe's database optimization guidance. Current Zima product pages are used only for Zima hardware specifications and workload matching.
