AI-optimised · 8–24 bays · GPU-ready

Surveillance servers for VMS, analytics and face recognition

Built for camera ingest, long-term retention and real-time AI inference. Intel Xeon for VMS throughput, AMD EPYC for GPU-dense analytics and FR, in 8, 12, 16 or 24 hot-swap bays — or diskless when storage is external.

• 8 / 12 / 16 / 24 bays — Hot-swap, or diskless
• Xeon and EPYC — Ingest or GPU density
• GPU-ready — SFF modules or RTX/Radeon
• 10G / 25G / 100G — LACP and teaming
• Redundant PSU — Hot-swap fans

Three solution lines

Pick the platform the workload actually needs

VMS servers for recording, video analytics servers for AI insight, and face recognition servers for biometric identification. They are different machines because each of the three workloads puts pressure on a different part of the design.

• VMS servers — Intel Xeon, tuned for sustained video ingest and retention with LSI RAID cache. 8, 12, 16 or 24 bays, or diskless for SAN and NAS.
• Video analytics servers — AMD EPYC with dense SFF GPU support for motion analysis, object detection and behaviour analytics. 8–24 bays or diskless.
• Face recognition servers — AMD EPYC with flexible GPUs — NVIDIA RTX, AMD Radeon Pro, or cost-optimised cards in 3U and 4U chassis.

Choosing between them

Xeon for throughput, EPYC for GPU density

Intel Xeon is the default for VMS recording servers because of I/O stability and proven behaviour with RAID caching under a sustained write load. Recording is not a bursty workload; it is the same write, every second, for years.

AMD EPYC is the recommendation for analytics and face recognition because of PCIe lane count and multi-GPU scaling. When the constraint is how many GPUs the platform can actually feed, lanes matter more than clock speed.

• Sustained camera ingest and 24×7 recording — Xeon with RAID cache
• Object detection, ANPR, crowd and behaviour analytics — EPYC with GPUs
• Real-time biometric matching against a large template database — EPYC with GPUs
• Small and mid-scale sites can run all three on one GPU-enabled EPYC node
• Higher scale or strict uptime — separate VMS and AI/FR nodes

• for VMS throughput
• for GPU-dense analytics
• SFF GPUs, single or dual
• for RTX and Radeon cards

Baseline specifications

What every line has in common

The chassis, memory, networking and management baseline is shared across all three platforms. What changes between them is the CPU choice, the GPU capacity and whether RAID cache is doing the heavy lifting.

• Bays: 8 / 12 / 16 / 24 hot-swap, in SAS, SATA or NVMe
• CPU: Intel Xeon for VMS, AMD EPYC for analytics and face recognition
• GPU: SFF modules, up to 5 single or 4 dual, or RTX and Radeon in 3U/4U
• Memory: ECC DDR4 and DDR5, at high capacity
• Networking: 10G, 25G and 100G NIC options with LACP and teaming
• RAID: LSI controllers with cache, on the recording platforms
• Management: IPMI and Redfish remote management with virtual console
• Power: redundant hot-swap PSUs and hot-swap fans

Deployment models

Five ways these get deployed

The right one depends on where the storage lives and whether recording and analytics share a node.

• Local storage — An 8 to 24 bay chassis with RAID, where retention lives on the recording node itself.
• Diskless — No local bays, with SAN, NAS or object storage behind a high-speed link carrying the retention.
• Single node — VMS, analytics and face recognition together on one GPU-enabled platform, for small to mid-scale sites.
• Scale-out — Separate VMS, analytics and FR nodes, for higher scale or where uptime requirements are strict.
• Edge — Short-depth or low-noise chassis, where the machine sits somewhere that was never designed to hold a server.
• Mixed — Local bays for the ingest tier and central storage behind it, which is what large multi-site estates usually settle on.

How we deliver

A clear path from sizing to support

Six stages. The first one decides most of the cost, which is why it is not a form.

• Sizing — Camera count, bitrate, retention and analytics or FR throughput define the compute, storage and GPU the project actually needs.
• Architecture — Select VMS, analytics and FR nodes. Pick bay count or diskless. Map the NICs and the RAID layout to the ingest.
• Integration and deployment — Install the VMS, analytics pipelines and FR engines, validate performance, then rack, wire and test with burn-in and soak for 24×7 readiness.

After it is running

Support and optimisation

Two stages that the sizing conversation rarely covers and the second year always does.

• Local warranty, spares and upgrade paths for storage, NICs and GPUs as the estate grows
• Alerting and remote management configured before handover, not after the first incident
• RAID cache and I/O queue tuning as recording profiles and camera counts change
• GPU utilisation review as analytics models are added or replaced
• Capacity headroom checked against the retention policy actually in force
• Firmware and driver combinations proven before they go near a production node

Common questions

The four that decide the configuration

• Can one server run VMS, analytics and FR? — Short answer: Yes, for small to mid-scale — a single EPYC server with GPUs. At higher scale, or where uptime is strict, we recommend separate VMS and AI/FR nodes.
• What bay count should I choose? — Short answer: 8-bay for small sites, 12 or 16 for mid-scale, 24 for large retention or dense ingest. Diskless when storage is external.
• Do you support RTX and Radeon cards? — Short answer: Yes. 3U and 4U servers take RTX or Radeon Pro, and selected high-end consumer cards in cost-optimised builds. For dense compact builds, SFF GPU modules — up to 5 single or 4 dual.
• Xeon or EPYC? — Short answer: Xeon for VMS recording, for I/O stability and RAID caching. EPYC for AI and FR, for PCIe lane count and multi-GPU scaling.

Final sizing depends on codec, resolution, frame rate, scene complexity and recording profile. The sizing tools on this site will get you to a starting point.

At a glance

What the three lines share

• hot-swap bays, or diskless
• DDR4 and DDR5 memory
• networking available
• remote management

Request sizing

Tell us the estate, and we will send a bill of materials

Camera count, codec, bitrate, retention days, the analytics you intend to run and the face-recognition throughput you need. With those, we reply with a bill of materials and the options around it rather than a price for a box.

If you would rather start with a number yourself, the surveillance sizing tools on this site work through the same arithmetic — camera ingest, retention and GPU load — and give you a starting configuration to bring to the conversation.

Size it first

Work the numbers before you specify

The calculators run the same arithmetic our engineers do, so you can arrive with a starting configuration rather than a blank page.

• NVR storage & retention — Camera count, codec, bitrate and retention days to the storage you actually need.
• Video analytics GPU sizing — Streams, models and frame rate to a GPU count that holds under real load.
• Face recognition GPU sizing — Faces per second and template database size to GPU and memory.

Related range

The three lines in detail

Each with its own sizing, specifications and FAQ.

• OPS modules — Slot-in compute for displays — signage, classrooms and control-room walls.
• VMS servers — Intel Xeon with LSI RAID cache, 8 to 24 bays or diskless, for sustained ingest.
• Video analytics servers — AMD EPYC with dense SFF GPUs for ANPR, object and behaviour analytics.
• Face recognition servers — AMD EPYC with GPU acceleration for real-time biometric matching.