"0 Detections, Hundreds of Alerts": The Frigate Terminology Trap That Isn't a Bug
I opened my Frigate dashboard one morning and my stomach dropped: 0 detections, hundreds of alerts. My first read was the obvious one — the object detector had fallen over, and Frigate was now firing blind, alerting on raw motion instead of actual objects.
That read was completely wrong. Nothing had broken. The detector was healthy, running OpenVINO inference at ~10 ms per frame the entire time. What had actually happened is that I didn’t understand what the words “Alert” and “Detection” mean in modern Frigate — and once I did, the “outage” evaporated and turned into a five-minute config change.
This is a post about a debugging story with a satisfying anticlimax, and about a genuinely confusing bit of Frigate’s UI vocabulary that trips up a lot of people running 0.14 and later.
Building a Headless AI Workstation: Ubuntu Server + RTX 3060 + Ollama, Zero-Touch from a USB Stick
Several of my homelab projects want a local GPU for inference — running a vision LLM for OCR, offloading work that would otherwise hit a cloud API, keeping a small model resident and fast. So I built a dedicated box for it: a Dell Precision 3640 (i3-10105F, 16 GB) with a Gigabyte RTX 3060 12 GB, running Ubuntu Server and serving a vision model through Ollama.
Two things made this worth writing up. First, the actual GPU-serving setup has a few non-obvious choices (which driver, no CUDA Toolkit, exposing the port safely). Second — the fun part — I made the whole install zero-touch: plug in a USB stick, walk away, and the box comes up on a static IP with SSH pubkey auth ready, no monitor or keyboard ever attached. This post covers both, and both live as reusable docs/scripts in my infra-config repo.
Backing Up a Homelab as Code: Docker Configs to a Private Git Repo, Without Leaking Secrets
If my main Docker host died tomorrow, how fast could I rebuild it? For a long time the honest answer was “slowly, and from memory.” The fix is to treat the box’s configuration as code: every docker-compose.yml, Dockerfile, and config file committed to a private git repo, so reimaging is a git clone and a handful of docker compose up commands.
The trap is that a live Docker tree is a minefield of secrets — .env files, TLS private keys, API tokens hardcoded into compose files — and pushing any of them to GitHub, even a private repo, is a bell you can’t fully un-ring. This post is the repeatable procedure I landed on: what to commit, what to never commit, and the automated checks that keep the second category out.