Four cameras public. Eleven cameras in Frigate. Frigate never on the internet.

Most answers to "how do I share a Frigate camera on a website" involve opening a port, and a port forward to Frigate hands a stranger the admin console: every camera, every recording, the config editor. Frigate should be reachable from the LAN and from a private network and from nowhere else. What we built instead can be tested from your own browser: the four public frames are at the bottom, and any other camera name returns a refusal.

The rule

The public sees latest.jpg from an allowlist. Not a stream, not the Frigate UI, not the events list, not RTSP, not the house cameras, not the Face camera. Four names, each with a label: Water Cam, Food Cam, Treat Cam, Scratch Cam (the overhead we call the Court). That list lives in two places, and both have to agree before a frame goes out.

Eleven cameras exist in Frigate on the box. Seven of them watch Helen, three watch the house, and one is a spare, disabled. Which of them a visitor can see is decided on the web server, not in Frigate, so a mistake in Frigate's config cannot publish a doorway. The naming and the private/public split are laid out on the network-and-naming page.

The chain

browser
  GET https://helenthecatlive.com/live-cam/api/cam/cat_water_bowl/latest.jpg
  |
  v
Caddy (Helen VPS, 1 vCPU)            handle /live-cam/* { reverse_proxy 127.0.0.1:5178 }
  |
  v
server/api.mjs (node, pm2, :5178)    path must be one of LIVE_CAM_PATHS (4 entries)
  |                                  40 requests / 10 s per IP, else 429
  |                                  1.5 s memo per camera + in-flight dedupe
  |                                  adds header x-helen-code: <ACCESS_CODE>
  v
helen-cam-proxy (express, pm2, :3113, loopback only)
  |                                  access code, timing-safe compare; 12 bad codes / 10 min per IP -> 429
  |                                  GET only; camera must be in HELEN_CAMS, else 403
  v
Tailscale                            http://<TAILSCALE_IP>:5000/api/cat_water_bowl/latest.jpg
  |
  v
Frigate (Windows desktop in the house, WSL2 docker)   no public IP, no port forward

Three separate refusals, in three separate processes, written at three separate times. The site backend does not know Frigate's address. The proxy does not know which site is calling it, only whether the code is right. Frigate does not know either of them exists. Widening one list does not widen the other: to make the Face camera public you would have to add it to HELEN_CAMS on the proxy and to LIVE_CAM_PATHS in the backend, in two deploys, and that friction is the feature.

The site-side handler, as it runs

This is the part of server/api.mjs that serves the four public frames. Plain node:http, no framework. The proxy in front of Frigate is a separate small Express app whose behaviour is in the table above; its env contract is three lines.

const LIVE_CAM_PATHS = new Set([
  "/api/cam/cat_water_bowl/latest.jpg",
  "/api/cam/cat_food_bowl/latest.jpg",
  "/api/cam/cat_treat_dispenser/latest.jpg",
  "/api/cam/cat_scratching_pad/latest.jpg",
]);

const camCache = new Map();
const camInflight = new Map();

const CAM_PROXY_BASE = (process.env.HELEN_CAM_PROXY_BASE || "http://127.0.0.1:3113").replace(/\/+$/, "");
const CAM_PROXY_CODE = process.env.HELEN_CAM_PROXY_CODE || "";

async function fetchLiveCam(camPath) {
  const hit = camCache.get(camPath);
  if (hit && Date.now() - hit.at < 1500) return hit;
  if (camInflight.has(camPath)) return camInflight.get(camPath);
  const job = (async () => {
    // camPath looks like /api/cam/<cam>/latest.jpg; the local cam proxy
    // (helen-cam-proxy, mirroring Frigate) serves it as /api/<cam>/latest.jpg.
    const upstreamPath = camPath.replace(/^\/api\/cam\//, "/api/");
    const up = await fetch(`${CAM_PROXY_BASE}${upstreamPath}`, {
      headers: CAM_PROXY_CODE ? { "x-helen-code": CAM_PROXY_CODE } : {},
      signal: AbortSignal.timeout(2500),
    });
    const rec = {
      status: up.status,
      type: up.headers.get("content-type") || "image/jpeg",
      buf: Buffer.from(await up.arrayBuffer()),
      at: Date.now(),
    };
    camCache.set(camPath, rec);
    return rec;
  })();
  camInflight.set(camPath, job);
  try {
    return await job;
  } finally {
    camInflight.delete(camPath);
  }
}

    if (url.pathname.startsWith("/live-cam/")) {
      const camPath = url.pathname.replace(/^\/live-cam/, "");
      if (!LIVE_CAM_PATHS.has(camPath)) {
        res.writeHead(404, { "Content-Type": "application/json", ...SEC_HEADERS });
        res.end(JSON.stringify({ message: "Unknown camera." }));
        return;
      }
      if (!rateLimit(`cam:${clientIp(req)}`, 40, 10_000)) {
        res.writeHead(429, { "Content-Type": "application/json", ...SEC_HEADERS, "Retry-After": "2" });
        res.end(JSON.stringify({ message: "Camera is catching up." }));
        return;
      }
      try {
        const rec = await fetchLiveCam(camPath);
        res.writeHead(rec.status, {
          "Content-Type": rec.type,
          "Cache-Control": "private, max-age=1",
          ...SEC_HEADERS,
        });
        res.end(rec.buf);
      } catch {
        res.writeHead(502, { "Content-Type": "application/json", ...SEC_HEADERS });
        res.end(JSON.stringify({ message: "Camera feed unavailable." }));
      }
      return;
    }

FRIGATE_BASE=http://<TAILSCALE_IP>:5000
HELEN_CAMS=cat_water_bowl:Water Cam,cat_food_bowl:Food Cam,cat_treat_dispenser:Treat Cam,cat_scratching_pad:Scratch Cam
HELEN_ACCESS_CODES=<ACCESS_CODE>

	handle /api/* {
		reverse_proxy 127.0.0.1:5178
	}
	handle /live-cam/* {
		reverse_proxy 127.0.0.1:5178
	}

The 1.5-second memo is what makes a one-vCPU VPS enough. However many people have the court open, Frigate is asked for a given camera at most once every 1.5 s, and a burst of requests that arrive while that fetch is in flight all get the same answer. The VPS never touches video; it moves a JPEG of a few tens of kilobytes, and the machine that does the real work is the desktop in the house. The Android app the proxy was originally built for uses the same code and the same allowlist.

Why this and not the obvious things

• Not a port forward. Frigate's web UI is an admin surface, whatever login sits in front of it. A port forward also puts the house's public IP in every page source. Tailscale gives the VPS a route to one machine and nothing else, and the house has no inbound port at all. Tailscale's own notes on subnet routers cover the case where the NVR cannot run the client itself.
• Not go2rtc's WebRTC. It is excellent on a LAN and it is the right answer for a private viewer app. For a public page it means a media server on the internet, STUN/TURN, and per-viewer cost that scales with the audience. A still that refreshes is what a website can afford forever, and the 24/7 video lives where video belongs: on YouTube.
• Not one allowlist. Two, because the day you are debugging at midnight and add a camera to "just see if it works" should not be the day it becomes public.
• Not Frigate's own auth. The proxy's access code is not a login; it is a shared secret between two processes on the same VPS, in an env file, and it exists so that even a bug in Caddy that exposed :3113 would produce a 401, not a picture.

What you give up

Motion. A visitor sees a new frame roughly every 1.5 seconds and never hears the fountain. On the 3D court that is fine, because the frames are textures on screens in a room you can walk around, and the room is the show; on a plain page it is a slideshow. For live video there is the mosaic and the Face cam on YouTube, encoded from the same go2rtc streams, and that trade (stills on the site, video on the platform built for it) is what lets the whole web tier, both sites and their analytics, run on one 1-vCPU VPS.

The Caddy and pm2 side. Getting the cameras into Frigate. Where the moving pictures went. Back to the cameras page.