Why We Chose Customer-Owned Hardware

On October 14, 2022, the idea that became Helixrack started with a familiar problem: a useful workload had become difficult to budget in the cloud. The compute charge was one part of it. Transfer charges, changing utilization, and the cost of keeping an instance available made the total harder to predict.

Buying a server could make the compute cost more legible. Running that server in an apartment, spare room, or shared office created a different set of problems: power, cooling, connectivity, physical access, and what happens when something fails at night.

Helixrack was built around the space between those two choices.

The question we wanted to test

The original proposition was simple: the customer buys and owns the hardware; Helixrack supplies a suitable place to operate it. That meant rack space, power, cooling, network access, and hands-on help when a machine needed to be received, restarted, inspected, or repaired.

This was not a claim that customer-owned equipment was right for every workload. Cloud services remained the practical choice for short-lived jobs, rapidly changing demand, and teams that did not want to manage hardware. We were interested in the other case: steady workloads whose owners wanted control and could benefit from turning an open-ended service bill into an owned asset plus a predictable operating charge.

Accelerated computing made that question more urgent. In September 2022, NVIDIA said Hopper-based H100 systems were entering full production. That announcement did not cause Helixrack to exist, and it does not prove what any early customer needed. It does show the period in which we were asking whether smaller operators could get access to useful compute without defaulting to enterprise colocation or an indefinitely rented cloud instance.

Three operating principles

The founding discussion produced three principles that still describe the service.

First, the customer owns the machine. Ownership should remain clear from purchase through installation and eventual removal. The hardware is not pooled, and Helixrack does not turn it into an opaque share of someone else’s system.

Second, the operating arrangement should be understandable. A customer should know what space, power, network allocation, and support are included. Exceptions and variable charges should be visible before they become a bill.

Third, small deployments deserve serious operations. One server still needs safe power distribution, sensible airflow, monitoring, documented network configuration, and a person who can respond when remote access is not enough. A small customer should not have to buy a private cage to receive careful handling.

A deliberately small first test

The first plan was not to build a conventional data center. It was to prove the service with a modest room in Elizabeth, used equipment where it could be inspected and trusted, a business internet connection, and a limited number of customer-owned servers. The questions were practical: Could we receive and rack equipment consistently? Could we keep addressing isolated? Could we monitor power and respond quickly? Would anyone value the arrangement enough to pay for it?

Those questions shaped the first room, the first rack, and the first customer intake process. They also imposed a useful constraint: add capacity only after the existing operation could be explained and supported.

The company changed substantially after that first discussion. The basic division of responsibility did not. Customers provide the hardware and retain ownership. Helixrack provides the operating environment around it.