Datacenter & Colocation Builds
Cages, racks, power, cabling and servers, built by the people who will run them.
A datacenter is a set of physical decisions that software later depends on. Where the cage sits, how much power each rack can draw, which way the air flows, how the fiber is routed and whether the label on a cable matches the record all decide how well the environment runs for the next ten years.
Our team builds these footprints hands-on. We choose or inspect the site, design the cage and rack elevations, specify power and cooling, run and label the cabling, build and burn in the servers, configure the switching and the out-of-band network, and hand over a facility that another team can operate. The same engineers who designed it are in the room when it is racked.
At a glance
We build datacenter footprints with our own hands: we choose the site, design the cage, specify power and cooling, run and label the cabling, build and burn in the servers, and hand over a facility with documentation and a plan to operate it.
The problem
A datacenter project fails in small physical details: a rack that cannot take the weight, an A feed and a B feed that share one breaker, a trunk with the wrong polarity, a server that was never burned in. Network teams, facilities teams and server vendors each own a piece, and nobody owns the whole. We take the whole job, from the first site visit to the day the cage is accepted.
Site selection comes first, and it is more than price per kilowatt. We compare the facility's real power density per cabinet, redundancy of its electrical and cooling paths, carriers present, cross-connect terms, physical access rules, hurricane and flood exposure, and what the contract says about expansion. A cage that cannot grow is a cost you pay twice.
Layout follows. A rack elevation shows every unit: switches at the top or in the middle, servers by weight and heat, patch panels and cable managers in fixed positions, blanking panels in every empty slot. We set a power budget per rack with room to spare, and we put heavy and hot equipment where the floor, the airflow and the feeds can support it.
What we deliver
- Site and colocation selection with a written comparison of power, cooling, carriers, access and contract terms
- Cage and rack layout, elevations, power budget per rack and a cooling plan
- Structured cabling to TIA-568 and labeling to TIA-606: Cat6A copper, OM4 and OS2 fiber, MPO trunks, patch panels and cable management
- Server builds with firmware baselines, BMC configuration and burn-in, plus spine-leaf switching and an out-of-band network
- Asset records in a DCIM, change windows with written procedures, remote hands and decommissioning with certified media sanitization
Power is designed in pairs. Every server with two power supplies has one on an A feed and one on a B feed, each from a separate path with its own PDU, and each side is loaded so that it can carry the whole rack alone if the other fails. We record the draw per rack in kilowatts, plan for three-phase distribution where density requires it, and test a feed failure before production moves in.
Cooling follows the same discipline. Cold-aisle or hot-aisle containment, blanking panels, brush grommets and sealed floor openings keep exhaust air from mixing with supply air. High-density GPU racks may need rear-door heat exchangers or direct liquid cooling, which we plan with the facility rather than discover after delivery.
Cabling is where discipline shows. Copper runs use Cat6A to TIA-568, multimode runs use OM4 and single-mode runs use OS2, with MPO trunks for parallel optics such as 100GBASE-SR4 and 400GBASE-SR8. Patch panels, fixed trunks, cable managers and polarity are planned before the first cable is pulled, and every cable and port is labeled to the scheme in TIA-606 so a technician can trace it without a map.
Servers are built and proven before they carry data. We install motherboards, CPUs, DDR5 registered memory, GPUs and NVMe drives, set firmware to a recorded baseline, configure the BMC for IPMI and Redfish management, and run a burn-in of memory, storage, compute and network under load. A server that fails burn-in is replaced under warranty while the project is still in the build phase.
Switching and optics complete the picture: SFP+ and SFP28 for server access, QSFP28 for 100G, QSFP-DD for 400G, with direct-attach copper and active optical cables for short runs, as described in our article on optics from 10 to 400 Gb/s. A separate out-of-band network with console servers and its own uplink lets us reach every device when the production network is down.
A 42U rack, racked in build order
Heavy gear goes in at the bottom, switches and patching at the top, with cable managers and blanking panels in between. Vertical A and B PDUs sit on opposite sides, and the animation shows the order the units are racked.
A colo cage seen from above
Racks face each other across a contained cold aisle and exhaust into hot aisles that return to the cooling units. Two rows of busway carry A and B power from separate UPS systems, and fiber and copper run overhead on a ladder rack from the meet-me room.
Cable management, before and after
The same patch panel, switch and fiber breakout, first with cables run by hand and then dressed through horizontal managers with a colour per function and a TIA-606 label at both ends. An MPO-12 trunk breaks out into four duplex LC jumpers, and service loops keep the bend radius.
A GPU server, taken apart and accepted
Two CPU sockets with eight DDR5 memory channels each, GPUs on SXM or PCIe, NVMe bays, a NIC with QSFP cages, a BMC speaking Redfish and redundant power supplies. Every machine then runs the same three gates: firmware baseline, burn-in, acceptance.
kW per rack, by workload
Typical power draw per rack by workload, as commonly cited ranges rather than one vendor's figures: storage 5 to 8 kW, general compute 10 to 15 kW, GPU racks with 8‑GPU HGX-class nodes 20 to 40 kW (an NVIDIA DGX H100 is published at about 10.2 kW maximum per system, so two to four per rack). The dashed line is the usable limit with A/B feeds: each feed must carry the whole rack if the other fails, and common practice loads a breaker to 80% of its rating. A 32 A, 400 V three-phase feed is 22.2 kVA, so 17.7 kW usable. Illustrative.
What burn-in catches before production
Illustrative results from burning in 200 servers (400 CPUs, 3,200 DIMMs, 1,600 NVMe drives, 320 GPUs) with memory pattern tests, CPU stress, GPU stress with ECC counters, and NVMe write and verify, over 48 to 72 hours. Faulty parts are replaced under warranty before any workload lands. Numbers are illustrative.
Our process
- 1
Survey
We visit candidate sites, measure power and cooling, and choose with you.
- 2
Design
Layout, elevations, power and cable budgets, and a bill of materials.
- 3
Build
We rack, cable, label and configure, then burn every server in.
- 4
Accept
Failure tests and a signed acceptance checklist before any production load.
- 5
Operate
Handover documents, remote hands and a change process that keeps records true.
We run the build as a series of written procedures. Each change window has a method of procedure with steps, owners, a rollback and a verification, and nothing is racked outside the plan. Asset tracking in a DCIM records every device, rack unit, port, cable and power outlet, so the record and the room agree.
After acceptance we stay available. Remote hands cover the work you cannot do from a distance, from swapping a drive to re-seating a transceiver, and decommissioning follows NIST SP 800-88 media sanitization with a certificate for each device. See our track record for a two-site colocation build (illustrative), a 100G colocation for low-latency trading, and an enterprise's global datacenter network.
Frequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageDo you work in colocation facilities or only in our own rooms?
Both. Most projects are colocation cages, where we choose the facility, design the cage and build inside the provider's rules. We have experience with operators such as Equinix, Digital Realty, Iron Mountain Data Centers, Flexential and DataBank, and with regional and international facilities, and we compare them on power, cooling, carriers and contract terms. We also build private server rooms and upgrade existing ones.
Can you build the servers as well as the network?
Yes. We specify, assemble, update and burn in servers, including GPU systems, and we build the switching, cabling and out-of-band network around them.
How do you accept a finished build?
Before any production load we run failure tests, such as pulling an A or B power feed and failing a link, and walk a signed acceptance checklist with you. You then receive handover documents, as-built diagrams, labels and asset records so someone else can run the room.
Who does the hands-on work in the cage?
Our own engineers rack, cable, label and configure the equipment, and assemble and update the servers, including GPU systems. We do not hand the physical work to a subcontractor, so the people who design the build also run its first day.
Which cabling standards do you follow?
Structured cabling follows ANSI/TIA-568, with administration and labeling to TIA-606. Typical builds use Cat6A copper for management, OM4 and OS2 fiber, MPO trunks and patch panels, with every cable and port labeled at both ends and recorded in the documentation we hand over.
What is server burn-in and why do you do it?
Burn-in runs memory, storage, network and thermal stress on each server before it carries production, so early hardware failures show up on our bench instead of in your service. Machines start from a written firmware and BMC baseline and are accepted against a checklist.
How do you help us choose a colocation facility?
We visit candidate sites and compare power and cooling per rack, carriers on site, cross-connect terms, access rules, remote-hands terms and flood or hurricane exposure. You receive a written comparison, and the choice stays with you. Contract and pricing questions are discussed during scoping.
Can you provide remote hands after the build?
Yes. We write method-of-procedure documents and runbooks, then act as your hands in the cage under agreed change windows with rollback steps. Scope and terms are discussed during scoping.
How do you decommission equipment and wipe the data?
Decommissioning follows NIST SP 800-88 Revision 2, Guidelines for Media Sanitization (September 2025): we choose clear, purge or destroy according to data sensitivity and keep a record for each sanitized item. We plan this at the start of a build, not when racks come out.
How do you plan power per rack?
We start from the real load of the servers, in kilowatts per rack, and feed every dual-power device from independent A and B paths sized so either one can carry the rack alone. The design is checked with the facility against its power and cooling limits before any equipment is ordered.