Frigate 0.18: what changes if you run or are building a local NVR

Frigate 0.18.0 shipped on September 12: configuration you can edit in the web UI, switchable camera profiles, a chat interface over your own footage, support for three more kinds of accelerator hardware, and breaking config changes everyone upgrading has to walk through. I read the release notes and Frigate’s own documentation to work out what a local house should do about it.

Short version: if you already run Frigate, go straight to 0.18.1, which shipped on October 13 with three security fixes, and treat it as a normal upgrade with a longer than usual to-do list. Back up your config and your database first, because zones, masks, snapshots and the GenAI block all changed shape. If you are buying hardware, two things moved: Nvidia 50 series and RDNA4 AMD cards now work as detectors, and Frigate’s own recommended-hardware page still tells readers to avoid the Beelink EQ14, the box my Frigate build guide shortlists. That last one is the part I would act on today.

Update, October 14, 2026: Frigate 0.18.1 came out on October 13 as a maintenance release with three security fixes, and the Home Assistant Frigate app now packages 0.18.1. I re-read every source below on October 14; the rest of this page still matches them.

What is in the release

What 0.18.1 adds

Frigate calls 0.18.1 “a maintenance release for Frigate 0.18”. It fixes three published security advisories: a camera name collision that could bypass an admin check, how request paths are passed to authentication, and malformed web push subscriptions at startup. It also cuts Intel QSV CPU use on cameras with a high incoming frame rate, fixes semantic search reindexing, and backs off restarts when a recording stream goes stale. If you are on 0.18.0, those security fixes are the reason to move.

The breaking changes to read before you upgrade

The release notes say to back up your config file and make a copy of frigate.db before upgrading. Then walk this list:

• Zones and masks changed format to add enabled and friendly_name fields. A migrator handles it, but the notes say you may need to edit them by hand if migration fails.
• Snapshots are no longer written as annotated JPEGs. Only a clean, unannotated WebP is stored, and snapshots.quality drops from 70 to 60 to match.
• The genai block became a map of providers with roles, as above.
• clean_copy, sync_recordings, timelapse_args, ui.date_format and ui.time_format are gone. Frigate says a config containing clean_copy is migrated automatically.
• FFmpeg moved to version 8 in every image except -rk. That brings a known issue with go2rtc streams that transcode with hardware acceleration, which needs a small go2rtc config change. FFmpeg 5 is deprecated and goes away in 0.19.
• Intel GPU statistics now read the kernel’s per-client DRM counters, which needs Linux kernel 6.5 or newer on the host.
• Running JinaV2 semantic search on a GPU needs an embeddings reindex.
• DELETE on /api/export is gone, replaced by a POST to /api/exports.

Two detectors also changed status. DeGirum is removed, because the company “ceased operations effective 1 Aug 2026”. DeepStack is deprecated and goes in 0.19.

What stays local, and what doesn’t

Frigate’s own description is unchanged: “A complete and local NVR designed for Home Assistant with AI object detection”. Object detection and recording stay on your box in 0.18.

The place the cloud can enter is the GenAI section, and Frigate’s docs are clear about which side each provider sits on. Local providers “run on your own hardware and keep all data processing private”, and the docs name Ollama and llama.cpp; cloud providers run on remote infrastructure, need an API key, and need an internet connection “to send images and prompts for processing”. Chat, object descriptions, review summaries, Remote Embeddings and the new VLM monitoring all run through that provider config. A house that points every role at a local Ollama gets the features without sending frames anywhere, and a house that points them at a hosted provider is sending images and prompts off-site. That is a choice you make in the config, not one the upgrade makes for you.

Frigate’s docs say running these models on a CPU is not recommended, because “high inference times make using Generative AI impractical”. I would plan on a GPU or an accelerator for local GenAI rather than expecting a spare N100 to carry it.

What this changes if you are buying

The detector list is wider than it was:

• Intel integrated GPUs and Arc cards through OpenVINO remain the cheap, common path, and the hardware page lists Intel NPUs alongside them.
• Nvidia now includes the 50 series. The floor is CUDA 12.x, a host driver of 545 or newer, and a GPU with Compute Capability 5.0 or greater.
• AMD discrete GPUs run through ROCm, and 7.2.0 adds RDNA4.
• AXERA sits in the community-supported group with MemryX, Nvidia Jetson, Rockchip RKNN, Synaptics and AMD’s XDNA2 NPUs, and Hailo modules stay in the “Most Hardware” group next to the Coral.
• The Coral is still supported, but the same page says it is “no longer recommended for new Frigate installations” except where power draw or hardware limits force it. My build guide already says that.

The Beelink EQ14 problem

This part is not in the release notes. Frigate’s recommended-hardware page names the Beelink EQ13 as its favorite server, for the N100 and the dual NICs that let you put cameras on an isolated network. My catalog has that box marked discontinued, so Frigate’s top recommendation is something you mostly cannot buy new.

The page then adds a warning: the Beelink EQ14, the N150 successor, “has some known compatibility issues, so you should avoid that model for now”. The warning was still there on October 14. My Frigate build guide and my mini PC guide both shortlist the EQ14. The page does not say what the issues are or when the warning was written, so I cannot tell whether this is current or left over from the N150’s first months. Until that is pinned down, I would not order an EQ14 specifically to run Frigate without checking first, and I would treat another Intel box with an M.2 slot as the safer buy.

Buy, wait or ignore

Home Assistant house already running Frigate. Upgrade to 0.18.1, but not without the config and database backup. Read the breaking-change list first, especially if you have zones, masks, a genai block or go2rtc transcoding. If you run the Home Assistant app rather than a container, the main Frigate apps now offer 0.18.1; the app for old CPUs without AVX is still on 0.14.1.

Home Assistant house building an NVR now. The hardware advice is what moved, not the software. A 50 series Nvidia card or an RDNA4 AMD card is now a working detector, and an Intel iGPU or NPU is still the cheap answer. Check the EQ14 note above before you order a box.

Apple Home or Google Home house. Mostly ignore this one. Frigate is built around Home Assistant and nothing in 0.18 changes that, though Frigate’s docs do describe exporting its cameras to the Apple Home app through its built-in go2rtc, so an Apple Home house is not locked out.

Budget buyer. Nothing to buy. CPU-only detection is documented as not recommended for real use, so a used Intel machine whose iGPU does the work is still the cheap path.

Does this change my picks?

Not the software picks. Frigate stays the local NVR I point people at, and 0.18 adds configurability without moving anything to the cloud by default.

• Frigate NVR build guide. Needs a second look at the EQ14 line, because Frigate’s own hardware page still argues against it. That is a hardware note, not a change to how the guide says to build the thing.
• Best mini PCs for Home Assistant. The same EQ14 question, narrower: that shortlist is for Home Assistant generally, and the warning may not apply to a box that never runs Frigate.
• Beelink EQ13 and Beelink EQ14 catalog pages, neither of which says that Frigate’s documentation tells NVR builders to avoid the EQ14 while still naming the discontinued EQ13 first. Both need that line once I know what the compatibility issues are.