Storage for your retention, by codec and record mode

ScenarioBitrate / cameraAll cameras / dayTotal for retention

Storage uses decimal GB/TB (how drives are sold: 1 TB = 1,000 GB), and 1 Mbps recorded continuously = 10.8 GB/day. Frigate records your camera's existing stream — it doesn't re-encode — so the real driver is the camera's configured bitrate. If you know it, enter it for an exact result; otherwise we estimate from resolution, FPS, and codec. The /dev/shm figure uses Frigate's documented per-camera formula (width × height × 1.5 × 9 + 270480) / 1048576 MB. For surveillance HDD sizing, see the budget NAS guide.

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 Frigate’s own per-camera formula — set it on your container (for an LXC or Docker run) so Frigate has room to work. 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.

Frequently asked questions

How much storage does Frigate need per camera?
It depends almost entirely on your camera’s bitrate, not on Frigate. As a rule of thumb, 1 Mbps of continuous recording uses about 10.8 GB per day. A typical 4MP camera at H.265 (~3 Mbps) recording 24/7 uses roughly 32 GB/day; the same camera at H.264 (~6 Mbps) uses about 65 GB/day. Switch the camera to H.265 and you roughly halve the storage. Motion-only recording cuts it further, proportional to how much of the day there is actual activity.
What size hard drive do I need for a 4-camera Frigate setup?
For four 4MP H.265 cameras recording continuously for 14 days, you need roughly 1.8 TB, so a 2 TB drive is the practical minimum and a 4 TB drive gives comfortable headroom. Bump to 4K, longer retention, or H.264 and you climb toward 4–8 TB fast. Use the calculator above with your real camera count, resolution, codec, and retention for an exact figure — and if you know your camera’s actual bitrate, enter it for the most accurate result.
Why does Frigate run out of /dev/shm, and how big should it be?
Frigate uses shared memory (/dev/shm) as a working buffer for decoded camera frames, and the container default (often 64 MB) is too small once you add cameras or higher resolutions. Frigate’s documented per-camera estimate is (width × height × 1.5 × 9 + 270480) / 1048576 MB. The calculator sums this across your cameras and adds a small base — set your container’s shm-size to at least that value to avoid frame-buffer errors.
Does Frigate re-encode video, so does the codec setting matter?
By default Frigate records your camera’s existing stream without re-encoding (it copies it), so the storage you use is determined by the bitrate and codec your camera is already sending. Changing the codec in this calculator estimates what your storage would be if the camera itself were set to H.264 vs H.265 — to actually realize H.265 savings, change the codec in the camera’s own settings, not in Frigate.
How much does motion-only recording save versus continuous?
It scales directly with how much of the day has activity. If your cameras see motion roughly 25% of the day, motion/detect-only recording uses about a quarter of the continuous figure. A low-traffic backyard camera might be 5–10%; a busy street-facing camera could be 40%+. Continuous recording is safest for evidence (no gaps), but motion-only is the biggest single storage lever if disk space is tight.
Do I need a surveillance-rated hard drive (WD Purple / Seagate SkyHawk) for Frigate?
For continuous 24/7 recording, yes — surveillance drives are built for sustained sequential writes and many concurrent camera streams, where a desktop drive can wear out faster. For motion-only setups with light write loads, a good standard NAS or desktop HDD is usually fine. SSDs handle the workload easily but cost more per TB; many homelabbers use an SSD for Frigate’s database/cache and an HDD for the bulk recordings.