The Offline-First
Isolation Architecture.
We built OpenNVR with a fundamental assumption: IP cameras are inherently insecure. They cannot be trusted. The architecture is designed around strict network isolation and a fully decoupled, fault-isolated AI inference pipeline.
Topology: two networks, one host
┌────────────────────────────────────────────────────────────┐
│ OpenNVR host │
Camera LAN (no internet) │ │
IP cameras (PoE) NIC 1 │ ┌──────────┐ records ┌──────────────┐ │
10.0.4.0/24 ───────────────┼──>│ MediaMTX │──────────>│ recordings/ │ never gated │
│ │ (Go) │ └──────────────┘ │
│ └────┬─────┘ substream │
│ │ ┌───────────────────┐ tracks ┌────────┐ │
│ └──────>│ detect-pipeline │───────────>│ NATS │ │
│ │ Tier-0, always on │ │ bus │ │
│ └───────────────────┘ └───┬────┘ │
│ │ │
│ ┌──────────────────┐ best frame ┌──────────┐ │ │
│ │ opennvr-core │─────────────>│ KAI-C │ │ │
│ │ FastAPI · :8000 │<─────────────│ :8100 │ │ │
│ │ + KAI-C in-image │ result └────┬─────┘ │ │
│ └───┬──────────────┘ │ /infer │ │
│ │ ┌─────┴──────┐ │ │
│ │ │ adapters │ │ │
Trusted LAN NIC 2 │ ┌───┴──────┐ WebRTC / HLS │ YOLO, LPR, │ │ │
users, operators ──────────┼──>│ nginx │ React UI (Vite) │ pose, VLM… │ │ │
192.168.1.0/24 │ └──────────┘ └────────────┘ │ │
│ │ │
│ ┌──────────────────────────────────────────────┐ │ │
│ │ apps (own network, own credential each) │<─┘ │
│ │ ANPR · occupancy · guard scan · notifier … │ │
│ └──────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────┘
1The Zero-Trust Camera LAN
In a standard deployment, cameras are placed on a dedicated, non-routable VLAN. They cannot reach the internet to "phone home" to malicious servers, and end-users cannot reach them directly. The OpenNVR server sits on the perimeter using a dual-NIC (Network Interface Card) configuration to bridge the gap safely.
OpenNVR uses the high-performance MediaMTX engine (written in Go) to ingest the raw RTSP feeds from the camera LAN, then exposes a controlled, encrypted WebRTC gateway to the trusted user network. If a camera is compromised by a botnet or malware, it has no route out — the isolated VLAN and default-deny forwarding rules give it nowhere to go.
2KAI-C: The Connective Middleware
KAI-C is the middleware every inference passes through. It does not touch video: it holds the adapter registry, enforces the sovereignty policy, mints the correlation ID that follows a request end to end, and writes the audit log. The backend never calls a model directly, which is what makes the audit trail complete rather than best-effort.
On registration and every 60 seconds after, KAI-C polls each adapter's /capabilities — its tasks, model fingerprint and health. A fingerprint that changes is audited; an adapter that gains a permission it did not have stops serving until an operator re-approves it; one that starts declaring network egress under local_only is de-registered. It ships inside the opennvr-core image on port 8100.
3Decoupled AI Processing
Most legacy NVRs bake object detection directly into the C++ video recording monolith running on the server. If a complex neural network throws an out-of-memory (OOM) exception or panics, the entire NVR crashes and you lose security footage.
They are decoupled by construction.
- Recording is MediaMTX, written in Go. It never loads a model and is never gated by one.
- Each adapter is its own container behind the Open Adapter Contract — one image per model.
- They meet only over HTTP, through KAI-C, with schemas generated from the code.
Result: If you drop experimental, untested Hugging Face code into your AI Adapters folder and it explodes, KAI-C gracefully logs a timeout error while the core Go routing engine continues tracking and recording your cameras without dropping a single frame.
4Compute-Gated Inference
Running a heavy neural network on every frame of every camera doesn't fit modest hardware. OpenNVR uses a two-tier, compute-gated pipeline so real AI runs on affordable boxes like a Raspberry Pi 5 or an Intel N100.
- Tier 0 — always-on and cheap. A per-camera pipeline (motion → region → a lightweight ONNX detector → tracking → best-frame) watches every stream and publishes structured events. It runs on a pluggable backend: plain CPU, or an accelerator via OpenVINO / TensorRT on the same model.
- The gate — spend the expensive models sparingly. Heavy models (scene-describing VLMs, face, license plate) run once, on the best frame of a real event — not on every frame — and every decision, including the ones it skips, is audited by KAI-C.
- Recording is never gated. Video always records regardless of any AI decision — the AI only ever adds understanding, never gatekeeps your footage.
Where it stands: Tier-0 ships as a compose service, on by default in shadow mode — it observes, publishes tracks and best frames, and audits every escalate/suppress decision without enforcing one. Promoting a camera from shadow to enforcement is one click in the UI, with a best-frame VLM check on by default. Dispatching the gated model through KAI-C on escalation ships too, flag-gated off until you turn it on.
Result: an always-on cheap tier answers most questions ("is anyone at the door?", "how many cars today?") with no expensive model at all, and reserves the costly models for the moments that actually matter — turning a workstation-class AI workload into something that runs quietly on hardware you already own.