Frigate NVR Storage Calculator

Worked examples

These are this calculator’s own outputs, computed with the same formula the tool runs in your browser — so you can see a real answer without touching a single input.

The mainstream starter setup and the tool’s own default state: four 4MP (2560×1440) cameras at 15 fps, H.265, recording continuously 24/7, keeping 14 days

• Inputs: Cameras = 4; Resolution = 4MP (1440p, 2560×1440); Recording FPS = 15; Codec = H.265/HEVC; Record mode = Continuous 24/7; Retention = 14 days; Known bitrate = blank (auto-estimate)
• Result: Total storage needed: 1.9 TB. All cameras/day: 130 GB. Per camera/day: 32 GB (≈ 3.0 Mbps est.). Smallest drive that fits: 2 TB (surveillance-rated HDD (24/7 write) — 95% full; buy 4 TB for real headroom). Set /dev/shm to: 463 MB.

A 4K homelab NVR: six 4K (3840×2160) cameras at 15 fps, H.265, continuous 24/7, keeping a full month (30 days)

• Inputs: Cameras = 6; Resolution = 4K (8MP, 3840×2160); Recording FPS = 15; Codec = H.265/HEVC; Record mode = Continuous 24/7; Retention = 30 days; Known bitrate = blank (auto-estimate)
• Result: Total storage needed: 12.2 TB. All cameras/day: 389 GB. Per camera/day: 65 GB (≈ 6.0 Mbps est.). Smallest drive that fits: 14 TB (surveillance-rated HDD (24/7 write) — 87% full). Set /dev/shm to: 1466 MB.

A budget motion-only build with off-reference frame rate: eight 1080p cameras at 20 fps, H.264, motion/detect-only with activity 25% of the day, keeping 30 days

• Inputs: Cameras = 8; Resolution = 1080p (2MP, 1920×1080); Recording FPS = 20; Codec = H.264; Record mode = Motion / detect only; Active/motion = 25% of day; Retention = 30 days; Known bitrate = blank (auto-estimate)
• Result: Total storage needed: 3.6 TB. All cameras/day: 115 GB. Per camera/day: 14 GB (≈ 5.3 Mbps est.). Smallest drive that fits: 4 TB (any reliable HDD/SSD, because the mode is motion — 91% full; buy 6 TB for real headroom). Set /dev/shm to: 517 MB.

How to use this calculator

Enter how many cameras you run, pick the resolution, frame rate, and codec, choose continuous or motion-only recording, and set how many days of footage you want to keep. The calculator instantly estimates total storage, daily write volume, a recommended drive size, and the /dev/shm value Frigate needs.

If you already know your camera’s bitrate (check its web UI or app), type it into the optional bitrate field — that is the single most accurate input, because Frigate records the stream your camera sends without re-encoding it.

What actually drives Frigate storage

Two numbers decide almost everything:

• Bitrate — the data rate of the recorded stream, in Mbps. Continuous recording at 1 Mbps uses about 10.8 GB/day. Everything else (resolution, FPS, codec) matters only because it changes the bitrate.
• Retention — how many days you keep. Storage is linear: double the days, double the disk.

Because Frigate copies the camera’s stream rather than transcoding it, the codec choice here estimates what your camera would produce on H.264 vs H.265. H.265 (HEVC) is roughly half the bitrate of H.264 at the same quality — the easiest way to halve your storage is to set the camera to H.265, if its hardware and your decoding setup support it.

Continuous vs motion-only

Continuous 24/7 recording is the safe default for security footage — no gaps, nothing missed. Motion/detect-only recording stores far less, proportional to how active the scene is, but a missed detection means missed footage. The comparison table above shows both modes side by side for your exact setup so you can see the trade in real gigabytes before you commit.

Don’t forget /dev/shm

A storage plan that ignores shared memory is how Frigate setups fail on day one. Frigate buffers decoded frames in /dev/shm, and the default container allocation is small. The calculator outputs a recommended shm-size from a per-camera formula — set it on your container (for an LXC or Docker run) so Frigate has room to work, and cross-check it against the stricter one-liner in Frigate’s own install docs. For the host underneath it, an LXC vs VM decision and a solid storage backend round out a reliable NVR build.

A note on the estimates

When you don’t supply a bitrate, the figures come from typical mainstream-IP-camera bitrates by resolution and codec, scaled by frame rate — good enough to size a drive, but not a substitute for your camera’s real number. Storage uses decimal GB/TB (1 TB = 1,000 GB), matching how drives are sold. Always size up: retention you never use is cheap; running out of space mid-incident is not.

Assumptions and sources

• The /dev/shm figure sums a per-camera shared-memory formula across your cameras. Frigate’s installation documentation currently publishes that formula as (width × height × 1.5 × 20 + 270480) / 1048576 MB against the detect resolution - its own worked example, 1280x720 plus 40 MB of logs, prints 66.63 MB. This calculator uses that same ×20 form, but applies it to the recording resolution rather than the detect resolution, because it does not ask you for a detect stream. Detect streams are usually lower-resolution than the recording stream, so the figure here is normally larger than Frigate’s true minimum — it errs toward over-allocating a tmpfs cap, which is the safe direction. If you set detect equal to your recording resolution, it is the minimum rather than a margin. Either way, run Frigate’s own command against your actual detect resolution before you size a container.
• Frigate recording the camera’s existing stream without re-encoding it - the reason bitrate decides everything - is documented in Frigate’s record configuration docs.
• The 10.8 GB/day per 1 Mbps of continuous recording is arithmetic, not an estimate: 1 Mbps x 86,400 seconds / 8 / 1,000.
• Every total on this page - the headline figure, the recommended drive, and the comparison table - includes a +5% allowance on top of the raw recording stream, covering the clips, snapshots and database Frigate writes alongside the recordings. That 5% is a TechFuelHQ working margin, not a Frigate-published figure; the stream-only total is the number shown divided by 1.05.
• The drive card names the smallest common drive size that holds the total, and states how full that leaves it as a percentage of the drive’s raw decimal capacity. Above 90% it also names the next size up, because a formatted drive gives back roughly that much to filesystem reserve and metadata (ext4’s default reserved-block setting alone is 5%), so a 95%-full “fit” is not one. That 90% cut is a TechFuelHQ working threshold, not a vendor figure.
• The default bitrates by resolution and codec (for example ~3 Mbps for a 4MP H.265 stream) are TechFuelHQ working estimates of mainstream IP-camera output, stated so you can override them with your camera’s real bitrate - which is the accuracy lever this page recommends.