Not a deployment issue. Frigate is the one service on the self-hosted shortlist that changes the network's shape rather than just its population, and ADR-0008 set the precedent that a service like that gets a decision record rather than a ticket.
What it is
Frigate MIT Docker/Python/Nodejs — awesome-selfhosted README.md:2196. Locally-processed AI object detection on camera streams, integrating with Home Assistant (#134).
The appeal is real and specific: the cameras on Skids (VLAN 20) are, per docs/security.md, "network-connected computers running firmware nobody outside its vendor has audited". Frigate is how their footage becomes useful without any of it leaving the house.
Four things to settle first
1. It changes the character of the 99→20 rule. ADR-0008 adds that rule for "Home Assistant reaching IoT devices" — occasional, low-volume control traffic. Frigate on VLAN 99 would pull continuous RTSP through the same rule, permanently, from every camera. The rule's direction stays correct; its volume and purpose do not resemble what was authorised. That is worth re-authorising explicitly rather than inheriting.
2. It becomes the most sensitive data store in the house. docs/security.md deliberately withholds camera placement from this repository. A clip archive is that information, plus continuous footage of the inside of the house, in one volume — a larger concession than the photo library in #132, and on the same segment as the firewall's admin UI.
3. Hardware. Frigate wants a Coral TPU or a capable GPU. On CPU it will saturate whatever it runs on, and the current plan is a low-power N100-class mini PC also running Immich's ML, Paperless's OCR, and seven other services. Continuous decode plus detection for several cameras is not a marginal load — this likely means either a Coral or a third machine.
4. Storage and retention. Continuous recording is measured in TB per camera per month. Retention policy is a decision with a privacy dimension as well as a capacity one.
The alternative worth pricing
Frigate on the NAS (VLAN 40) instead. It puts the recording load on the box with the disks, and keeps clips off the management segment — but it needs 40→20 or a camera path into a terminal segment, which is worse in a different way, and the clips end up on the tier ADR-0008 defined as holding replaceable data. Probably wrong, but it should be rejected on the record rather than by omission.
What closing this looks like
An ADR — accept it with the rule re-scoped and the hardware bought, or decline it and say why. ADR-0008 handled the media server exactly this way rather than assuming a placement, and this is the same class of question.
Which VLAN this touches
🔴 99 — Winterfell (management)
🔵 20 — Skids (IoT)
🟡 40 — CasaBonita (media) — if the alternative placement is taken
Security review
Depends on
#134 (Home Assistant) for the integration to be worth anything, #102 for the hardware. Blocked on the decision above.
Not a deployment issue. Frigate is the one service on the self-hosted shortlist that changes the network's shape rather than just its population, and ADR-0008 set the precedent that a service like that gets a decision record rather than a ticket.
What it is
Frigate
MITDocker/Python/Nodejs— awesome-selfhostedREADME.md:2196. Locally-processed AI object detection on camera streams, integrating with Home Assistant (#134).The appeal is real and specific: the cameras on Skids (VLAN 20) are, per
docs/security.md, "network-connected computers running firmware nobody outside its vendor has audited". Frigate is how their footage becomes useful without any of it leaving the house.Four things to settle first
1. It changes the character of the 99→20 rule. ADR-0008 adds that rule for "Home Assistant reaching IoT devices" — occasional, low-volume control traffic. Frigate on VLAN 99 would pull continuous RTSP through the same rule, permanently, from every camera. The rule's direction stays correct; its volume and purpose do not resemble what was authorised. That is worth re-authorising explicitly rather than inheriting.
2. It becomes the most sensitive data store in the house.
docs/security.mddeliberately withholds camera placement from this repository. A clip archive is that information, plus continuous footage of the inside of the house, in one volume — a larger concession than the photo library in #132, and on the same segment as the firewall's admin UI.3. Hardware. Frigate wants a Coral TPU or a capable GPU. On CPU it will saturate whatever it runs on, and the current plan is a low-power N100-class mini PC also running Immich's ML, Paperless's OCR, and seven other services. Continuous decode plus detection for several cameras is not a marginal load — this likely means either a Coral or a third machine.
4. Storage and retention. Continuous recording is measured in TB per camera per month. Retention policy is a decision with a privacy dimension as well as a capacity one.
The alternative worth pricing
Frigate on the NAS (VLAN 40) instead. It puts the recording load on the box with the disks, and keeps clips off the management segment — but it needs 40→20 or a camera path into a terminal segment, which is worse in a different way, and the clips end up on the tier ADR-0008 defined as holding replaceable data. Probably wrong, but it should be rejected on the record rather than by omission.
What closing this looks like
An ADR — accept it with the rule re-scoped and the hardware bought, or decline it and say why. ADR-0008 handled the media server exactly this way rather than assuming a placement, and this is the same class of question.
Which VLAN this touches
🔴 99 — Winterfell (management)
🔵 20 — Skids (IoT)
🟡 40 — CasaBonita (media) — if the alternative placement is taken
Security review
secrets/*.sops.yaml— camera RTSP credentials, which are among the more sensitive in the estatedocs/network.mdwith an OUI-truncated MAC — cameras are already there; a Coral would not be network-attachedDepends on
#134 (Home Assistant) for the integration to be worth anything, #102 for the hardware. Blocked on the decision above.