Hash verification and many concurrent streams increase compute and bandwidth demand.
Large migrations and multi-cloud sync.Hardwarevereisten voor Clumoove: RAM, CPU, opslag en implementatie
Plan Clumoove-hardware voor RAM, CPU, PostgreSQL, Redis, worker-concurrency en cloudoverdracht-bandbreedte, met praktische richtlijnen voor ZimaOS-formaat.
Clumoove requirements at a glance
Clumoove is a multi-container cloud migration/sync platform with React, Go API and worker services, PostgreSQL and Redis. Upstream publishes no numerical host CPU/RAM minimum; transfer concurrency and network speed dominate sizing.
- RAM
- No numerical official whole-host minimum published.
- CPU
- No numerical official core minimum. Worker concurrency, hashing and many simultaneous transfers drive CPU use.
- Database/cache
- PostgreSQL stores durable task queues and state; Redis handles distributed coordination and short-lived state.
- Transfer model
- Files are streamed source-to-target without intermediate disk caching, reducing local scratch-storage needs.
- Parallelism
- Production Compose uses MAX_THREADS with a default of 50 per worker; actual safe concurrency depends on CPU, RAM, providers and bandwidth.
- Best Zima starting point
- ZimaBoard 2 832 suits modest migration/sync workloads; 16 GB or ZimaCube 2 Pro is better for many workers and high-throughput local/NAS transfers.
From official requirements to the right setup
Size Clumoove from the real workload and deployment topology rather than generic server assumptions.
-
Official requirements
Use Clumoove's production Docker Compose stack with separate frontend, API, worker, PostgreSQL and Redis services.
-
Confirm your needs
Set unique encryption/JWT secrets and a strong Redis password before deployment.
-
Leave room to grow
Tune MAX_THREADS and worker count to the source/target provider limits, available CPU/RAM and network bandwidth rather than leaving concurrency unlimited.
-
Run it on ZimaOS
On ZimaOS, use Install Custom App because no concrete public official ZimaOS one-click detail page was verified; persist PostgreSQL and any local-storage sandbox paths.
Check every playback client
- PostgreSQL
- Redis
- MAX_THREADS
- Worker count
- Source/target APIs
- Network bandwidth
- Local storage sandbox
- Backup retention
Official minimum requirements
Clumoove upstream documents architecture, services, ports and concurrency but no numerical server hardware minimum.
Do not invent a RAM/core floor. The key resource variables are transfer concurrency, hashing, PostgreSQL/Redis state and source/target network throughput.
| Requirement | Official minimum | What this supports |
|---|---|---|
| RAM minimum | No numerical official minimum published | Five-service stack and workload determine memory. |
| CPU minimum | No numerical official minimum published | Workers and hash verification drive compute. |
| Core services | Frontend, API, worker, PostgreSQL and Redis | Current documented architecture. |
| Production max threads | 50 per worker by default | Current production Compose setting. |
| Web/API ports | 3001 and 8001 | Documented remote-host development/entry ports. |
| Intermediate file cache | Not required for streamed migrations | Transfers are streamed source-to-target. |
When to upgrade your hardware
Scale Clumoove when these workload signals appear.
Parallel transfers saturate CPU or WAN
More workers increase PostgreSQL connections
Local/NAS migration becomes storage-network bound
Horizontal worker scaling raises DB connection and coordination requirements.
High-throughput deployments.SMB/SFTP/local-storage paths can shift the bottleneck to disks and LAN throughput.
NAS-to-cloud and NAS-to-NAS workflows.Plan hardware growth with confidence
Scale Clumoove only where the workload justifies additional resources.
Use ZimaBoard 2 832 for modest migrations
Enough for a small number of concurrent workers and cloud-limited transfers.
ZimaBoard 2 832.Use 16 GB when parallelism grows
More workers plus PostgreSQL/Redis benefit from additional RAM.
ZimaBoard 2 1664.Use fast storage for PostgreSQL and local sandbox data
Persistent state and any local backup repositories benefit from SSD/NVMe.
Use SATA/NVMe or ZimaCube SSD tiers.Use ZimaCube 2 Pro for high-throughput LAN/NAS migration
Stronger CPU and 10GbE-capable local networking better suit many parallel local transfers.
ZimaCube 2 Pro.Can it run on ZimaOS?
Clumoove deployment on ZimaOS should follow the verified route below.
Custom install Clumoove in ZimaOS
Deploy Clumoove's production Compose stack with PostgreSQL/Redis, persist database/local-storage paths and tune worker concurrency to the host and network.
Custom install Clumoove in the ZimaOS app ↗Review Clumoove upstream deployment
Use current upstream deployment guidance for images, ports and persistent services.
Review Clumoove repository ↗Verify ZimaOS App Store status again before publishing
No concrete public official ZimaOS one-click detail page was verified for this guide, so the Custom Install route is used.
Browse the ZimaOS App Store ↗Choose Zima hardware for Clumoove
Clumoove is mostly a transfer/orchestration platform, so concurrency and network/storage topology are more important than idle application footprint.
Which Clumoove workload are you running?
Modest cloud-to-cloud or NAS sync
Use ZimaBoard 2 832 and keep worker concurrency conservative.
- Best starting pointZimaBoard 2 832
- More worker headroomZimaBoard 2 1664
Many workers / fast local NAS transfers
Use stronger CPU and faster local networking/storage.
- Higher-throughput platformZimaCube 2 Pro
Provider API limits and WAN speed can dominate performance even on faster Zima hardware.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Modest Clumoove migration/sync jobs. | Frontend/API/worker/PostgreSQL/Redis with conservative concurrency. |
|
Cloud-provider APIs or WAN may bottleneck before hardware. | Get Now |
| ZimaBoard 2 1664 | More concurrent transfer workers. | Larger PostgreSQL/Redis working set and parallel jobs. |
|
N150 CPU can become the limit with heavy hashing and many threads. | Get Now |
| ZimaCube 2 Pro | High-throughput LAN/NAS migration. | More workers, fast local storage and 10GbE-capable networking. |
|
Remote provider limits can still dominate throughput. | 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 Clumoove RAM, CPU, storage and ZimaOS deployment.
How much RAM does Clumoove need?
Clumoove does not publish a numerical official whole-host RAM minimum.
How many CPU cores does Clumoove need?
No numerical official core minimum is published; hashing and worker concurrency determine demand.
Which databases/services does Clumoove use?
PostgreSQL stores durable state/task queues and Redis handles coordination and short-lived state.
Does Clumoove need temporary disk space for transfers?
Its documented migration flow streams data source-to-target without intermediate disk caching.
How does concurrency affect hardware?
Higher MAX_THREADS and more workers increase CPU, RAM, PostgreSQL connections and network use.
Does Clumoove need a GPU?
No dedicated GPU is required.
Can ZimaBoard 2 run Clumoove?
Yes for modest workloads; use 16 GB or stronger CPU as worker concurrency grows.
Is Clumoove currently a verified ZimaOS one-click app?
No concrete public official ZimaOS detail page was verified, so this guide uses Custom Install.
What sources informed this Clumoove hardware guide?
Current Clumoove repository/deployment documentation, IceWhale AppStore release history and Zima product pages.
