We replaced Blue Iris with Frigate because Frigate fitted the way we wanted to run the house. It runs in Docker containers today and can move to Proxmox later, it plugs natively into Home Assistant, it does AI object detection for free, and its config lives in Git. Blue Iris is a Windows application, so keeping it would have meant running and patching a Windows VM, and our perpetual licence only covered updates up to 2023. The switch itself was cheap. The real bill came later, as memory pressure on a single 16 GB host.
This is the CCTV chapter of a week-long smart home build we did with Claude Code as the engineering agent, which started on the night of 23/24 September 2026. The wider story is in Home Assistant with Claude Code: A Full Smart Home in a Week. This piece sticks to the cameras: the decision, the setup, the stall that nearly made us doubt it, and what we would change if we did it again.
The starting point: a Windows NVR in a container-shaped house
The house had three IP cameras feeding a legacy Blue Iris install. Everything else on the plan was going into Docker Compose on a Mac mini-class desktop with 16 GB of RAM and an 8 GB Docker VM: Home Assistant, Mosquitto, Zigbee2MQTT, Z-Wave JS UI and a local voice stack. The next step after that is a move to Proxmox on two small-form-factor, NUC-class PCs. We set one rule for every component. The compose files had to move to Proxmox by copying a folder and flipping a few settings.
Blue Iris is a mature NVR, and on a dedicated Windows machine it does its job. It didn’t fit that rule, though. A Windows VM is one more operating system to license, patch, back up and watch, and it would have been the only thing in the stack not described by a text file. Our licence situation sealed it. With updates covered only to 2023, staying meant either paying again or running ageing software that faces the network. So on the first night the agent audited the legacy CCTV, and we decided to replace it.
The same build-or-buy question comes up in any business putting in operational systems. Our guide on custom software vs off the shelf for Irish SMEs covers the general version. Here the answer was a third option: open-source software that someone else maintains, configured as code.
Why Frigate won the Blue Iris vs Frigate decision for us
Four reasons mattered, roughly in this order. First, Frigate is built to run in containers, so it slotted into the same compose layout as everything else and moves to Proxmox unchanged. Second, it integrates natively with Home Assistant. Cameras, detections and review events become things automations can react to, with no glue code in between. Third, object detection is free and runs locally, so there is no subscription and no footage leaves the building to be analysed. Fourth, the whole configuration is one YAML file that goes into Git next to the rest of the house. That means it can be reviewed, diffed and rolled back.
Before anything was written, research agents checked the specifics against official docs and source repos. Three ran in parallel that night. One of them verified the Frigate 0.18 config keys and the quirks of Docker CIFS volumes, which mattered because recordings were going to a NAS. That step paid for itself. Frigate rejects unknown config keys, so config pasted from an older tutorial gets you a container that refuses to start. The reference config for the version you are actually running is the only safe source.
Getting Frigate running in Docker
The stack was written overnight. Then an independent review pass went through it and found 9 defects. One of them was directly in our path: Home Assistant camera streams were returning 401. All 9 were fixed and re-tested before morning. At about 06:13 the human on the project ran the deploy script and 7 containers came up. That script generates its own MQTT, restream and Zigbee keys locally, so no credentials ever passed through the agent. Frigate went live on all three cameras on 26 September, once HTTPS through our internal CA was in place.
Detect on the sub-stream, record the main stream
The most useful config decision was to separate detection from recording. Detection runs on each camera’s low-resolution sub-stream at 640×360 and 6 fps, and only the main streams are recorded. A detector doesn’t need full resolution to spot a person crossing a driveway. Decoding three full-resolution streams just to feed it would have burned CPU on a host that already had plenty to do. The agent changed the stream settings through the cameras’ own HTTP APIs, and while it was there we cut recording bitrates by 59%.
We also chose not to record around the clock. Footage is motion-only and kept for about a week. Recordings go to the NAS, but Frigate’s SQLite database stays on local disk, because SQLite must never sit on an SMB share. This split is easy to get wrong if you mount one large network volume and point everything at it. The database will appear to work until the share hiccups.
Detection rules that came from real behaviour
We didn’t design the alerting rules on day one. They came from watching what the system did. Pets are recorded but never trigger alerts. A parked object that never moves creates no saved event, which is by design. Then one night a stationary object was read as a “person” for 80 minutes. That gave us the rule that matters most: automations react only to moving people. A misclassified bin or coat is annoying in the review timeline and unacceptable as a 3am notification.
A local vision model to describe what it saw
Frigate can hand event snapshots to a generative model for a written description. Ours go to Qwen2.5-VL-32B on a separate local GPU box, so no cloud is involved. Frigate’s chat feature needed a second model, Qwen3-30B, because the vision model has no tool calling. For a business this split is worth knowing about in advance. If you want both image descriptions and a chat interface over your footage, you are running two models, not one.
What broke: the stall that wasn’t Frigate’s fault
On 27 September Frigate stalled. Detection crawled along at 0.1 fps. Our first suspect was the GenAI description calls blocking the pipeline. That was wrong. The root cause was memory. The 8 GB Docker VM had about 83 MB free, swap was 100% full, and the load average was 80 on 10 CPUs. The biggest memory users were Frigate’s semantic-search model at 891 MB and several unrelated stacks sharing the same host.
Turning semantic search off took the load from 80 to 1.5. The obvious next move would have been to give Docker 12 GB, but the host itself was already swapping 21.7 GB, so there was nothing to give. The stalls came back once more, until we retired a separate English speech-to-text model from the voice stack. After that the VM had 783 MB available, up from 485 MB. That is enough to run on, and not enough to feel comfortable. The real fix is the move to Proxmox plus stopping stacks that don’t need to run.
The worst symptom was a quiet one. For about 18 hours Frigate stopped creating events while detection still looked fine. Nothing errored and nothing alerted. The CCTV simply stopped recording anything worth reviewing. We cover this class of problem in AI automation challenges to plan for before you build, and CCTV is a sharp example of it. A dashboard that only shows detection fps will tell you everything is fine while the thing you actually care about has stopped.
699 dropouts that were really a host problem
The weekly AI health report we built later flagged 699 camera “dropouts” over 7 days. That looks like failing cameras or bad Wi-Fi. When we traced it, every one came from the memory crisis and the restarts it caused. The cameras were healthy throughout. When a monitoring signal blames the camera, check the host first.
One more lesson came from a config mistake. Configs are now validated inside the container before every restart, so a typo gets rejected before Frigate goes down, not after.
Frigate and Home Assistant: alerts that carry the picture
The payoff of the native integration is the phone alert. A Frigate review event triggers a push notification with a snapshot and a clip attached, so you can decide in two seconds whether it matters. We built it as a script, not a notify group, because notify groups drop the images and the action buttons. The alert rules sit on top of the detection rules: moving people only, pets never. CCTV in the Home Assistant world is just another sensor. That is the real argument for Frigate over a standalone NVR. Camera events can drive lighting, presence and anything else in the house, using the same automation tools as everything else.
What it cost
In licence fees, nothing. Frigate is free, and we no longer carry a Windows VM. The image descriptions run on our own local GPU box, so there is no per-call cloud bill for them. We can’t give you a clean hours figure for the CCTV on its own, because it was one strand of a week that also covered radios, voice, lighting and backups.
The real cost was memory and attention: an evening chasing the wrong suspect, a feature switched off, a voice model retired to free headroom, and the conclusion that one 16 GB Docker Desktop host is the bottleneck. That conclusion is what drives the move to Proxmox, where detection can be accelerated on the iGPU and the cameras won’t compete for memory with everything else on the box.
What we would do differently
Most of the changes come down to checking things earlier, before they had a chance to bite:
- Size the host for detection, models and every other stack on it before the first camera goes live, and start with semantic search off until you can see the headroom.
- Put the SQLite database on local disk and recordings on the NAS from day one, and wrap every NAS access in a timeout.
- Monitor event creation, not just detection fps, because a stalled pipeline can look healthy.
- Validate the config in the container before every restart.
- Write “moving objects only” into the alert rules from the start.
If we were buying hardware fresh, we would put Frigate on a Linux host with an iGPU straight away and skip Docker Desktop for anything camera-heavy. Docker Desktop got us running in a night, and that was worth a lot. It is also where every memory problem we had came from.
This week: run one camera’s sub-stream through Frigate
Don’t rip out your current NVR. Pick one camera, find its sub-stream URL, and check how much free memory the host you plan to use actually has, not what the spec sheet says. Run Frigate in Docker with detection on that sub-stream only and recording off, alongside your existing system, for a week. Keep docker stats open under load, and keep a note of everything Frigate calls a person. That note becomes your alert rules, and the memory figure tells you whether your host can take the other cameras.
D3X Solutions LABS is an AI engineering studio in Ireland. This is the kind of work we do: local AI detection, agent-built and reviewed config, and the operational plumbing that keeps it honest, such as validation, health reporting and backups that are checked rather than assumed. We start by looking at what you already run and where its limits are, then decide what goes local, what goes in containers and what stays as it is. For the wider business view, our piece on practical AI for mid-sized companies is a good companion. If you are weighing a CCTV or AI vision project for a home office, shop or site, book a free 30-minute call and we’ll work through your cameras, your hardware and the first sensible step together.
Frequently Asked Questions
Is Frigate a good replacement for Blue Iris?
It depends on how you run your infrastructure. Frigate suits a container- or Linux-based setup, integrates natively with Home Assistant, does free local object detection and keeps its config in a Git-friendly YAML file. If you already run a dedicated Windows machine and don't use Home Assistant, Blue Iris may still fit you better.
Can Frigate run in Docker on a Mac?
Yes, we ran it in Docker Desktop on a Mac mini-class host with an 8 GB Docker VM. It worked, but memory was the limiting factor: with other stacks on the same host, Frigate stalled until we switched off semantic search and freed memory elsewhere. For a camera-heavy setup, a Linux host with an iGPU is a better long-term home.
How do I reduce Frigate CPU and memory usage?
Run detection on each camera's low-resolution sub-stream (we use 640×360 at 6 fps) and record only the main stream. Turn off features you don't need yet, such as semantic search, which used 891 MB on our host. Also check what else is running on the same machine, because that was half of our memory problem.
Does Frigate integrate with Home Assistant?
Yes, Frigate has a native Home Assistant integration, so detections and review events can trigger automations directly. We use it to send phone push notifications with a snapshot and clip, built as a script because notify groups drop images and action buttons.
Can Frigate store recordings on a NAS?
Yes, but keep Frigate's SQLite database on local disk and send only the recordings to the NAS, because SQLite must not sit on an SMB share. Wrap any NAS access in a timeout too, since network shares can hang.
Do I need a cloud AI service for Frigate object detection?
No. Object detection runs locally in Frigate at no cost. If you also want written descriptions of events, you can point Frigate at a local vision model, as we did with Qwen2.5-VL-32B on a local GPU box, so no footage leaves the building.
Want this working in your business?
D3X Solutions LABS builds AI agents and automation that pay back fast. Book a free 30-minute call and we will look at where AI would pay back first in your workflow.
Get in touch
