The Raspberry Pi 5 that had been running Frigate died on 2026-08-08. The only other computer in the house that stays on is a Windows 11 desktop, so Frigate moved there, and it has stayed. There is no Windows port; what runs is Ubuntu inside WSL2, Docker inside Ubuntu, and Frigate inside Docker, which sounds like three layers of trouble and in practice is a handful of settings and one boot script. What follows is the shape of that arrangement, what broke the first few times, and the order to do things in. The real wsl.conf, .wslconfig, docker-compose.yml and the boot script are on the setup files page. If you do not yet know what Frigate is for, start there.
Why Windows at all
Less a decision than an inventory. The desktop was already awake and already on the same network as the cameras, and it has more of everything the Pi and its AI hat lacked: six cores and twelve threads to decode ten camera streams, 32 GB of memory, a 3.7 TB drive for clips, and an Intel UHD 630 graphics unit inside the CPU that now does the object detection. Nothing was bought for it, no graphics card, no Coral stick, no cloud plan.
| Part | What it does for Frigate |
|---|---|
| Windows 11 Pro desktop, Intel Core i7-8700 | Decodes ten camera streams on the CPU at 2 to 3 frames a second each. The whole Linux side, decoders included, was 13.6 % of the machine in the 2026-09-03 capture. |
| Intel UHD Graphics 630 (inside the CPU) | Runs the cat detector through OpenVINO, about 12 ms per look. How. |
| WSL2 with Ubuntu, systemd turned on | The small Linux that Frigate lives in. |
| Docker Engine, installed inside Ubuntu | Runs the Frigate container. Not Docker Desktop. |
| D: drive, 3.7 TB spinning disk, NTFS | Holds the recordings. 16.4 GiB a day for one always-on 1440p camera, 107 GiB a day across the nine that record. The storage math. |
| Three scheduled tasks | Bring it all back after a reboot, keep the Linux side from going to sleep, and start the detector. |
The shape of it
Windows boots. A scheduled task starts the Ubuntu distro inside WSL2. Because systemd is on inside that distro, Docker starts by itself, and because the Frigate container is marked restart: unless-stopped, Frigate starts by itself. Frigate reads its config from D:\frigate\config and writes clips to D:\frigate\media, both of which Linux sees as /mnt/d/frigate/.... A second small program on the Linux side holds the graphics unit and answers Frigate's "is this a cat?" questions. With mirrored networking, the Frigate web page is at http://127.0.0.1:5000 from a Windows browser as if it were a Windows program.
That chain has four places it breaks if you do not know about them.
What breaks, and why
The Linux side goes to sleep. WSL2 tears the distro down a few seconds after the last terminal window closes. Frigate stops, with no error anywhere. Two settings fix it: vmIdleTimeout=-1 in .wslconfig, and an "anchor" process that keeps a wsl.exe open forever. We run the anchor from a keepalive task every two minutes; if it is missing, the task starts it again.
The boot task runs as SYSTEM and does nothing. Windows' Task Scheduler defaults to running boot-time tasks as the SYSTEM account. wsl.exe refuses to run as LOCAL SYSTEM. The task reports success, the log is empty, and Frigate is not up. Run the task as your own user, "whether logged on or not", with highest privileges.
Networking that is not mirrored. By default WSL2 has its own private network, so 127.0.0.1:5000 means nothing from Windows and the cameras' RTSP addresses are a hop away. Set networkingMode=mirrored and the Linux side shares the Windows network stack: same addresses, same ports, both directions.
No /dev/dri. On real Linux, Frigate uses the Intel graphics through /dev/dri for both decoding video and, optionally, running the detector. WSL2 does not have /dev/dri. It has /dev/dxg, which is Microsoft's own door to the GPU. Frigate's own OpenVINO cannot see through that door, so we run the detector as a separate program on the Linux side that can. Hardware video decode is off the table in the container, and at 640×360 and 2 fps that turns out not to matter.
What it costs
With eleven cameras, seven of them detecting cat and person at 2 fps, one switched off, and three house cameras just recording at 3 fps, the whole Linux side (Frigate, go2rtc and the decoders) was using 13.6 % of the CPU when we captured its stats on 2026-09-03. The detector on the graphics unit answers in about 12 ms and is idle most of the time. The machine still does everything else it did before, including cutting and posting the Shorts and pushing two 24/7 streams to YouTube. Windows Update reboots it now and then; the boot task brings Frigate back within a few minutes, and the recordings are where they were.
-
Install WSL2 and Ubuntu.
In an elevated PowerShell:
wsl --install -d Ubuntu. Reboot. Open Ubuntu once so it creates your user. Microsoft's page on systemd in WSL is the one to have open. -
Turn systemd on inside the distro.
Two lines in
/etc/wsl.conf, thenwsl --shutdownfrom Windows. Without this, nothing restarts by itself after a reboot. -
Tell WSL to share the network and never sleep.
In
%USERPROFILE%\.wslconfig: mirrored networking, idle timeout off. The exact file is on the setup page. -
Install Docker Engine inside Ubuntu.
Follow Docker's ordinary Ubuntu instructions inside the distro. Do not install Docker Desktop for this; it manages its own distro, its own restarts, and its own idea of when to be running. Point Docker's
data-rootat the Linux disk, not at/mnt/d. -
Make a home for Frigate on a real drive.
D:\frigate\configfor the config,D:\frigate\mediafor the clips. From Linux that is/mnt/d/frigate/.... The clips can live on NTFS; we have 900 GB of them there and it is fine. -
Write the compose file and start it.
The important lines: pass
/dev/dxgas a device, mount/usr/lib/wsl/lib, setshm_sizeto what Frigate asks for, and bind the two folders.docker compose up -d. Frigate's install docs cover the rest of the container. -
Add your cameras and look at the stats.
Open
http://127.0.0.1:5000in a Windows browser. Add cameras per the camera setup page. Then open/api/statsand check every camera showsskipped_fps: 0.0. - Add the boot script and the keepalive as scheduled tasks. Boot script at startup and at logon; keepalive every two minutes. Both as your user, highest privileges. Both scripts are on the setup page. The third task, which starts the detector at boot, is on the detector page.
- Move detection onto the graphics unit. Optional, but it is why the whole Linux side sits at 13.6 % of the CPU. A small Python program on the Linux side holds the iGPU and Frigate talks to it over a socket. The whole detector, with numbers.
-
Reboot before you trust it.
Restart Windows and read
C:\ProgramData\FrigateBoot\frigate-boot.log. It should say the D: drive appeared, the distro answered, Docker is active, and the API listed your cameras. If it does not, the log says which step stopped.
Limits
Windows Update will reboot the machine on its own schedule; the boot task handles the comeback but you lose a minute or two of recording. Recordings go through WSL's 9p file-sharing layer to reach the NTFS drive; at our 107 GiB a day across nine cameras that has been fine for weeks, but it is slower than a native Linux disk, so keep Docker's own files off it. Hardware video decode is not available in the container, so a large number of high-resolution detect streams would push the CPU; keep detect on the sub-stream. And this is a desktop, not a server: it has no remote console, so the boot script's log is the only witness when something goes wrong at 3 am.