Frigate NVR Hardware Guide: CPU, GPU, Coral, Hailo and Storage
The best Frigate server is not simply the machine with the fastest CPU. Size four workloads separately: video decoding, object detection, optional AI enrichments, and recording storage. For many new x86 builds, a modern Intel platform is an unusually practical starting point because its integrated GPU can handle video decode and OpenVINO workloads without a discrete GPU. Hailo remains a useful dedicated detector option. Google Coral is still supported, but Frigate no longer recommends it for most new installations except particularly low-power deployments or hardware that cannot use better-supported alternatives. NVIDIA becomes attractive when you also want GPU-backed detection or heavier enrichments.
Frigate is a local NVR with real-time object detection, but camera count alone is a poor hardware-sizing metric. A 4K H.265 stream, a low-resolution detection substream, continuous recording, semantic search, face recognition and a large detection model stress different parts of a system.
Quick recommendations
| Workload | Practical starting point | Why |
|---|---|---|
| Small existing x86 homelab | Modern Intel CPU with iGPU | Hardware decode plus OpenVINO without another accelerator |
| Low-power dedicated detector | Hailo, or an existing Coral where it still fits | Moves object detection away from the CPU; Coral is now a niche new-buy choice |
| Intel Core Ultra system | Intel NPU for detection, GPU for enrichments where supported | Frigate explicitly recommends this division on NPU+GPU systems |
| Existing NVIDIA server | Supported NVIDIA GPU | NVDEC plus TensorRT/ONNX path and GPU-backed enrichments |
| Existing AMD server | Modern AMD iGPU/dGPU | VAAPI video decode; ROCm/ONNX options on supported hardware |
| Raspberry Pi / compact ARM build | Hardware-specific path, often with dedicated accelerator | Works, but verify decode and detector support before buying |
| Camera-heavy recorder | Separate fast local database/config storage from adequately sized recording storage | Video retention is usually the capacity problem, not the Frigate database |
These are architecture defaults, not camera-count guarantees. Stream codec, resolution, FPS, detector model, retention policy and enabled enrichments can change resource demand dramatically.
Frigate has four different hardware problems
A useful Frigate build starts by refusing to collapse every workload into “AI acceleration.”
1. Video decoding
Every camera stream has to be decoded for processing. Frigate strongly recommends an integrated or discrete GPU for hardware-accelerated video decoding. Current documentation provides acceleration paths for Intel, AMD and NVIDIA hardware, plus Raspberry Pi, Jetson and Rockchip paths.
Video decode is not the same thing as object detection. A Coral can accelerate supported TensorFlow Lite object detection, but it does not decode your H.264/H.265 camera streams.
2. Object detection
Frigate's detector receives selected frames after motion processing. Current supported paths include Coral Edge TPU, Hailo, Intel OpenVINO, NVIDIA/ONNX, AMD ROCm/ONNX, Apple Silicon and several community-supported accelerator families.
Frigate still provides a CPU detector, but its documentation says CPU detection is for testing and is not recommended for general use. On suitable systems, OpenVINO CPU mode can also be more efficient than the default CPU detector.
3. Enrichments
Semantic search, face recognition and license-plate recognition are independent from basic object detection. Frigate can accelerate supported enrichments on Intel, NVIDIA, AMD and some Rockchip hardware, but support differs by feature and backend.
A dedicated detector therefore does not automatically accelerate everything. Frigate explicitly notes that a Coral TPU does not accelerate its enrichments.
4. Recording and retention
Continuous or event-based video creates a storage problem separate from AI inference. Capacity depends on camera bitrates and how much footage you retain. Do not choose an SSD capacity from camera count alone; calculate from actual aggregate bitrate and retention policy.
Intel: a strong general-purpose Frigate platform
Intel systems are compelling because the same platform can expose efficient video decoding and OpenVINO acceleration.
Frigate supports Intel integrated GPUs and Arc GPUs for video decode. Its OpenVINO detector can use Intel CPUs, GPUs and NPUs; current documentation says OpenVINO is supported on Intel platforms from 6th-generation Skylake onward, while GPU/NPU use requires a supported Intel platform.
For systems that have both an Intel NPU and GPU, Frigate's current guidance is particularly useful: use the NPU for object detection and the GPU for enrichments for the best supported division of work.
That does not mean every buyer needs Core Ultra. A modest Intel mini PC with a supported iGPU can be an excellent NVR because video decode efficiency often matters more than peak CPU benchmark scores.
Coral Edge TPU: still supported, but no longer the default new-buy recommendation
Google Coral remains an officially supported Frigate detector in USB, Mini PCIe and M.2 forms. It runs compatible TensorFlow Lite models through the Edge TPU delegate.
However, Frigate's current recommended-hardware guidance says Coral is no longer recommended for new installations except where very low power matters or the host cannot use alternative AI accelerators. That makes Coral most attractive when you already own one, have a constrained low-power deployment, or need compatibility with hardware that lacks a better current accelerator path.
Its limitation is equally important. Coral is a detector accelerator, not a universal Frigate accelerator. It does not provide video decode or Frigate enrichment acceleration.
A sensible existing-Coral architecture can therefore be:
- Intel or another supported GPU/iGPU for camera decoding;
- Coral for object detection;
- CPU/GPU as appropriate for the rest of the application.
Hailo: dedicated inference with newer model paths
Frigate officially supports Hailo-8 and Hailo-8L acceleration modules. Current documentation can automatically select a default model for detected Hailo hardware and supports model configuration through local files or URLs.
Hailo is worth considering when you want dedicated low-power inference and have compatible M.2/HAT connectivity. Verify the exact model and platform path you intend to use before buying hardware rather than assuming every accelerator supports every Frigate model.
NVIDIA: best when the GPU has more than one job
Frigate can use modern NVIDIA GPUs for hardware video decoding, and its stable-tensorrt image supports NVIDIA-specific inference paths. Current detector documentation also describes ONNX acceleration on NVIDIA hardware.
NVIDIA becomes especially attractive when the same machine will run supported enrichments or other CUDA/GPU workloads. Frigate's enrichment documentation says NVIDIA GPUs are automatically detected for supported enrichments in the TensorRT image.
The tradeoff is obvious: a discrete GPU adds purchase cost, idle power, cooling and PCIe requirements. Buying one solely to replace a detector that a lower-power accelerator or existing iGPU can handle may be poor system design.
AMD: viable, but check the exact software path
Modern AMD integrated and discrete GPUs can accelerate Frigate video decoding through VAAPI. Frigate also provides a stable-rocm image and an ONNX detector path for supported AMD GPUs.
The caveat is software support. Frigate notes that only some enrichment models are available on ROCm because compatibility and stability vary. An AMD GPU that is excellent for video decode is therefore not automatically equivalent to an NVIDIA or Intel path for every AI feature.
Buy against the current Frigate support matrix, not just raw GPU compute specifications.
Apple Silicon and other platforms
Frigate documents an Apple Silicon detector path for M1 and newer systems. Rockchip platforms can use RKNN NPUs through a community-supported path, and Jetson has community-supported TensorRT/ONNX support.
These can make excellent compact systems when you already own the hardware or have a specific deployment constraint. For a new generic NVR purchase, however, ecosystem maturity, device passthrough and upgrade options should be weighed alongside performance.
Do not mix up detector and decoder capacity
A common sizing mistake is to add an AI accelerator and expect CPU usage from cameras to disappear.
If FFmpeg is still decoding multiple high-resolution streams in software, object-detection acceleration does not solve that bottleneck. Conversely, flawless hardware video decode does not mean object inference is accelerated.
When diagnosing high utilization, inspect the pipeline in order:
- confirm camera stream configuration and codecs;
- confirm hardware video decoding is actually active;
- inspect detector inference times and utilization;
- inspect enrichment workloads separately;
- inspect recording I/O and storage latency.
Frigate warns that there is no CPU fallback when configured hardware video acceleration fails, so logs matter when validating a deployment.
Use camera substreams intelligently
The most efficient design often avoids feeding the full recording stream into every analytics task. Cameras that provide multiple streams can use a lower-resolution/lower-frame-rate stream for detection while retaining the higher-quality stream for recording.
This reduces decode and inference work without forcing you to sacrifice recording quality. Exact configuration depends on the camera and codec support, so treat stream design as part of hardware sizing rather than an afterthought.
Storage: calculate bitrate, not megapixels
Recording capacity is approximately a bitrate problem.
A useful planning equation is:
storage per day (GB) ≈ aggregate recording bitrate (Mb/s) × 10.8
For example, an aggregate 20 Mb/s of continuously retained camera video is roughly 216 GB/day before filesystem/container overhead. Seven days is roughly 1.5 TB. Variable bitrate, audio and retention rules will move the real number, so measure actual streams before buying disks.
Frigate can retain continuous footage, motion footage, alerts and detections differently. Selective retention can therefore change storage demand far more than changing the CPU.
Keep the database local
Frigate stores tracked-object and recording metadata in SQLite under /config. Its documentation warns that placing the database on SMB/NFS can cause database is locked errors. Network storage can still be used for media, but keeping the database/config path on reliable local storage avoids an unnecessary failure mode.
Frigate also recommends a tmpfs mount for /tmp/cache, where initial recording segments are staged.
HDD or SSD for recordings?
For large continuous-retention workloads, capacity and sustained write reliability usually matter more than NVMe-class latency. Large HDD-backed storage can therefore be sensible for recordings, while a small reliable SSD/NVMe device is attractive for the OS, containers and configuration/database path.
An SSD-only build may still make sense for a compact, silent system with short retention. The point is to size storage by workload rather than assuming “NVR means SSD” or “NVR means HDD.”
And RAID is not backup. Redundancy can keep recording through a disk failure, but it does not protect against deletion, filesystem corruption, theft or configuration mistakes.
Bare metal, Docker or VM?
Frigate's official installation guidance recommends Docker on a bare-metal Debian-based distribution. It explicitly says running Frigate in a VM on Proxmox, ESXi or VirtualBox is not recommended, although users have succeeded with Proxmox.
The issue is not ordinary VM CPU overhead. GPU, iGPU, Coral and other accelerator passthrough add failure points and platform-specific complexity.
If you already operate Proxmox and understand PCIe/USB device passthrough, virtualization may be an acceptable tradeoff. For a new appliance where reliability matters more than consolidation, bare-metal Linux plus Docker is the simpler reference architecture.
Security: expose the right port
Frigate's current installation documentation distinguishes port 8971, the authenticated UI/API endpoint, from port 5000, an internal unauthenticated UI/API endpoint. Reverse proxies should target 8971; exposing the unauthenticated internal endpoint carelessly expands risk.
Treat camera credentials and RTSP URLs as secrets. Keep Frigate and cameras segmented appropriately, restrict unnecessary inbound access, and avoid exposing management interfaces directly to the public internet.
A practical buying framework
Existing Intel mini PC
Start with the iGPU for hardware decode and OpenVINO. Measure before buying a Hailo, Coral or discrete GPU. This is often the cheapest route because the useful accelerators are already in the system.
Buying a low-power dedicated NVR
Prioritize:
- supported hardware video decode for your camera codecs;
- an officially supported detector path;
- enough local SSD for OS/config/database;
- appropriate recording storage capacity;
- reliable Ethernet;
- physical connectivity for any dedicated accelerator.
Do not pay for a high-end CPU simply because the machine handles several cameras. If buying a detector specifically for a new deployment, compare Hailo and the host's Intel/NVIDIA/AMD path before defaulting to Coral.
NVR plus AI-heavy enrichments
If semantic search, face recognition, license-plate recognition and other GPU-capable features are central to the deployment, choose hardware around the current enrichment support matrix as well as the detector. Intel GPU/NPU combinations and NVIDIA GPUs can be attractive here.
Existing NAS or Proxmox server
Consolidation can save hardware, but confirm accelerator passthrough and storage topology first. A NAS CPU with no suitable video acceleration may be a worse Frigate host than a cheap mini PC. Likewise, a powerful hypervisor does not help if the required iGPU/USB/PCIe device cannot be passed through cleanly.
What to measure after deployment
A Frigate build should be validated rather than declared “good” from specifications alone. Check:
- whether hardware video acceleration is active for each relevant stream;
- CPU utilization during normal and high-motion periods;
- detector inference time and queue behavior;
- GPU/NPU/TPU utilization where available;
- dropped or problematic camera streams;
- recording write rate and free capacity;
- database/storage errors;
- temperatures and throttling;
- power draw if the system runs 24×7.
Only add hardware after identifying the actual bottleneck.
Final recommendation
For a new general-purpose Frigate box, start with efficient hardware video decoding and a supported detector path, not with the biggest CPU. A modern Intel mini PC is a strong default because it can cover decode and OpenVINO workloads economically. Hailo is a reasonable dedicated-inference option when its connectivity and model path fit. Coral remains useful when already owned or when its low-power niche is specifically valuable, but it is no longer Frigate's default new-install recommendation. NVIDIA is strongest when the GPU will also earn its power budget through supported enrichments or other workloads. AMD is viable for decode and supported ROCm/ONNX paths, but verify feature compatibility first.
Most importantly, keep the four resource domains separate: decode, detection, enrichments and storage. That model produces more reliable hardware decisions than any fixed “X cameras need Y CPU” table.
Sources
- Frigate documentation: Recommended Hardware — https://docs.frigate.video/frigate/hardware/
- Frigate documentation: Object Detectors — https://docs.frigate.video/configuration/object_detectors/
- Frigate documentation: Video Decoding — https://docs.frigate.video/configuration/hardware_acceleration_video/
- Frigate documentation: Enrichments — https://docs.frigate.video/configuration/hardware_acceleration_enrichments/
- Frigate documentation: Installation — https://docs.frigate.video/frigate/installation/
- Frigate documentation: Advanced Options — https://docs.frigate.video/configuration/advanced/
- Frigate documentation: Full Reference Config — https://docs.frigate.video/configuration/reference/