How to Self-Host Frigate NVR: AI-Powered Security Cameras Without a Cloud Subscription

Use a local filesystem that can sustain continuous writes. Avoid placing active recordings on an unreliable network mount until you have confirmed its disconnect and recovery behavior. Frigate's configuration and database should also be protected by a backup routine.

Estimate storage from measured camera bitrate rather than camera resolution alone. For continuous recording, a practical decimal estimate is:

Storage in GB per day = aggregate recorded bitrate in Mbps × 10.8

For example, insert the measured bitrate of every stream assigned the record role, add them together, and multiply by 10.8. Motion-based or event-based retention uses less storage, but the reduction depends on actual activity and configuration. Measure real disk growth over several representative days before setting a long retention period.

Leave free space for the operating system, database activity, temporary files, exports, and unusually busy periods. Configure storage monitoring instead of relying only on a theoretical estimate.

Prepare and test each camera independently

Do not begin by adding every camera to Frigate. Verify one camera and one stream at a time. This separates camera or network problems from Frigate configuration problems.

On Ubuntu, install ffprobe through the FFmpeg package:

sudo apt update
sudo apt install -y ffmpeg

To avoid placing credentials directly in shell history, read the complete RTSP URL into a temporary shell variable:

read -rsp "RTSP URL: " RTSP_URL
echo
ffprobe -v error -rtsp_transport tcp -show_streams "$RTSP_URL"
unset RTSP_URL

Confirm that the output identifies the expected video stream, codec, resolution, and frame rate. Repeat the test for the detection and recording URLs. Let each stream run in a player long enough to reveal periodic disconnects.

Deploy a security-first Frigate baseline with Docker Compose

The safest installation sequence is to start with one camera, persistent storage, the authenticated interface, and no optional device mappings. After the baseline works, add hardware decoding and a supported detector separately.

1. Create the directory structure

mkdir -p "$HOME/frigate/config"
mkdir -p "$HOME/frigate/storage"
cd "$HOME/frigate"

Do not make these directories world-writable. If Docker later reports a permission error, correct ownership or access for the runtime model you are using rather than applying chmod 777.

2. Create the Compose file

Create compose.yaml with the following baseline. It binds port 8971 to the host loopback address, which means only software on the Frigate host can reach it directly. That is appropriate when the Localtonet client runs on the same host.

services:
  frigate:
    container_name: frigate
    image: ${FRIGATE_IMAGE:-ghcr.io/blakeblackshear/frigate:stable}
    restart: unless-stopped
    stop_grace_period: 30s
    shm_size: "512mb"

    ports:
      - "127.0.0.1:8971:8971"

    environment:
      FRIGATE_RTSP_USER: "${FRIGATE_RTSP_USER}"
      FRIGATE_RTSP_PASSWORD: "${FRIGATE_RTSP_PASSWORD}"

    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./config:/config
      - ./storage:/media/frigate
      - type: tmpfs
        target: /tmp/cache
        tmpfs:
          size: 1000000000

Notice what is not published: port 5000, RTSP restreaming on 8554, and WebRTC on 8555. Add a port only when a documented use case requires it and the surrounding firewall and authentication model are understood.

If trusted LAN devices must access Frigate directly, replace 127.0.0.1 with the Frigate host's specific trusted LAN address. Do not use a broad public bind on a host that is directly reachable from the internet.

3. Store the camera credentials outside the Frigate YAML file

Create a local .env file. The values below are placeholders:

FRIGATE_IMAGE=ghcr.io/blakeblackshear/frigate:stable
FRIGATE_RTSP_USER=frigate_camera_user
FRIGATE_RTSP_PASSWORD=replace_with_camera_password

Restrict access to it:

chmod 600 .env

If the password contains characters with special meaning inside a URL, encode or handle them according to the camera and Frigate documentation. Do not weaken a password merely to make URL parsing easier.

4. Create a minimal Frigate configuration

Create config/config.yml. Replace the camera address and stream paths with values verified during the RTSP test:

mqtt:
  enabled: false

cameras:
  front_door:
    enabled: true
    ffmpeg:
      inputs:
        - path: rtsp://{FRIGATE_RTSP_USER}:{FRIGATE_RTSP_PASSWORD}@CAMERA_IP/detect-stream
          roles:
            - detect
        - path: rtsp://{FRIGATE_RTSP_USER}:{FRIGATE_RTSP_PASSWORD}@CAMERA_IP/record-stream
          roles:
            - record

    detect:
      enabled: true

    record:
      enabled: true

objects:
  track:
    - person
    - car

The path suffixes in this example are descriptive placeholders, not universal RTSP paths. Camera vendors and models use different URL formats. Use only the paths you tested successfully.

This minimal configuration avoids release-sensitive retention and detector options. Once the container is healthy, use the configuration editor and documentation for your selected Frigate release to add retention, snapshots, zones, masks, review settings, semantic search, face recognition, license-plate recognition, or other enrichment features. Those features can require additional configuration, models, hardware, or services and should not be assumed to work merely because Frigate starts.

5. Validate Compose and start Frigate

First ask Docker Compose to render and validate the Compose model:

cd "$HOME/frigate"
sudo docker compose config -q

This validates the Compose structure and variable expansion. It does not prove that every Frigate setting or camera URL is correct. Start the container and inspect the application logs for Frigate-level validation:

sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --tail=200 frigate

Do not rely on fabricated example startup output. The actual logs are the source of truth for your image, hardware, configuration, and camera connections. Resolve configuration errors, permission errors, and stream failures before adding more cameras.

Verify the authenticated interface and complete the first login

Before creating any public tunnel, prove that port 8971 works locally and requires authentication.

Check the local web endpoint

From the Frigate host, request the authenticated interface:

curl -kI https://127.0.0.1:8971/

The -k option is used only for this local test because a local certificate may not be trusted by the command-line client. It is not a recommendation to disable certificate validation generally.

If you bound port 8971 only to loopback and need to use a browser on another trusted computer, create a temporary SSH port forward:

ssh -L 8971:127.0.0.1:8971 your-user@FRIGATE_HOST

While that SSH session is open, visit https://127.0.0.1:8971 in the browser on your computer.

Retrieve the generated initial credentials

On an initial installation, Frigate generates administrator credentials and records the initial password in its startup logs. Review the local logs privately:

sudo docker compose logs frigate | less

Find the initial credential message, sign in through port 8971, and change the password through the authenticated account-management interface. If the selected release presents a different first-login flow, follow that release's login screen and documentation.

Verify the application and camera health

• Confirm the container remains in a running state.
• Review logs for repeated FFmpeg restarts, authentication failures, corrupt frames, or storage errors.
• Confirm the configured camera appears in Frigate.
• Verify that the detection stream is connected.
• Verify that recordings are created under storage.
• Play a recording from beginning to end.
• Restart the container and confirm it returns without manual intervention.
• Reboot the host during a planned test and confirm Docker and Frigate recover.

sudo docker compose restart frigate
sudo docker compose ps
sudo docker compose logs --since=10m frigate
sudo du -sh "$HOME/frigate/storage"

Add hardware acceleration only after the baseline works

Video decoding and object detection should be tuned independently. A supported GPU may decode camera video without serving as the object detector, while another device performs detection. Treat them as separate configuration changes.

After each change, check the Frigate logs and compare host load with docker stats. Do not infer hardware acceleration merely from a low CPU percentage. Confirm that Frigate reports the intended decoder or detector and that camera feeds remain stable.

Configure authenticated remote access with Localtonet

Localtonet exposes a service without requiring inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The Localtonet client on the Frigate host creates an outbound connection to one of our relay servers. The resulting HTTP tunnel provides a public address while the selected client is connected and the tunnel is running.

This tutorial exposes only Frigate's authenticated interface on port 8971. It does not expose the internal interface on port 5000, the RTSP restream on port 8554, or the separate WebRTC transport on port 8555.

For the current dashboard workflow, consult the Localtonet HTTP tunnel documentation. The public hostname is assigned or selected during configuration, so do not assume a fixed domain format.

Test the remote experience instead of assuming it

Run the following tests over a mobile connection rather than your home Wi-Fi:

• Confirm that the public address presents the expected Frigate login page.
• Confirm that invalid credentials do not reveal cameras or settings.
• Open the camera overview and event history.
• Play multiple recordings and download a non-sensitive test clip.
• Test live view in every supported browser and device.
• Check whether the selected view uses a compatible HTTP-delivered mode such as MSE.
• Review Frigate and Localtonet status after closing and reopening the browser.

If the interface and recordings work but live video does not, do not change the tunnel target to port 5000. The likely issue is a media transport, browser codec, go2rtc, or WebRTC path. Port 8555 is a separate TCP and UDP service and is not automatically carried by one HTTP tunnel to port 8971. Keep the authenticated web tunnel intact while diagnosing the media path.

Connect Frigate to MQTT and Home Assistant safely

Frigate can run without Home Assistant and without MQTT. Add MQTT only when you want integrations or automations that consume Frigate events.

The Frigate integration for Home Assistant is installed through HACS. It also requires MQTT to be configured in both Frigate and Home Assistant. The Mosquitto Broker add-on is convenient for Home Assistant OS or a compatible supervised deployment, but add-ons are not available in every Home Assistant installation method. Container and Core installations require an independently managed MQTT broker.

Prepare the MQTT broker

• Create a dedicated MQTT account for Frigate.
• Use a unique password and restrict broker access to trusted networks.
• Do not expose MQTT directly to the public internet for this integration.
• Confirm that Home Assistant is connected to the same broker.
• Verify hostname resolution and firewall access from the Frigate container.

Then replace the disabled MQTT block in config.yml with settings appropriate for your broker:

mqtt:
  enabled: true
  host: MQTT_BROKER_IP
  port: 1883
  user: frigate_mqtt
  password: "{FRIGATE_MQTT_PASSWORD}"

Add the corresponding secret to the container environment rather than writing the actual password in config.yml:

environment:
  FRIGATE_RTSP_USER: "${FRIGATE_RTSP_USER}"
  FRIGATE_RTSP_PASSWORD: "${FRIGATE_RTSP_PASSWORD}"
  FRIGATE_MQTT_PASSWORD: "${FRIGATE_MQTT_PASSWORD}"

Add FRIGATE_MQTT_PASSWORD to the protected .env file, recreate the container, and inspect the logs:

sudo docker compose config -q
sudo docker compose up -d
sudo docker compose logs --since=10m frigate

After MQTT is healthy, install the Frigate integration through HACS and add it in Home Assistant. Keep Home Assistant, the broker, and Frigate on trusted internal networks. The public Frigate URL is not a replacement for the local MQTT connection.

Operate, back up, upgrade, and recover Frigate

Routine checks

A self-hosted NVR needs routine maintenance. Review camera health, container restarts, storage use, time synchronization, and failed logins. Test playback periodically rather than discovering a recording problem after an incident.

cd "$HOME/frigate"

sudo docker compose ps
sudo docker compose logs --since=24h frigate
sudo docker stats --no-stream frigate
df -h "$HOME/frigate/storage"
sudo du -sh "$HOME/frigate/storage"

Check whether every camera is still producing current recordings. A running container alone does not prove that streams are healthy or that media is being retained.

Back up configuration and metadata

The config directory contains configuration and application data that are needed to reconstruct the deployment. For a consistent backup, stop Frigate briefly before archiving it:

cd "$HOME/frigate"

sudo docker compose stop frigate

sudo tar -czf "$HOME/frigate-config-$(date +%F).tar.gz" \
  compose.yaml config

sudo docker compose start frigate

Store the archive on another system and protect it because configuration data may reveal camera addresses, usernames, zones, and operational details. Back up the .env secrets separately using encrypted secret storage. Do not place an unencrypted copy in a general-purpose cloud folder.

Recording backups need a separate policy because media can be large. Decide whether you need all recordings, only exported evidence, or a short replicated window. Test restoration rather than assuming an archive is usable.

Use a controlled upgrade process

The moving stable tag is convenient for an initial deployment but does not create a reproducible rollback point. Before production use, select and pin an exact Frigate release that you have reviewed against the current release notes and hardware documentation.

1. Record the current image tag or digest.
2. Export a consistent backup of config.
3. Read the release notes for configuration migrations and breaking changes.
4. Change the image to the exact target tag.
5. Pull the image and recreate the container.
6. Review startup logs before adding or changing features.
7. Verify authentication, every camera, recordings, playback, detection, MQTT, and remote access.

cd "$HOME/frigate"

sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs --tail=300 frigate

Plan rollback before upgrading

If the new release fails, restore the previous exact image tag. If the upgrade migrated the database or configuration incompatibly, stop the container and restore the matching pre-upgrade backup before starting the older image.

Do not point two Frigate containers at the same writable configuration database or recording directory during a rollback test. That can create conflicting writes and complicate recovery.

Troubleshoot common installation and remote-access problems

Frequently asked questions