Media Servers guide
Frigate Docker Compose Setup: Cameras, Detectors, and Storage That Last
Deploy Frigate with durable recordings, deliberate camera and detector choices, safe ports, backups, and a reversible update path.
Published and reviewed by OpenAlt · September 28, 2026
OpenAlt Organization
Verdict
Use Docker Compose with one camera first, durable storage, and a pinned Frigate image. Treat video decoding and object detection as separate workloads: decoding handles turning camera video into usable frames, while detection analyzes selected frames for objects. A GPU or integrated graphics device may help with decoding without improving detection, and a TPU or detector runtime may accelerate detection without decoding video.
As of September 28, 2026, blakeblackshear/frigate has 36,147 GitHub stars, is MIT-licensed, and lists v0.18.0, released September 12, 2026. Frigate’s official documentation recommends Docker Compose for deployment. The current UI uses HTTPS on port 8971; RTSP restreaming uses 8554, and WebRTC uses 8555 over TCP and UDP. Read the official installation and update documentation.
Table of contents
- Hardware decision
- Directories and storage
- Compose baseline
- Camera wizard and first stream
- Decode versus detector acceleration
- Security
- Retention and capacity
- Backup, restore, update, and rollback
- Troubleshooting
- FAQ
Hardware decision
| Goal | Suitable starting point | What it solves | Important limitation |
|---|---|---|---|
| Run one camera reliably | Modern CPU, SSD, adequate RAM | Frigate, recording, and basic detection | Detection load rises with cameras and frame rate |
| Decode camera video | Intel or AMD iGPU, or supported NVIDIA GPU | H.264/H.265 video decoding | Does not automatically accelerate object detection |
| Accelerate detection | OpenVINO CPU, supported GPU, Coral, Hailo, or another documented detector | Object inference | Compatibility and model support vary |
| Store recordings | Dedicated HDD, SSD, NAS, or mounted volume | Durable media retention | Capacity depends on bitrate and retention days |
| Reduce detection workload | Camera substream for detection | Fewer pixels and lower decode cost | The main stream should remain available for recording |
Start with the hardware you already have. Frigate’s getting-started guide documents OpenVINO CPU as a default detector option and provides device-specific acceleration guidance. Do not assume that a result from one camera, model, or accelerator predicts performance for another. Use the official getting-started guide for supported detector configurations.
Directories and storage
Keep configuration and media on separate durable paths:
/configstores Frigate configuration, the database, and related application state./media/frigatestores recordings, clips, snapshots, and exports./tmp/cacheis appropriate for temporary cache data and may be a tmpfs mount.
Do not put recordings on a small boot partition or a temporary filesystem. A database backup is useful, but it cannot replace the video files. Confirm that the Docker user can write to both mounted directories, and monitor free space and inode usage.
Camera footage may contain identifiable people, vehicles, or private activity. That can create privacy, notice, retention, access, or disclosure obligations depending on your location and use. Establish an appropriate policy before recording shared or public areas; this is an operational consideration, not a legal conclusion.
Compose baseline
This baseline pins Frigate to v0.18.0 and avoids publishing port 5000. Add hardware-specific devices only after the CPU-only deployment is recording correctly.
services:
frigate:
container_name: frigate
image: ghcr.io/blakeblackshear/frigate:0.18.0
restart: unless-stopped
privileged: true
shm_size: "512mb"
volumes:
- /etc/localtime:/etc/localtime:ro
- ./frigate/config:/config
- ./frigate/storage:/media/frigate
- type: tmpfs
target: /tmp/cache
tmpfs:
size: 1000000000
ports:
- "8971:8971"
- "8554:8554"
- "8555:8555/tcp"
- "8555:8555/udp"
Open https://your-frigate-host:8971 after starting the stack. A self-signed certificate warning can be expected on a fresh installation. Pinning a version makes upgrades deliberate and rollback possible. The official installation page documents the Compose layout and storage paths.
Camera wizard and first stream
Create the Frigate administrator account, then use the camera wizard to add one camera. Use the camera’s lower-resolution substream for detection when available, and reserve the main stream for recording. Confirm the RTSP username, password, hostname, port, and path exactly as supplied by the camera.
Enable recording, wait long enough to create a real segment, and verify that the timeline contains playable footage. Check that the recording directory grows, that playback works after a container restart, and that retention removes old material as expected. Only after this succeeds should you add more cameras, restreams, high-resolution detection, or hardware accelerators.
Keep the RTSP password out of committed Compose and configuration files when possible. Use an untracked local environment file or another secret-management method, and protect backups because they may contain the same credential.
Decode versus detector acceleration
Video decoding and object detection should be configured and tested independently.
For hardware decoding, expose the relevant device and configure the corresponding FFmpeg preset documented for that hardware. An Intel or AMD render device commonly appears under /dev/dri; an NVIDIA setup requires its supported container runtime and device configuration. If the device is not visible inside the container, decoding acceleration is not active.
For detection, begin with the documented CPU option:
detectors:
openvino:
type: openvino
device: CPU
A detector accelerator may reduce inference time while leaving video decoding unchanged. Conversely, hardware decoding may reduce CPU use while object inference remains CPU-bound. Measure both workloads separately: watch CPU usage and stream stability for decoding, then inspect detection latency and missed or delayed events for inference. Consult the official getting-started guidance before selecting a device-specific detector.
Security
Port 5000 is an internal, unauthenticated path. Do not publish it to the LAN or internet casually. Prefer the authenticated HTTPS UI on 8971, a VPN, or a carefully configured reverse proxy. If a reverse proxy runs on the same host, bind the host-side UI port to loopback and expose only the proxy.
Restrict RTSP restreaming and WebRTC ports to networks that need them. Use strong, unique camera credentials, avoid putting passwords in shell history, and do not expose camera administration interfaces through broad port forwarding. Review who can view recordings and exports.
Retention and capacity
A practical estimate for continuous recording is:
daily storage in GB ≈ total bitrate in Mbps × 10.8
Multiply by the number of retention days, then add roughly 15% for filesystem overhead, database data, snapshots, and operational headroom. For example, one 4 Mbps stream kept for seven days needs about 302 GB before overhead, or approximately 348 GB with headroom.
Variable bitrate cameras can exceed their nominal average during motion. Measure actual disk growth for at least a full day before finalizing capacity. Event-only recording reduces storage but changes what you can review later. Set retention separately for recordings, detections, snapshots, and clips where appropriate.
Backup, restore, update, and rollback
Back up /config, especially the main configuration and Frigate database, and back up important media separately. For a consistent database backup, stop Frigate briefly or follow a database-safe procedure. Test restoring to a separate directory; an untested backup is only an assumption.
Before upgrading, copy the configuration and record the current image tag. Update one version at a time, review migration notes, and confirm that cameras, recordings, detections, and hardware devices still work. Keep the previous image tag available for rollback, but restore the matching configuration and database snapshot when necessary. Use Frigate’s official updating guidance for version-specific migration details.
Troubleshooting
- Bus error or container crash: Increase
shm_size; multiple FFmpeg processes and high-resolution streams can exhaust shared memory. Reduce camera frame sizes or stream count while testing. - Hardware device error: Confirm that the host device exists, the container mapping is correct, and the required runtime or permissions are present. Remove optional acceleration until the CPU path works.
- RTSP connection failure: Check DNS, reachability, credentials, stream path, camera limits, and whether the camera requires TCP transport. Test the low-resolution substream first.
- Playback or recording gaps: Check disk space, mount permissions, camera stability, clock synchronization, and whether the stream’s codec is supported.
- WebRTC failure: Confirm both TCP and UDP 8555 exposure where required, and check firewall or proxy handling.
- Unexpected retention: Verify the active configuration, timezone, recording mode, and available disk space. Configuration changes do not repair already-corrupted media.
For related Docker guidance, see Home Assistant Docker Compose, Frigate resources, and Monitoring.
FAQ
Should I use a Coral TPU immediately?
No. Start with one verified camera and the documented CPU detector. Add a TPU or another accelerator when measured inference latency, CPU usage, or camera count justifies it.
Does an iGPU replace a detector?
No. An iGPU can accelerate video decoding, but object detection is a separate workload. Configure and measure each independently.
Can recordings live on tmpfs?
No for durable retention. Tmpfs is volatile and consumes RAM. Use it for temporary cache only; keep /media/frigate on persistent storage.
Is exposing port 5000 safe?
Treat it as unsafe for routine network exposure because it is an internal unauthenticated path. Use the authenticated HTTPS UI on 8971, preferably behind a VPN or controlled reverse proxy.