GitHub and Reddit users repeatedly report CPU saturation as the second, third or fourth HD camera is added. This is the clearest sign that stream settings or host CPU must change.
Multi-camera 1080p/4K deployments.motionEye Hardware Requirements: CPU, RAM, Cameras & Recording
Learn motionEye CPU, RAM, camera, recording and motion-detection requirements, then choose ZimaOS hardware for surveillance workloads.
motionEye requirements at a glance
motionEye does not publish a numerical CPU or RAM minimum. It is a Python web frontend for the Motion surveillance daemon, and camera workload dominates hardware sizing. Each stream's resolution, frame rate, codec, live viewing, motion detection and recording path can change CPU usage dramatically. Community reports repeatedly show CPU saturation with several 1080p or 4K streams even when RAM remains available.
- CPU
- No official numerical minimum. CPU is the main sizing variable when streams must be decoded for motion detection, live preview or re-encoding.
- RAM
- No official numerical minimum. Community examples range from 512 MB/1 GB Pi systems to multi-GB hosts; camera decoding and buffering matter, but CPU often hits the limit first.
- Software
- Current motionEye installation requires Python 3.7 or later and relies on the Motion daemon/FFmpeg-related video stack.
- Camera workload
- Camera count alone is insufficient: 1080p/25 FPS H.264 motion detection is much heavier than a low-resolution substream at 5 FPS, and 4K can overwhelm small hosts.
- Storage
- Recording capacity depends on bitrate × cameras × retention time. Motion passthrough can reduce re-encoding work, but recording and motion detection still create disk and decode workloads.
- Best Zima starting point
- ZimaBoard 2 832 is a sensible starting point for a small number of moderate-resolution cameras with conservative FPS/settings. ZimaCube 2 becomes more attractive as camera count and recording retention require integrated multi-drive storage.
From official requirements to the right setup
motionEye sizing starts from the video pipeline: cameras × stream resolution × FPS × detection/recording mode.
-
Official requirements
List each camera's main and substream resolution, codec and FPS. Use low-resolution substreams for motion detection where possible rather than decoding every 4K main stream.
-
Confirm your needs
Decide which streams need motion detection, live preview and recording. Motion detection requires decoded frames; that CPU work can remain substantial even when movie recording itself uses passthrough.
-
Leave room to grow
Calculate recording storage separately from application RAM. Continuous and motion-triggered recording, retention and camera bitrate determine HDD/SSD capacity and sustained write load.
-
Run it on ZimaOS
Install motionEye from ZimaOS, add cameras one by one, monitor CPU per stream and test the exact detection/recording settings. Only scale hardware after identifying whether decode, motion processing, storage writes or live preview is the bottleneck.
Check every playback client
- Number of cameras
- Main/substream resolution
- Frame rate used by motionEye
- H.264/H.265/MJPEG codec
- Motion detection enabled per stream
- Movie passthrough versus re-encoding
- Continuous versus motion-triggered recording and retention
- Storage write throughput and available capacity
Official minimum requirements
Current motionEye documentation defines its Python/Linux software prerequisites but does not publish a host CPU, RAM or camera-count minimum.
Do not turn a Raspberry Pi model or one user's 2 GB/4 GB setup into a universal requirement. Camera decoding and motion detection scale with the actual streams; benchmark representative cameras and use substreams before buying oversized hardware.
| Requirement | Official minimum | What this supports |
|---|---|---|
| CPU | No numerical minimum published | Real CPU demand depends on stream decode, motion detection, preview and encoding. |
| RAM | No numerical minimum published | Community examples show CPU can saturate while substantial RAM remains free. |
| Python | Python 3.7 or later | Current official installation prerequisite. |
| Motion daemon | Required backend surveillance engine | motionEye is the web frontend/configuration layer around Motion. |
| Camera count | No official universal limit | Resolution, FPS, codec and detection mode make camera count alone misleading. |
| Storage | No fixed capacity minimum | Recording bitrate and retention determine real capacity. |
When to upgrade your hardware
Upgrade motionEye when camera decode/detection or recording storage reaches measurable limits.
CPU stays near 100% after adding more cameras
Motion detection on high-resolution streams is too expensive
Recording retention outgrows the current disk layout
motionEye/Motion must decode frames to perform motion detection. Using a lower-resolution substream or lower detection FPS can reduce CPU dramatically while keeping the high-resolution stream for recording.
Users detecting motion on 1080p/4K IP cameras.Surveillance storage grows continuously with bitrate and retention. Multi-drive ZimaCube hardware can be justified by capacity and write workload even if CPU remains acceptable.
Long-retention and continuous-recording setups.Plan hardware growth with confidence
Scale motionEye by reducing unnecessary decode work before upgrading compute.
Use camera substreams for motion detection
A lower-resolution, lower-FPS substream can reduce decode and motion-analysis work while a main stream remains available for higher-quality recording.
This often saves more CPU than adding RAM.Use movie passthrough when the workflow allows
Passthrough avoids video re-encoding for recording, reducing one major CPU cost. It does not eliminate the separate decode work needed for motion detection or live preview.
Verify CPU with detection and preview enabled rather than assuming passthrough makes the server idle.Separate surveillance storage from appdata
Keep motionEye configuration on reliable app storage and record video to disks sized for sustained writes and retention.
HDDs are appropriate for bulk surveillance retention; SSD/NVMe can help metadata/appdata and high-I/O workflows.Do not buy a discrete GPU without a verified acceleration path
Community threads discuss Quick Sync/VAAPI, but motionEye/Motion hardware acceleration behavior is configuration- and backend-dependent and is not a universal supported requirement.
Treat GPU/iGPU acceleration as an experiment to verify on the exact container, codec and Motion build.Can it run on ZimaOS?
motionEye is currently available in the ZimaOS App Store and is suitable for consolidating IP-camera monitoring with local storage.
Install motionEye from the ZimaOS App Store
The current ZimaOS listing packages motionEye as the web frontend for the Motion daemon.
Open motionEye in the ZimaOS App StoreUse current motionEye releases
motionEye shipped security fixes in June 2026, so keep the app/container current rather than preserving an old motionEyeOS-era stack.
Read current motionEye releasesBenchmark cameras one by one
Add each RTSP/video source with its actual detection and recording settings and watch CPU before scaling to the full camera count.
Read the motionEye project documentationChoose Zima hardware for motionEye
motionEye is one of the cases where the App name alone is not enough to choose hardware. Size from camera decode/detection and recording storage.
Is this a small camera setup or a larger surveillance/retention server?
A few moderate-resolution cameras with conservative FPS/detection
Start on ZimaBoard 2 and validate real CPU usage before adding more streams.
- Small motionEye deploymentZimaBoard 2 832
- More cameras and co-hosted smart-home servicesZimaBoard 2 1664
More cameras, long retention or heavier HD workloads
Integrated drive bays and Core-class CPU headroom become more useful as surveillance storage and decode work grow.
- Multi-drive camera recording serverZimaCube 2 Standard
- Heavier camera/storage and multi-service stackZimaCube 2 Pro
These are workload tiers, not guaranteed camera-count or FPS benchmarks. Camera codec, resolution, substreams, motion settings, Motion/FFmpeg build, storage and container configuration can produce very different CPU usage.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | A small motionEye deployment with a few moderate streams. | Low-to-moderate FPS monitoring, selective motion detection and local recording. |
|
Do not promise a specific camera count; multiple 1080p/4K streams can saturate CPU depending on settings. | Get Now |
| ZimaBoard 2 1664 | More cameras plus Home Assistant and other smart-home services. | Larger combined automation/camera stack and more memory headroom. |
|
Extra RAM does not solve a decode-bound CPU workload; use substreams and measure CPU. | Get Now |
| ZimaCube 2 Standard | A larger multi-drive surveillance storage server. | More cameras, longer retention and integrated HDD capacity. |
|
Choose it when storage/CPU scale justifies the move, not from camera count alone. | Get Now |
| ZimaCube 2 Pro | A heavier all-in-one camera and storage platform. | Higher aggregate camera workload, long retention and many co-hosted applications. |
|
Dedicated GPU is not required; verify any Intel hardware-acceleration path independently. | 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 FAQ topics follow query fan-out around camera count, CPU saturation, motion detection, passthrough, 4K, GPU acceleration and storage retention. Reddit and motionEye GitHub issues were used because those questions dominate real deployment discussions.
How much RAM does motionEye need?
motionEye does not publish a numerical RAM minimum. Community deployments run on small Raspberry Pi systems and larger servers, but multi-camera problems are often CPU-bound before RAM is exhausted.
Why does motionEye use so much CPU with multiple cameras?
Every stream may need decoding for preview and motion analysis. GitHub and Reddit reports show CPU use climbing sharply as additional HD cameras are added, even when recording is disabled or RAM remains available.
Does motion detection require decoding the video stream?
Yes. Motion analysis operates on decoded image frames, so a high-resolution/high-FPS detection stream can consume substantial CPU even if the original camera already sends compressed H.264/H.265.
Why is CPU still high when movie passthrough is enabled?
Passthrough avoids re-encoding the recording, but live preview and motion detection can still require decoding frames. Passthrough removes one CPU cost, not every video-processing cost.
Can motionEye handle 4K cameras?
It can ingest 4K streams, but that does not mean a small host can decode and detect motion on several 4K feeds. Community reports show 4K can push Raspberry Pi-class systems close to full CPU/RAM. Use a lower-resolution substream for detection when possible.
Can ZimaBoard 2 832 run motionEye?
Yes as a sensible starting point for a small camera deployment, but there is no safe universal camera-count promise. Test your actual codec, resolution, FPS and motion settings before scaling.
Will Intel Quick Sync or a GPU fix motionEye CPU usage?
Not automatically. Hardware acceleration depends on the Motion/FFmpeg build, codec, container device access and configuration. Community discussions show mixed results, so treat QSV/VAAPI as a feature to verify rather than a guaranteed requirement.
How much storage does motionEye need for recordings?
Capacity is driven by camera bitrate, number of recording cameras and retention time. For long continuous retention, storage can become the main reason to move from ZimaBoard 2 to a multi-bay ZimaCube 2.
What sources and further reading informed this motionEye hardware guide?
The motionEye repository and wiki establish the current Python/Linux/Motion deployment model, while the current release page confirms active 2026 maintenance and security fixes. GitHub and Reddit discussions were deliberately used for FAQ fan-out because CPU saturation, motion detection, passthrough and multi-camera scaling are the dominant practical hardware questions. Those user reports are workload evidence, not official camera-count guarantees.
