FVIndustrial · Video SurveillanceIndustrial IoTCase study
Fox VMS — Industrial Video Surveillance
Puts an entire plant’s camera estate — live viewing, 24×7 recording and evidentiary export — behind one access-controlled console.
An ONVIF video management system for plant operations: device onboarding by IP or serial, low-latency live viewing, 24×7 recording with policy-driven retention, evidentiary export and per-camera RBAC — across a web console, a WinUI 3 control-room client and a Flutter handset app.
Source private
Industry
Heavy Industry / Plant Operations
Role
Architect & Full-Stack Engineer
Type
SaaS Platform
Year
2026
Status
In progress
150+ cameras
Scale Target
Web · Windows · Mobile
Surfaces
24×7 tiered
Recording
Overview
Fox VMS is industrial IP video surveillance built as two products in one codebase. The first is a client platform in the Hik-Connect mould: add a DVR or NVR by IP, domain or serial, view live, drive PTZ, and watch from another city through an outbound relay. The second is an enterprise VMS — 150+ cameras, centralized recording with mixed-tier retention, RBAC down to a single camera, a video wall and server-side analytics.
The enterprise case is the harder constraint and dominates the architecture; the client platform falls out of it as a thin consumer of the same gateway.
A Go backend carries the gateway, recorder and relay. Four surfaces sit on top: a Next.js operator console, a WinUI 3 control-room client on .NET 8 doing native H.264/H.265 decode, and a Flutter app for Android and iOS.
The problem
Plant surveillance is split between consumer apps that handle a handful of cameras and enterprise VMS platforms that cannot be operated by a small site team. Neither covers a plant that needs 150+ cameras, per-camera access control, evidentiary export and remote viewing from another city.
The solution
One codebase serving both cases: an enterprise VMS whose constraints drive the architecture, with the consumer-style client platform implemented as a thin consumer of the same gateway rather than a separate product.
Technical stack
Frontend
Next.js 15
React 19
Tailwind CSS 4
Flutter 3
Infrastructure
Docker
Also used
Go 1.25
.NET 8
WinUI 3
ONVIF
RTSP
H.264 / H.265
System architecture
1
Go 1.25 backend carrying the gateway, recorder, relay, migrations and seed — fully containerized
2
Next.js 15 + React 19 operator console for device management, live view and administration
3
WinUI 3 on .NET 8 control-room client with native H.264/H.265 decode for wall-scale playback
4
Flutter 3 handset app for Android and iOS
5
ONVIF device onboarding by IP, domain or serial with an outbound relay for cross-network viewing
6
Policy-driven retention with mixed storage tiers and per-camera RBAC
Engineering challenges
Challenge
A consumer-style client and a 150-camera enterprise VMS pull the architecture in opposite directions — simple onboarding versus centralized policy, RBAC and retention.
How I solved it
Designed for the enterprise constraint first and derived the client platform from it, so the simpler product is a restricted view of the same gateway rather than a parallel implementation that would drift.
Challenge
Browser-based decode cannot sustain a control-room video wall at full frame rate across many H.265 streams.
How I solved it
Built the control-room surface as a native WinUI 3 client on .NET 8 with hardware-accelerated decode, leaving the web console for administration and single-stream viewing where a browser is sufficient.
Core features
ONVIF device management — onboard by IP, domain or serial
Low-latency live viewing with PTZ control
24×7 recording with policy-driven, mixed-tier retention
Evidentiary export with chain-of-custody
RBAC down to an individual camera
Video wall for control-room operation
Outbound relay for viewing across networks
Health and storage monitoring across the fleet
Server-side video analytics
Native H.264/H.265 decode in the Windows client
Results & impact
A single platform covering both a small site adding a DVR by serial and a plant running 150+ cameras with tiered retention, per-camera permissions and evidentiary export — reachable from a browser, a Windows control room or a phone.
Screenshots
What I learned
When two products share a codebase, designing for the stricter constraint and deriving the looser one prevents the two from diverging.
Native decode is still the right call for wall-scale multi-stream playback; the browser is the wrong tool for that specific job.
