# Frigate NVR skips detection where nothing moves, and runs as a container pair

> Frigate NVR is a local network video recorder that runs object detection on IP camera feeds with OpenCV and TensorFlow, built around Home Assistant. Its design trade is explicit: cheap motion detection first, expensive detection only where it fires. Getting it running means a container, a broker on port 1883, and a group ID mismatch waiting in the devcontainer compose file.

**blakeblackshear/frigate** — NVR with realtime local object detection for IP cameras. Frigate NVR - Realtime Object Detection for IP Cameras \[English\] | 简体中文 A complete and local NVR designed for Home Assistant with AI object detection.

- Repository: https://github.com/blakeblackshear/frigate
- Website: https://frigate.video
- Stars: 36,178 · Forks: 3,643
- Language: TypeScript
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/blakeblackshear-frigate

## Motion detection runs first so TensorFlow does not run on every frame

The core design choice is a two-stage pipeline. A low overhead motion detector decides where anything changed, and TensorFlow object detection runs in separate processes only on those regions. The stated goal is to look for objects when and where it is necessary rather than analysing every frame, and the project leans on multiprocessing to keep framerate up rather than processing everything. The detector runs OpenCV and TensorFlow locally on the camera feed, so nothing about the video leaves the machine unless you configure it to.

This is the difference between Frigate and a plain recorder, and it is also its cost. A region that never trips motion detection never gets classified, so a slow or still object can sit in a zone without ever producing an event. Retention is tied to what is detected, which means the thing you want to keep and the thing the detector noticed are not always the same clip.

## The run target publishes 5000 and 8971 and nothing else

There is no install script in this repository. The documentation lives at docs.frigate.video, and the repo hands you a Makefile that builds the image and runs it. The `local` target builds a `frigate:latest` tag, and `run` starts that image with two published ports and a config volume:

```bash
docker run --rm --publish=5000:5000 --publish=8971:8971 \
	--volume=${PWD}/config:/config frigate:latest
```

Nothing else is mapped. There is no HTTPS, no authentication flag, and no reverse proxy in the command, so exposing this to a network is a decision you make outside the Makefile. A reverse proxy in front of it is the normal answer, and that proxy becomes your entire security boundary.

## The compose file runs its own broker with no-auth mode enabled

Alongside the main service, docker-compose.yml defines a service named `mqtt` using the image `eclipse-mosquitto:2.0`, publishing port 1883 and starting the broker with `mosquitto -c /mosquitto-no-auth.conf`, a comment in the file describing it as no-auth mode. Frigate talks over MQTT so it can push into other systems, and for a local development setup a broker without authentication is the fast path.

The consequence is a plain TCP listener on 1883 with no credentials. That is fine on a loopback interface and wrong on a bridged network, because camera events and any commands flowing through that broker become readable by anything that can reach the port. If you carry this compose file into a shared host, the broker configuration is the first thing to replace.

## Group IDs are hard-coded and OpenVINO fails when they drift

The devcontainer service in docker-compose.yml adds fixed numeric groups to the container:

```yaml
    group_add:
      - "109" # render
      - "110" # render
      - "44"  # video
      - "46"  # plugdev
```

A comment above them tells you to check the host's actual IDs with `getent group render`, `getent group video` and `getent group plugdev`, and states that the exact IDs must appear in group_add or OpenVINO GPU acceleration will fail. The render group appears twice, at 109 and 110, which is a hint that these were copied from a particular machine. On a host where the video group is not 44, the container starts and the acceleration path does not, which is a slow failure to diagnose from application logs alone. Check your own group numbers before you blame the model.

## GPU support is a commented-out block, not a flag

NVIDIA support in the compose file is a commented `deploy` block with a `reservations` section requesting one device with `capabilities: [gpu]`, preceded by a note to uncomment it. There is a separate commented line for mounting `/dev/bus/usb` for a Google Coral USB accelerator, and another for `/dev/dri` with a note that it needs updating for your hardware. The devcontainer also sets `shm_size: "256mb"` and an empty `YOLO_MODELS` environment variable.

Read that as a picture of what accelerator support actually costs here. Each device type is a different commented block, and the `/dev/dri` line explicitly warns that the value has to be edited per machine. Frigate works on CPU, and the project recommends an accelerator because AI accelerators will outperform even the best CPUs with very little overhead, but every hardware path is manual configuration rather than a documented flag.

## Home Assistant lives in a separate repository

Frigate does not ship the Home Assistant integration itself. It points at a custom component in a different repository, frigate-hass-integration, and communicates over MQTT as the general-purpose interface for other systems. Live view goes two ways: RTSP re-streaming to reduce the number of connections your camera has to hold open, and WebRTC with MSE for low-latency viewing.

The re-stream is worth thinking about, because it changes where the load sits. Your camera sees one connection from Frigate instead of one per viewer, and Frigate becomes the thing that must stay up for anyone to watch. The split into a separate integration repository also means version skew is possible, and the README does not say how the two are pinned to each other.

## MIT covers the code, the Frigate name is a separate trademark

The licence section splits code from brand. Source code, configuration files and documentation in the repository are under the MIT License, free to use, modify and distribute with the original copyright notice retained. The Frigate name, the Frigate NVR brand and the logo are trademarks of Frigate, Inc. and are not covered by it, with a separate TRADEMARK.md setting out acceptable use. Copyright is held by Frigate, Inc.

For a self-hosted tool that is a mild constraint rather than a blocker. Fork the code and keep the copyright notice, and do not ship a build called Frigate. The repository also carries `web/` for the frontend, `migrations/` for schema changes, `labelmap.txt` and `audio-labelmap.txt` for detector classes, and Python tooling pinned to `target-version = "py311"` under ruff, which tells you the floor for the interpreter.

## Conclusion

Frigate NVR fits a household or small site that wants recorded video, object-filtered retention and Home Assistant events without sending footage to a third party. It does not fit anyone without a spare x86 or arm64 machine to run a container on, and it does not do its own object detection well without a GPU or AI accelerator, which the project calls highly recommended. Before you commit, check three concrete things: whether your camera's RTSP stream survives the re-stream path, whether the ports 5000 and 8971 in the run target are free on your host, and whether the group IDs in docker-compose.yml match what getent reports on your machine, because OpenVINO acceleration fails silently when they do not. The last push to the dev branch was on 2026-09-29, with v0.18.0 published on 2026-09-12 and 0.19.0 already stamped in the Makefile.

## FAQ

### How do I install Frigate NVR?

The repository has no install script. Documentation sits at docs.frigate.video, and the Makefile builds the image from docker/main/Dockerfile with a local target and then runs it, publishing ports 5000 and 8971 with the local config directory mounted at /config.

### How do I run Frigate on Docker?

Use the Makefile: the local target builds a frigate:latest image and the run target starts it with two published ports and a config volume. For Home Assistant, the integration itself is a custom component maintained in the separate frigate-hass-integration repository, and the two communicate over MQTT.

### Does Frigate NVR need a GPU?

The README says use of a GPU or AI accelerator is highly recommended, and that AI accelerators will outperform even the best CPUs with very little overhead. The supported object detectors are documented separately, and the compose file shows GPU support as a commented deploy block rather than a documented flag.

### How do I use Frigate with Home Assistant?

Through a custom component hosted in the separate frigate-hass-integration repository rather than from this repository directly. The two sides talk over MQTT, and Frigate also re-streams over RTSP to reduce connections to the camera, with WebRTC and MSE available for low-latency live view.

### What does Frigate NVR do with the video it records?

Recording runs continuously, and retention settings are based on detected objects, so clips are kept according to what the detector saw rather than uniformly. Detection itself runs locally on the camera feed using OpenCV and TensorFlow, after a low overhead motion pass narrows down where to look.

## Sources

- [Official documentation](https://frigate.video)
- [Official README](https://github.com/blakeblackshear/frigate#readme)
- [Project repository](https://github.com/blakeblackshear/frigate)
- [Release notes](https://github.com/blakeblackshear/frigate/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/blakeblackshear-frigate