Frigate Running in Docker inside LXC on Proxmox

nospam@example.com (Raymond P. Burkholder) — Tue, 28 Apr 2026 01:58:50 +0000

Once all the GPU and Docker prerequisites are in place, installing frigate-nve is easy: a) build a yaml file, b) docker compose the file.

In the LXC container, create a frigate directory and move into it:

mkdir frigate
cd frigate

In that directory, here is the content of my docker-compose-yaml file:

services:
  frigate:
    container_name: frigate
    #privileged: true # this may not be necessary for all setups
    restart: unless-stopped
    stop_grace_period: 30s # allow enough time to shut down the various services
    image: ghcr.io/blakeblackshear/frigate:stable
    shm_size: "1512mb" # updated for my camera list based upon error messages in the log
#    devices:
#      - /dev/dri/renderD128:/dev/dri/renderD128 # AMD / Intel GPU, needs to be updated for your hardware
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              #device_ids: ['0'] # this is only needed when using multiple GPUs
              count: 1 # number of GPUs
              capabilities: [gpu]
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /root/frigate/config:/config
      - /root/frigate/storage:/media/frigate
      - type: tmpfs # 1GB In-memory filesystem for recording segment storage
        target: /tmp/cache
        tmpfs:
          size: 1000000000
    ports:
      - "8971:8971"
      # - "5000:5000" # Internal unauthenticated access. Expose carefully.
      - "8554:8554" # RTSP feeds
      - "8555:8555/tcp" # WebRTC over tcp
      - "8555:8555/udp" # WebRTC over udp
    environment:
      FRIGATE_RTSP_PASSWORD: "xxxxxxx"

Get it started:

# in a foreground process:
docker compose up
# or, as a background process:
docker compose up -d frigate

The login should be seen at something like (or your container's address):

https://127.0.0.1:8971/

Official installation documentation:

Frigage NVR Installation

Docker Notes

nospam@example.com (Raymond P. Burkholder) — Sun, 05 Apr 2026 00:26:37 +0000

Images vs Containers

Docker Image: blueprint with app code and dependencies - static, read-only
Docker Container: running instance of an image - dynamic, executable

Each instruction in the Dockerfile adds an extra layer to the Docker image. Minimize the number of layers by consolidating the instructions to increase the build’s performance and time.

Avoid using multiple RUN commands as it creates multiple cacheable layers which will affect the efficiency of the build process.

Use a single process per container: Each container should run a single process. This makes it easier to manage and monitor containers and helps to keep containers lightweight.

Images can exist without containers, whereas a container needs an image to run. We can create multiple containers from the same image, each with its own unique data and state

Docker commands

Docker Run: It used for launching the containers from images, with specifying the runtime options and commands.
Docker Pull: It fetches the container images from the container registry like Docker Hub to the local machine.
Docker ps: It helps in displaying the running containers along with their important information like container ID, image used and status.
Docker Stop: It helps in halting the running containers gracefully shutting down the processes within them.
Docker Start: It helps in restarting the stopped containers, resuming their operations from the previous state.
Docker Login: It helps to login in to the docker registry enabling the access to private repositories.

Docker network commands:

docker network ls
docker network inspect

Docker image commands:

docker image ls -a
docker container ls -a

Documentation

Dockerfile reference - examples
Dockerfile overview - with example
Command Line Completion
Base images - includes building from scratch
CLI Cheat Sheet
tutorial

Raymond P. Burkholder - Things I Do - Docker

Frigate Running in Docker inside LXC on Proxmox

Docker Notes