Server Build Guide: Part Order, Chassis Choice and What's Missed
Building a server from parts gives you exactly what you need at a lower price than a configured system, and it goes wrong in predictable ways. This covers the order to make decisions in, and the parts people forget until the build stops.
Should you build a server or buy one configured?
The honest answer first.
Buy configured when the machine must be in production quickly, when you need vendor support on the whole system, or when procurement requires a single part number. A configured server arrives working.
Build from parts when you have a chassis already, when you want a specification no configured option matches, when the budget is the constraint, or when you are expanding an existing machine.
The saving on a build is real, and so is the time cost. Our build versus buy guide covers the decision in more detail.
Start with the workload, not the parts
Three questions before anything else.
What will it run, and how much memory does that need? On virtualisation hosts, memory runs out before processor does, almost every time. Our host sizing guide covers sizing properly.
How much storage, at what speed? Capacity and performance are different tiers with different drives.
Where will it live? A machine room takes a rack server; a room with people in it needs a tower. Our noise guide covers this honestly, and it is the decision most often got wrong.
The chassis decides almost everything
This is the step that catches people, because a chassis is not just a box.
The chassis fixes drive bay count and size, which cannot be changed by adding drives. It fixes expansion slot count and height — 1U takes low-profile cards only. It fixes which processors can be cooled, since high-power parts are harder to cool in 1U. And it determines which rails, carriers and risers you need.
So the chassis and its generation come first, and everything else is chosen against it. Our form factors guide covers choosing, and our naming guide covers identifying a chassis you already have.
The build order
Six decisions, in this order, because each constrains the next.
1. Chassis and generation. Per above.
2. Processors. Same model in both sockets. Firmware must support the generation you are fitting — a Xeon E5 v4 in a board shipped for v3 will not post without a firmware update applied first. Our processor guide covers this.
3. Memory. Type (RDIMM or LRDIMM) and speed set by the processor tier, quantity set by the population table. Our memory install guide covers why slot order decides performance.
4. Controller. RAID or HBA, and whether it needs cache with battery backup. Our controller guide covers the choice.
5. Drives. Interface, capacity, sector format and firmware coding, all matched to the controller and backplane.
6. Networking. Adapters matched to slot height and available lanes.
The parts people forget
Every one of these has stopped a build.
Heatsinks. A bare processor does not include one, and they are chassis-specific and rated to a power class.
Extra fans. Many platforms require additional fans when a second processor is fitted.
Drive carriers. Empty bays do not come with them, and carrier generation must match the chassis.
Risers. Without them the machine takes no expansion cards at all.
Rails. They stay in the rack when a server is removed, so used chassis frequently arrive without them.
Blanks. Empty bays and empty fan positions need blanking for airflow.
Cache battery or capacitor pack. A separate part, and without it the controller runs write-through and write performance collapses with no error reported.
Power cords. One per supply. Our power cords guide covers the types.
Our backplanes and caddies guide covers several of these together.
Before it goes into production
Four steps that catch problems while they are still cheap.
Update firmware across BIOS, controller, drives and network adapters, in the sequence the vendor specifies. Our firmware guide covers sequencing.
Configure out-of-band management and test it from another machine. Our out-of-band guide covers why this is the thing you need at 3am.
Run it under load for a sustained period before trusting it. Early-life failures show up here, not later.
Record what is in it. Serials, part numbers, firmware levels. Our acceptance testing guide covers the checklist.
Frequently asked questions
Is it cheaper to build a server than buy one?
Usually yes on parts, especially where you already have a chassis. The cost is time and the risk of a missing part stopping the build. Buy configured when the machine must be in production quickly or needs vendor support on the whole system.
What should I choose first when building a server?
The workload, then the chassis. The chassis fixes drive bays, expansion slots, which processors can be cooled, and which rails and carriers you need. Everything else is chosen against it.
What parts do people forget on a server build?
Heatsinks, extra fans for a second processor, drive carriers, risers, rails, blanking panels, the controller cache battery, and power cords. Every one of these has stopped a build.
Can I add more drive bays to a server?
Not by adding drives. Bay count and size are fixed by the backplane, which is chassis-specific hardware with its own cabling. Choose the chassis for the bay count you need.
Do I need to update firmware before installing processors?
Yes, where you are fitting a newer processor generation than the board shipped with. It fits physically and will not post without firmware support, and a machine that will not post cannot then be updated.
What should I test before putting a built server into production?
Update firmware in the vendor sequence, configure and test out-of-band management from another machine, run it under sustained load to catch early-life failures, and record serials, part numbers and firmware levels.
Send us your chassis model and what the machine will run, and we will list every part the build needs including the ones people forget.
