Your NOC Video Wall Is Just a Linux Box Now (Architecture + the 5-Year Math)

Pavel Suchkov — Mon, 13 Jul 2026 14:46:00 +0000

For twenty years, the video wall was the one part of the NOC you could not run yourself: a proprietary controller appliance, input cards, output cards, a support contract, and often a vendor engineer for every significant change.

That era is quietly ending.

A modern NOC video wall can run on a commodity Linux server with a capable GPU. The wall becomes an IT workload, with everything that implies for architecture, monitoring, redundancy, and lifecycle management.

Disclosure: I work on Craft Wall, one of the software platforms in this space. This article focuses on the architecture and the cost model, not a sales pitch. The underlying dataset is published under CC BY 4.0, so you can rerun the calculations with your own numbers.

What the system actually has to do

Marketing photos usually show operators looking at a glowing wall. The real engineering requirements are more specific:

16–30 live sources rendered simultaneously, 24/7, for years
Multi-operator control, so one operator can rearrange part of the canvas while another controls a different region
Browser-based operation with no client software installed on operator workstations
Failure containment, so one broken dashboard or camera feed cannot take the entire wall down

A real NOC wall must keep Grafana, Splunk, SolarWinds, camera feeds, ticket queues, and IP-KVM sessions running together on one canvas.

If it cannot do that, it is closer to a digital-signage player than a NOC video wall.

What actually goes on the wall

A mid-size telecom or data-center NOC usually converges on five source layers:

Layer	Typical count	Examples
Network-health dashboards	4–8	PRTG, SolarWinds, Zabbix
Metrics and alerting panels	2–4	Grafana, Prometheus
SIEM and security panels	2–4	Splunk, QRadar
Tickets and escalation	1–2	ServiceNow, Jira, on-call board
Visual context	4–8	CCTV, rack cameras, RTSP streams, site systems

This leads to two important architectural consequences.

The browser is a first-class source

Most NOC content is delivered through web dashboards.

The wall software therefore needs actual browser rendering with:

service-account authentication
automatic refresh control
session persistence
defined behavior for stale or unavailable data
independent recovery for each browser source

A screenshot slideshow is not enough.

Multiple transport types are unavoidable

A typical NOC wall may need to handle:

browser dashboards
RTSP camera streams
NDI sources
HDMI capture
IP-KVM sessions
RDP or jump-host consoles
local applications

RTSP and NDI decoding must be handled efficiently, ideally on the GPU and across many simultaneous streams.

If every transport requires a separate paid module, the bill of materials grows quickly.

Three ways to build a NOC video wall

1. Hardware controller

This is the traditional Datapath, Barco, or RGB Spectrum approach.

It is deterministic and familiar, but it usually comes with:

high initial hardware cost
source limits defined by card slots
proprietary expansion cards
vendor-dependent maintenance
forced replacement when the appliance reaches end of life

2. Cloud-managed AV-over-IP

This approach often has a relatively low entry price and is licensed per display.

The trade-off is that the wall may depend on:

a reliable external network path
a remote control plane
recurring subscription payments
licensing that scales directly with the number of displays

The annual fee continues for as long as the wall remains in service.

3. Software on commodity Linux and GPU hardware

This is the category Craft Wall belongs to, alongside other software-based video wall platforms such as Hiperwall and VuWall.

The usual model is:

standard server hardware
commodity GPUs
perpetual software licensing
no per-display subscription
support for on-premises and air-gapped deployments

The trade-off is straightforward: it becomes your server to operate.

For a NOC or DevOps team, that is often an advantage rather than a problem.

What changes when the wall becomes a Linux workload

Moving the video wall onto commodity Linux hardware changes the operating model.

The wall can now be managed with the same practices used for other production infrastructure:

services supervised and restarted automatically
system and application logs collected centrally
CPU, RAM, GPU, temperature, storage, and network utilization monitored
configuration backed up and versioned
health checks connected to the existing monitoring stack
updates tested on the standby node before reaching production
hardware replaced without waiting for a proprietary appliance lifecycle

The monitoring baseline should include:

CPU and memory utilization
GPU utilization and VRAM consumption
GPU temperature and throttling state
dropped frames and decoder errors
source reconnect attempts
network throughput and packet loss
application process health
storage capacity and log growth
primary and standby synchronization status

This does not make the wall maintenance-free. It makes the maintenance visible, automatable, and understandable to the team already operating the NOC.

Failure modes matter more than the demo

A NOC video wall is a 24/7 production system. It should be designed around at least four failure classes.

A source process fails

Each source should run independently and restart automatically.

The blast radius must be limited to one cell or one source, not the entire wall.

A source remains unavailable

The affected cell should fall back to defined content or geometry instead of becoming a permanent black rectangle.

Operators must be able to distinguish between:

an unavailable source
stale data
an authentication failure
an intentionally disabled source

The server fails

A hot-standby server should maintain a synchronized copy of scenes, layouts, and source configuration.

If the primary server fails, the standby should take over within seconds without requiring operator action.

The system becomes saturated

Incident conditions often create the highest load at exactly the worst time.

If GPU, CPU, or network capacity becomes saturated, the platform should support priority-based degradation:

critical sources retain full resolution and quality
secondary sources reduce bitrate, frame rate, or resolution
essential incident information remains visible

If a vendor cannot explain exactly what happens in each of these four situations, that is already a useful answer.

A rough 16-display bill of materials

A typical software-defined deployment might include:

16 professional displays
one commodity Linux server
one RTX-class GPU
approximately 0.45 kW server power draw
one 10GbE network interface
an optional second identical server for hot standby
browser-based operator workstations

The controller software should not care which display manufacturer you use.

Operator workstations should require no dedicated client installation and no per-seat license.

The five-year cost

The full model includes five cost categories, an 8% NPV calculation, and sensitivity analysis.

The dataset is published under CC BY 4.0:

Five-year video wall TCO dataset: DOI 10.5281/zenodo.20650637

Here is the baseline example for a 16-display, 24-source video wall:

Architecture	Acquisition cost	Five-year TCO
Perpetual software on a commodity server	~$8,700	~$13,000
Hardware controller with chassis and cards	~$20,000	~$34,600
Per-display subscription at $500/display/year	~$6,000	~$40,300

The dominant variable is the number of displays multiplied by the annual per-display fee.

At 32 displays, the subscription component roughly doubles. The perpetual-software path changes much less because the license is not directly tied to every physical display.

These baseline figures compare the controller paths and exclude the display panels themselves. A higher-availability deployment with a hot-standby server, additional KVM endpoints, and extended support will have a higher total, which is why the full reference architecture may show a different worked BOM.

Cost is not the only consideration. Frame-accurate broadcast switching, mandatory redundancy architectures, or classified air-gapped environments can legitimately change the ranking.

But if none of those requirements applies, a low initial price should not determine a five-year infrastructure decision.

You can test the numbers using the public video wall TCO calculator.

The short evaluation checklist

Define the deployment model: cloud, on-premises, or air-gapped.
Count sources by type: dashboards, SIEM, tickets, cameras, KVM, and remote desktops.
Require browser-based multi-operator control with authentication and audit logging.
Ask what happens during each of the four failure scenarios.
Monitor the wall as production Linux infrastructure.
Calculate the full five-year cost using your own display count, subscription quote, electricity price, and support costs.

The complete architecture, worked bill of materials, failover model, and integration notes are available here:

NOC Video Wall Reference Architecture

Editorial note: The technical argument and cost model were written and fact-checked by the author. AI assistance was used for English-language editing and Markdown formatting.

DEV Community: Pavel Suchkov