Measure job concurrency, CPU and database throughput; tune the job workload before increasing app replicas.
Large imports/exports and automation-heavy bases.NocoDB-hårdvarukrav: RAM, CPU, lagring och PostgreSQL, arbetare och bilagor
Planera NocoDB-hårdvara utifrån officiella krav på CPU, RAM och diskutrymme, PostgreSQL, Redis, worker-aktivitet och lagring av bilagor, samt praktiska råd för ZimaOS.
NocoDB hardware requirements at a glance
NocoDB lists minimum 2 vCPU, 2 GB RAM and 10 GB disk, with production recommendations of 4 vCPU, 8 GB RAM and 50 GB+ disk. Its current quickstart includes app, worker, PostgreSQL and Redis services; attachments and imports add workload beyond the web UI.
- RAM
- Official self-hosting minimum: 2 GB; production recommendation: 8 GB. Leave additional capacity for ZimaOS and unrelated containers on a shared host.
- CPU
- Official minimum: 2 vCPU; production recommendation: 4 vCPU. Import/export jobs, API traffic, formulas and automations affect practical compute.
- Storage
- Official minimum: 10 GB; production recommendation: 50 GB+. Store database, attachments, Redis/job state and backups durably; the recommendation is not an attachment quota.
- Database / cache
- Current quickstart uses PostgreSQL and Redis alongside app and worker containers. Do not describe an old one-container SQLite example as the complete current quickstart.
- Workers / networking
- Background jobs have a separate worker workload. Quickstart uses port 8080; the single-server HTTPS installer adds a proxy that expects reachable ports 80/443.
- Best Zima starting point
- ZimaBoard 2 832 with SSD-backed data is a modest starting point but leaves less headroom when the recommended 8 GB app stack shares the host. Consider 1664 for production-style consolidation.
From official requirements to the right setup
Plan the complete NocoDB workload before selecting a server.
-
Official requirements
Start with the official minimum/recommended table and current multi-service topology. Distinguish NocoDB host sizing from Kubernetes per-pod resource requests.
-
Confirm your needs
Estimate concurrent editors/API clients, import/export size, formula/automation activity and background jobs. An almost empty UI does not represent a busy data workflow.
-
Leave room to grow
Persist PostgreSQL, Redis and application/attachment data; include recoverable database and attachment backups. Size record indexes and uploaded files separately.
-
Run it on ZimaOS
Use ZimaOS Custom Install with the app, worker and companion services. Map 8080 to an available host port or adapt the documented proxy topology without taking ports 80/443 from existing host services.
Check every playback client
- 2 vCPU / 2 GB / 10 GB minimum baseline
- Production 4 vCPU / 8 GB / 50 GB+ target
- Concurrent editors and API traffic
- Import/export batch sizes
- Background worker concurrency
- PostgreSQL and Redis persistence
- Attachment volume and retention
- App/proxy ports and backup recovery
Official minimum requirements
Reviewed October 30, 2026 against the linked upstream deployment documentation. Numerical values retain their stated minimum, recommendation or example scope; select release-compatible instructions before installation.
The numbers above are official self-hosting minimums and recommendations. Kubernetes resource requests, legacy SQLite community methods and an empty-table test do not replace them. A host with exactly 8 GB total RAM has less than 8 GB available after OS and other services.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Host CPU | 2 vCPU minimum; 4 vCPU production recommended | Official self-hosting requirements, not a throughput guarantee. |
| Host RAM | 2 GB minimum; 8 GB production recommended | Budget ZimaOS and other containers beyond the intended application stack. |
| Host disk | 10 GB minimum; 50 GB+ production recommended | Add capacity according to database, attachments, backup and retention growth. |
| Current quickstart stack | App + worker + PostgreSQL + Redis | All four containers are documented in the current quickstart. |
| Official image | nocodb/nocodb | App and worker use the same release image; pin a production version. |
| Runtime / ports | Docker Engine/Desktop; Compose-based stack; app port 8080 | Production recommends Linux; the HTTPS single-server path adds proxy port requirements. |
| Persistence | PostgreSQL, Redis and application data volumes | Attachments and backups require their own capacity and recovery plan. |
When to upgrade your hardware
Use observed NocoDB workload pressure to decide when an upgrade is warranted.
Imports and automations build a worker backlog
Editors/API clients overwhelm database memory or connections
Attachments and database backups exceed storage
Check SQL latency, connection pools and Redis alongside app usage. Adding only frontend CPU may not improve database contention.
Busy collaborative bases.Track files, SQL indexes, deletion/retention policy and recovery copies separately.
Image/document-rich datasets.Plan hardware growth with confidence
Address storage, memory, compute and deployment limits separately.
Put active database data on SSD
Improve SQL/app state latency and keep verified database/attachment backups.
ZimaBoard 2 with SATA/PCIe SSD.Choose memory beyond the production recommendation
Use 16 GB for the recommended stack plus OS and additional services when the workload fits the CPU.
ZimaBoard 2 1664.Expand attachment and backup capacity
Use more drives only for deliberate retention and broader archive needs.
ZimaCube 2 Standard, while accounting for its 8 GB base RAM.Scale CPU for measured jobs and concurrency
Use stronger compute when worker/API demand is demonstrably CPU-bound and SQL storage is healthy.
ZimaCube 2 Pro.Can it run on ZimaOS?
No specific public official one-click NocoDB ZimaOS page was verified. Use Custom Install with the current official app/worker/database/cache topology.
Custom install NocoDB in ZimaOS
Deploy the current NocoDB stack with persistent PostgreSQL, Redis and application/attachment data; adapt port 8080 and proxy configuration to existing ZimaOS services.
Custom install NocoDB in the ZimaOS app ↗Use the official NocoDB deployment instructions
Keep the selected stable release, persistent paths and companion services aligned with upstream documentation.
Review NocoDB official installation ↗Review the current multi-service quickstart
Keep app and worker versions aligned and size background jobs, database and Redis alongside the web application.
Review NocoDB deployment details ↗Which Zima hardware fits NocoDB?
Start with the lowest reasonable host for the actual workload. Product specifications were checked against the current product pages.
Which workload best matches your NocoDB deployment?
Modest internal data workflow
Use SSD-backed storage and leave host headroom beyond the baseline.
- Workload optionZimaBoard 2 832
- Workload optionZimaBoard 2 1664
Larger imports or consolidated business services
Choose stronger compute for measured worker and SQL pressure.
- Workload optionZimaCube 2 Pro
These are practical workload recommendations, not official app requirements, compatibility certification, measured capacity limits or performance guarantees. Include all co-hosted services and independent backups.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Modest NocoDB workload | Small internal bases, app/worker and suitable companion services. |
|
Total 8 GB host RAM is shared with the OS; do not call it 8 GB dedicated application capacity. | Get Now |
| ZimaBoard 2 1664 | Production-style host headroom | NocoDB stack plus OS and modest additional services. |
|
The four-core N150 remains; vCPU/core counts alone do not guarantee job throughput. | Get Now |
| ZimaCube 2 Pro | More concurrent jobs and services | SQL-backed data workflows and broader server consolidation. |
|
Storage latency, worker configuration and query behavior remain important. | 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
Answers to NocoDB RAM, CPU, storage, Docker, database and ZimaOS sizing questions.
What is the official NocoDB RAM minimum?
The self-hosting page lists 2 GB minimum and 8 GB production recommended. Include host OS and unrelated containers when choosing a shared server.
How many CPU cores does NocoDB need?
Official guidance lists 2 vCPU minimum and 4 vCPU production recommended. Formula work, imports, automations and API concurrency affect practical throughput beyond that baseline.
Which services are in the current quickstart?
The current documented stack has NocoDB app, a background worker, PostgreSQL and Redis. Historical SQLite-based community methods should not be represented as the complete modern quickstart.
Is 10 GB enough disk space?
10 GB is the official minimum, while 50 GB+ is the production recommendation. Plan actual database growth, attachments, job state and backup copies; neither value guarantees retention for all datasets.
Does NocoDB need a GPU?
No dedicated GPU is required for the ordinary database UI/API and worker stack. Optional external AI or execution services must be sized according to their own backend rather than added to the core minimum.
Can ZimaBoard 2 run NocoDB?
It is a practical modest-stack candidate with SSD-backed state. The 16 GB model offers more room around the 8 GB production recommendation; both models still share the same N150 CPU.
Why can imports be slow while the UI stays responsive?
Imports/exports and automations can run as background jobs. Check worker backlog, SQL write latency and CPU separately from web requests before selecting an upgrade.
When should I choose ZimaCube 2 Pro?
Choose it for measured CPU-heavy jobs or wider server consolidation. More drive bays alone do not resolve slow SQL queries, connection pressure or an undersized worker configuration.
What sources informed this NocoDB hardware guide?
This guide was reviewed against the linked project deployment documentation on October 30, 2026. Zima device choices are editorial workload guidance, separate from upstream requirements and measured performance.
