groundplaneStart a project
Case study 2024-present

Cloud Gaming Infrastructure

High-density gaming servers, out-of-band management, KVMs, power switching, storage and rack infrastructure for a cloud gaming operator.

A cloud gaming operator needed a server stack they could deploy across US datacenters at unit economics that worked for a consumer service. The closest off-the-shelf option for getting eight user-facing nodes into a rack was a Supermicro 4U 8-GPU server. Our 8-node 2U took half the rack height at a lower cost per unit. We designed, sourced, built, and tested the whole thing from the rack out: gaming nodes, application servers, bulk storage, out-of-band management, custom power, and the cabling around all of it. Vendor relationships and BOM ownership were ours from first quote to first article. Build 1 was assembled in-house, side-by-side with the operator, so every lesson fed straight back into design.

Three production 2U gaming chassis stacked, ready for shipping.
Fig. 1Production units stacked for shipping.

What we built

  • 8-node 2U gaming chassis, each node a full desktop-class compute system
  • Custom KVM at every node, aggregated by a KVM controller per server, all reachable from anywhere
  • Out-of-band management board (custom PCB) sitting below the OS, with hardware-level recovery for any node
  • 2-node application server for control-plane workloads
  • 60-bay SATA chassis with custom backplanes, built for fast primary game storage
  • Custom 19 V redundant power supplies with PMBus telemetry, spec'd by us and sourced through vendors
  • Custom heatsinks, designed and manufactured for the 2U thermal envelope
  • Rack layouts, cabling, and a current-monitoring board with remote per-circuit power control
60-bay SATA storage chassis populated with drives, with the compute and backplane visible to the right.
Fig. 260-bay SATA chassis. Drives in custom carriers; compute and backplane to the right.

Hard parts

Two problems took disproportionate engineering time.

The first was getting eight desktop-class compute nodes into a 2U enclosure and keeping them cool. Each node has its own thermal load, the chassis has a tight static-pressure budget, and the air paths between nodes have to stay independent so one hot node does not drag its neighbors with it. The first heatsink revision was right on the edge of working: with only the bottom node powered, fine; with both nodes loaded, the top one hit 100°C and thermally throttled, and the long fin path was bleeding static pressure across the chassis. We redesigned to share a single heatsink between adjacent nodes, opened up the airflow, and brought both into spec at sustained full load: bottom 70°C, top 76°C.

v1 heatsink for the 2U gaming chassis.
Fig. 3v1 heatsink, the version that did not quite work. The v2 redesign is proprietary.

The second was the back door. Cloud gaming nodes get handed off to end users who can do whatever they want with the OS, including locking the operator out. The OOB system sits below the OS at the hardware layer: it can power cycle, KVM in, reflash firmware, and re-image a node even when everything above it is bricked. The per-server KVM controllers and OOB boards feed into the same control surface, so any node in the fleet is recoverable without anyone walking into the datacenter. The same depth of KVM work later grew into WarpKVM, our standalone inline KVM product.

By the numbers

Gaming nodes
1,520
Total servers
300
Rack power
5-10 kW
Status
Deployed across multiple US datacenters
PCB layout of the KVM controller showing high-speed routing in yellow on a red board.
Fig. 4KVM controller PCB. One of many custom high-speed boards designed for the stack.

What's next

With Build 1 deployed, the next generation is in design: a denser server and rack architecture for the next deployment. The current-monitoring and remote power-management hardware from Build 1 is also growing into its own rack-management product line.