Frigate on Proxmox: Hardware & Passthrough Guide

Frigate virtualization planning

Frigate can run in a virtualized environment, but the hardware path is less forgiving than a generic web application because video decoding and AI detection often depend on direct device access. Current Frigate installation guidance says running in a VM is not the recommended path, while noting that Proxmox users have had success; it also points users toward a QEMU VM rather than treating nested Docker in LXC as the simple default. This guide keeps suitable hosts, SSDs, NICs and UPS options near the top, then walks through passthrough and storage decisions that should be proven before migrating a working NVR.

See live hardware Size my workload

Quick answer

What this Frigate workload needs

If you choose Proxmox, use a QEMU VM as the clean planning baseline, reserve enough CPU and RAM, and design GPU/iGPU or accelerator passthrough before buying the host. Disable memory ballooning when the passthrough design requires stable pinned resources, keep Frigate recording storage explicit, and test one camera plus hardware decoding before scaling the VM.

Live Amazon hardware

Current products that fit this decision

Compare current Amazon listings relevant to this guide. Product availability and prices can change.

Checking the dedicated Frigate Storage catalogue…

Buying decision

Match the hardware to the bottleneck

Virtualization is valuable when you need isolation and consolidation, but it should not add three layers of complexity just to save one physical box. Choose Proxmox when the server already has a reason to be a hypervisor and the required video/detector devices can be passed through cleanly. Otherwise a dedicated Docker host is often simpler.

Interactive decision tool

Frigate Proxmox Resource Planner

Use the workload inputs to size a practical Frigate hardware tier before comparing live products. Results are planning guidance; verify current Frigate support, camera bitrates and the exact hardware configuration before deployment.

Compatibility checklist

Four checks before you purchase

Keep live products near the decision

Current Amazon listings appear above the long guide so capacity, interfaces and prices can be checked before deep reading.

Measure the real workload

Use camera bitrate, retention, PoE draw and network aggregation instead of relying on fixed per-camera rules.

Separate application and recording storage

Keep the Frigate configuration/database role distinct from bulk video retention so each storage tier can be sized correctly.

Verify the complete data path

Camera, switch, NVR, storage and UPS are one recording system; a weak link anywhere can affect reliability.

Treat the hypervisor as part of the NVR hardware path

A Proxmox build adds firmware, IOMMU grouping, device passthrough and virtual networking between the physical hardware and Frigate. Verify those layers before assuming a mini PC or server that works bare metal will work identically in a VM. The most important purchase decision is often not CPU benchmark score but whether the iGPU, discrete GPU or AI accelerator can be exposed cleanly to the Frigate guest.

Use a QEMU VM as the documented planning baseline

Frigate installation guidance references Proxmox documentation that recommends application containers such as Frigate run inside a QEMU VM. This provides stronger isolation while avoiding some of the complexity of running Docker inside LXC. It does add a virtualization layer, so reserve resources deliberately and make sure device passthrough is supported by the host motherboard, BIOS and Proxmox configuration.

LXC is possible but not Frigate's simple supported path

Frigate explicitly warns that LXC setup can be complex and says running inside LXC is not officially supported. Nested Docker, /dev/dri mappings and accelerator devices can work for experienced administrators, but every extra permission and cgroup layer increases troubleshooting surface. Do not choose LXC only because it uses less overhead if a QEMU VM makes the device boundary easier to understand and maintain.

Disable ballooning when GPU passthrough depends on stable memory

Frigate's Proxmox guidance specifically calls out disabling ballooning, especially when passing a GPU to the VM. A recorder should have predictable resources during busy camera periods. Assign memory based on camera count and enrichments, then leave host headroom for ZFS, other VMs and the hypervisor. Oversubscribing RAM may look efficient until multiple services become busy at once.

Plan iGPU or GPU passthrough before purchasing the CPU

Intel hardware decoding is attractive for Frigate, but an iGPU used by the Proxmox host may require specific passthrough or mediated-device strategies. Discrete GPUs can be cleaner but consume more power and PCIe resources. Decide whether the same device is needed by other VMs. A host with the right CPU but awkward IOMMU groups may be a worse Frigate platform than a slightly slower system with straightforward device isolation.

AI accelerator passthrough needs its own interface plan

USB Coral, M.2 accelerators and PCIe devices each present different passthrough requirements. An M.2 slot used for an SSD cannot simultaneously hold an accelerator, and small hosts may route multiple devices behind one IOMMU group. Choose the detector architecture before buying expansion hardware. Test the device inside the guest using the same driver and Frigate version intended for production.

Separate VM boot, database and recording storage logically

The Proxmox host may use ZFS or another pool for VM disks while Frigate recordings live on a separate local volume or passed-through storage. Avoid hiding all video inside a thin virtual disk whose capacity management is hard to observe. Keep the /config database on reliable low-latency storage and make the recording path large, explicit and easy to monitor from both guest and host.

Avoid double redundancy without understanding the cost

A ZFS mirror under a virtual disk plus another RAID layer inside the guest can waste capacity and complicate recovery. Pick one layer that owns physical-disk redundancy. For simple Frigate storage, passing a dedicated dataset or disk arrangement to the VM is easier to reason about than stacking filesystems and RAID abstractions that each believe they control failure handling.

Virtual networking rarely needs exotic design

A bridged virtio network interface is enough for many Frigate VMs. VLAN tags can isolate camera traffic while the physical switch handles PoE. 2.5GbE or 10GbE is useful only when aggregate camera, NAS and server traffic requires it. Measure the data path and avoid turning the hypervisor into an unnecessary router unless the architecture calls for that role.

Reserve CPU instead of counting only vCPUs

Four vCPUs on a heavily oversubscribed hypervisor are not equivalent to four dedicated cores during a busy event. Hardware decoding reduces CPU pressure, but the VM still needs predictable scheduling for FFmpeg, database work and enrichments. Monitor host steal/wait conditions and keep enough real compute capacity for the NVR even when other VMs perform backups or maintenance.

Proxmox snapshots are not a backup of camera footage

VM snapshots can be useful before upgrades, but they do not protect the physical host, recording disk or evidence from deletion. Treat Frigate configuration backups, important exported clips and rolling NVR recordings separately. Keep snapshots short-lived when they affect storage performance and ensure the backup system understands the size and churn of the data it is protecting.

Validate a single camera before migrating the full NVR

Pass through the intended video and detector devices, add one camera, confirm hardware decoding, record to the final storage path, and watch resource usage. Only then migrate the rest of the cameras. This staged approach reveals passthrough, permissions and network problems before the hypervisor becomes responsible for an entire security system.

Questions people ask

Frigate on Proxmox Hardware FAQs

Is Proxmox recommended for Frigate?

Frigate says running in a VM is not the recommended path, though Proxmox users have had success. Docker on a dedicated host remains simpler.

Should I use a Proxmox VM or LXC for Frigate?

Frigate documentation points to a QEMU VM as the cleaner Proxmox application-container approach and warns that LXC can be complex and is not officially supported.

Can I pass an Intel iGPU to Frigate on Proxmox?

It is possible on supported hardware, but the exact passthrough method depends on the platform and Proxmox setup. Verify before buying the host.

Should memory ballooning be enabled?

Frigate's Proxmox guidance says ballooning should be disabled, especially when passing a GPU to the VM.

How much RAM should a Frigate Proxmox VM have?

Size it from camera count, enrichments and other services, then leave host headroom. 8 to 16 GB is a practical range for many systems, but heavier workloads need more.

Where should Frigate recordings live on Proxmox?

Use a deliberately sized storage path with clear capacity and performance. Avoid hiding large rolling video inside a small or opaque VM disk.

Can I use a USB Coral through Proxmox?

USB passthrough can work, but device reset and virtualization behavior should be tested with the exact host and Frigate version.

Do I need 10GbE for a Frigate VM?

Usually not for cameras alone. It becomes relevant when the hypervisor also moves large NAS, backup or other server traffic.

Are Proxmox snapshots enough to back up Frigate?

No. They do not replace backups of configuration, important clips or protection from physical storage failure.

What should I test before moving Frigate into Proxmox?

Confirm hardware decoding, detector passthrough, storage writes, networking and clean container restart with one camera before migrating the full system.

Official references and methodology

Verify current Frigate support before deployment