Hardware Sizing

Node sizing is driven almost entirely by how many camera streams the node's VPP instance processes, and where. Server-side RTSP puts the full detection and recognition load on the node host — CPU/GPU demand grows with every stream. On-edge processing moves detection onto the camera or AI box, leaving the server a fraction of the work per camera. The corridor services themselves (Hub, CIGS, CBS, broker, PostgreSQL) are lightweight next to video processing.

Starting points

For a single-node pilot with a handful of RTSP cameras, a Linux host (Ubuntu 22.04 LTS or later) running Docker with a modern multi-core CPU, a supported NVIDIA GPU for recognition workloads, and SSD storage is the practical baseline. VPP is the sizing-relevant component — consult the hardware requirements in the VPP platform documentation for per-stream figures, and validate your camera count against them before procurement.

What changes the math

Three levers dominate: camera count per node (scale linearly; when a host saturates, add a node rather than overloading one), processing type (moving cameras to edge devices reclaims server capacity — see On-edge processing), and storage mode (with STORAGE_ENABLED=true, PostgreSQL stores face crops and full frames; the short default retention keeps volumes modest, but size disk for your configured TTLs — see Event Storage & Retention).

Ask before you buy

Sizing for a specific site — lane count, expected throughput, camera models, edge vs. server split — is confirmed with Innovatrics during project preparation. Share the intended layout and camera shortlist early; a short compatibility and sizing check is cheaper than re-procurement.