Custom Dedicated Servers

A custom dedicated server is what you build when the plans on the page do not fit the workload in your head. Most dedicated hosting is sold as a menu of fixed configurations, sized for the common cases, and for most workloads that is exactly right. A custom build is for the workloads that fall outside the menu — the ones with an unusual ratio of memory to cores, a specific network or storage requirement, several GPUs, or a compatibility constraint a stock plan cannot satisfy. This page is two things at once: an honest guide to deciding whether you actually need a custom build, and a practical walk through how to specify one — which component to start from, how to choose each part, how the build happens, and how to leave room to grow.

What is a custom dedicated server?

A custom dedicated server is a single-tenant machine specified from the ground up rather than chosen from a fixed list of plans. You select the processor, the amount and type of memory, the storage mix and its RAID layout, the network ports, any GPUs, and the operating system; the provider assembles those parts, runs a burn-in test to catch early failures, and provisions the machine to your specification. The aim is to build the server around the workload instead of bending the workload to fit a stock machine.

That is worthwhile when your requirements fall outside the common case — an unusual memory-to-core ratio, several GPUs, a particular high-bandwidth network, a specific storage layout, or hardware a compliance regime requires. It is the architecture and reasoning behind single-tenant hardware in general, covered on our bare metal servers page, taken down to the level of individual components. But customization is a means, not a virtue in itself, which is why the honest first question is not how to configure a custom server but whether your workload needs one — the subject of the next section, and the one most worth getting right.

Do you actually need a custom build?

Custom is not for making an ordinary server “better.” It earns its place when a standard model cannot deliver the density, speed, upgrade headroom, or compatibility a specific task requires, and outside those cases it mostly adds delivery time and support complexity without a matching benefit. So the decision is worth making deliberately.

The clear cases for a custom build are genuinely non-standard: four to eight GPUs, very large memory, fast NVMe arrays, 100 or 200 gigabit networking, particular cooling, power, or redundancy needs, or hardware a compliance regime specifies. The clear cases for a stock plan are workloads that fit a common scenario — a typical web or database server, an inference node with one or two GPUs, a pilot — where a ready-made machine launches faster and carries less risk of incompatibility. Between them sits an option that is easy to miss and often the best answer: a standard base platform with a few targeted changes, which captures most of the customization value without the full lead time of a ground-up build. The trap to avoid is treating “custom” as a synonym for “serious.” A workload that a stock plan covers is served best by the stock plan, and a provider that reaches for a bespoke quote every time is selling rather than advising.

Start from the bottleneck, not the catalogue

The single most useful habit in speccing a server is to find the constraint before choosing parts. Every workload is limited by something — video memory, GPU count, CPU, RAM, disk I/O, network, or cooling — and the component that limits it should drive the whole build. Buying by maximum specifications, without knowing where the bottleneck is, is how money goes into parts that do not move the result while the actual constraint stays unaddressed.

The way to find it is to describe how the workload behaves, not what it is called. Two machines can both be “GPU servers” and be completely different inside: a server for light inference needs a stable configuration brought online quickly, while a server for training large models needs video memory, GPU-to-GPU communication, networking, drives, power, and cooling all calculated in advance. The same is true across categories — a database server is bound by memory and disk I/O, a streaming server by network, a rendering node by GPU and storage throughput. Once you know which resource runs out first under real load, the rest of the specification follows from supporting it, and the parts that do not touch the bottleneck can be sized modestly without harm. If you cannot yet name the bottleneck, that is the signal to profile the workload before buying, not to order by the largest numbers on the list.

Choosing the CPU, memory, storage, and network

With the bottleneck identified, each component is a choice you can reason about rather than guess at. The table summarizes the options; the notes after it cover what actually drives each decision.

For the CPU, the real question is parallel versus single-thread. High-core EPYC or Xeon suits work that spreads across cores — virtualization, heavy concurrency, parallel compute — while strong per-core clocks suit work bound by single-thread speed; ARM is an option where power efficiency matters, and dual-socket is for genuine consolidation rather than for a bigger number. For memory, size it to keep the working set in RAM, use ECC without exception at server scale, and populate the channels evenly, since DDR5 platforms perform best with RAM spread across all channels, which can mean more modules than a bare capacity target suggests. For storage, match the drive to the access pattern — NVMe for hot, latency-sensitive data, SAS or SATA SSD for resilient operational arrays, HDD for bulk — and pick a RAID layout for redundancy, accepting the usable-capacity cost; our storage server page goes deeper on layered storage. For the network, a gigabit port is the baseline, with 10 to 100 gigabit for bandwidth-heavy work and bonded NICs for throughput; the transfer policy matters as much as the port speed. Across all of them, the rule is to size for the real workload plus immediate growth and to avoid economizing on memory, disk, or network in ways that bottleneck the machine and force a migration later. One practical caveat from how providers operate: some custom platforms let you raise specifications freely but not lower them below a stock baseline, and certain choices, such as the memory type, are fixed by the platform — a board built for one generation of ECC RAM will not take another. Knowing these constraints up front shapes the spec, because the cleanest custom build is one where every requirement is satisfiable on a single coherent platform rather than fighting the hardware’s limits.

GPUs, form factor, and the things that don’t fit

A GPU is never a standalone choice, because an accelerator starved of supporting hardware cannot deliver its capability. If the server lacks the CPU, memory, or storage throughput to feed the card, the GPU sits idle waiting for data, and the money spent on it is wasted. So a GPU build is really a balanced-system build — the accelerator sized alongside enough cores, enough memory, and fast enough storage to keep it busy, with the GPU-to-GPU interconnect mattering once there is more than one card.

Physical fit is the other half, and it is where custom builds most often run into walls. The chassis form factor — typically 1U, 2U, or 4U — bounds how many drives and accelerators fit, and the constraints compound: a GPU can be too long for a chassis, the PCIe lanes can run short for the cards and NVMe you want, the power supply can be undersized for the draw, and the thermals can exceed what the airflow and the room’s cooling can handle. Validating these against each other is part of a competent build — confirming CPU and memory compatibility, backplane and drive-caddy types, PCIe lane budget, power-supply wattage, and cooling — and flagging conflicts before assembly rather than discovering them after. Where the server is going matters too: power circuit, rack space, and cooling at the destination are real limits, and a build that ignores them is a machine that cannot be installed where it is needed.

This is also where the software stack belongs in the conversation, not only the hardware. A GPU build in particular has to match the driver and library versions the application supports, and a machine that is perfect on paper but runs an unsupported combination is a machine that does not work for its purpose. Checking the software requirements — supported driver and library versions, and how the application actually uses the hardware — before finalizing the spec avoids the worst kind of custom-build surprise, the one discovered after assembly.

How does a custom build actually happen?

A custom build is a short process with a few deliberate steps, and knowing them sets the right expectation. It starts with a conversation about the workload rather than a parts list, because the specification should follow from what the machine has to do; from there the configuration is drawn up, quoted, and approved. Then the real assembly happens: the components are sourced or allocated, built into the chassis, and validated for compatibility, and the machine goes through a burn-in test that stresses the CPU, memory, and storage to surface early-life failures before it ever reaches production. Finally the provider provisions the operating system and any baseline configuration and hands it over.

Most custom configurations are online within one to two business days of an approved order — the cost of getting exactly the right hardware rather than a pre-built box. The snapshot below shows the shape of a spec and its build steps.

# custom build · spec to workload, burn-in before handover · mcsnet
# example: bespoke sending platform, spec’d to send volume
cpu      = 1x EPYC 7443 (24c)     # concurrent connections, not max cores
memory   = 128 GB ECC DDR5        # queue + reputation state + headroom
storage  = 2x 1.92TB NVMe RAID1   # fast queue/log I/O, mirrored
network  = 10 Gbps bonded         # send volume plus headroom
ip_plan  = /28 block, warmed      # reputation tied to this machine
burn_in  = 24h stress: cpu ram disk  ->  certificate issued
deploy   = built to order, online in ~1-2 business days

That burn-in step is the part people forget to value. A machine that has been stressed for a day before it carries production load is far less likely to fail in its first weeks, which is exactly when an untested server is most fragile.

Build in headroom for known growth

The most common custom-build mistake is sizing for today and forgetting tomorrow. A configuration that fits a pilot perfectly can be useless for the production service the pilot becomes, and discovering that after launch is expensive. The fix is cheap by comparison: when a commercial launch is on the horizon, build basic headroom into the original spec — a chassis with free bays, a power supply with margin, open memory and drive slots, and a network that can carry more than today’s traffic.

Headroom is also what makes later upgrades easy rather than disruptive. A custom server can often be upgraded or reconfigured in place — more memory, more drives, a denser layout — or migrated to a larger platform when it is genuinely outgrown, and a build with free slots turns that into a part to add rather than a machine to replace. In 2026 there is an extra reason to favor headroom now over upgrades later: memory and storage prices have climbed and supply has tightened, so components added down the line may cost more and take longer to source than they would today. Specifying a deliberate growth path is the difference between an upgrade you schedule and a migration you endure.

What does a custom server cost?

A custom server costs what its components cost, which is both the appeal and the discipline of building one. Renting a configured machine starts around $100 a month for a modest build and climbs past $1,000 for premium specifications with high-bandwidth networking, very large memory, or GPUs, where the accelerator often dominates the bill. Because you choose every part, a custom build is not automatically dearer than a stock plan — you pay for what the workload needs and skip what it does not, which can make a well-specified custom machine better value than an oversized stock tier.

The economy to resist is cutting corners on the components that bottleneck the workload. Going cheap on memory, disks, or network hardware tends to cost more later than it saves now, in the form of performance bottlenecks, instability, and a complicated migration to a better machine once the shortfall becomes unavoidable. The sounder approach is to size for the real workload plus immediate growth and to economize only on the parts that do not touch the bottleneck. In 2026 this matters more than usual, because memory and storage prices have risen and supply has tightened, so a refresh costed on last year’s component prices will come in low. Budgeting over the full term, against what the workload genuinely requires, is how you avoid both overspending on idle capacity and underspending into a bottleneck.

A custom server for email infrastructure

A sending platform is a workload that rewards speccing to the work rather than buying a tier, which is why we build them custom. The bottleneck for a busy mail transfer agent is rarely raw core count; it is the concurrency of many simultaneous connections and the disk I/O of constant writes to queues and logs. So the spec follows from that: enough cores for the connections you actually run, fast mirrored NVMe sized to queue and log throughput, ECC memory with headroom for reputation state, a network sized to send volume, and — the part generic builds miss — an IP plan, warmed and tied to the machine, because sending reputation lives on the hardware mail leaves from.

That is a different machine from a stock plan picked by core count, and the difference shows up in deliverability rather than in a benchmark. We spec sending platforms to volume and tune them for sustained throughput, the same way we run our own, so the configuration matches the work instead of approximating it. It also benefits from headroom in a specific way: sending volume tends to grow, and a platform spec’d with room to add IP capacity, memory, and network spares a growing sender from migrating its reputation onto new hardware mid-growth, which is one of the riskier moves in deliverability. Building that headroom in from the start is part of speccing a sending machine that lasts. It is the clearest example of the principle behind this whole page: the right server is the one built around the workload.

Spec’d and built from Toronto

A custom build starts with a conversation, and we treat that as the actual work — understanding the workload and its bottleneck before drawing up a configuration, then sourcing, assembling, burn-in testing, and provisioning to spec. Our home data center is in Toronto, giving Canadian data residency and a stable North American base, and we build from Frankfurt, Strasbourg, Amsterdam, Singapore, Panama City, and Miami as well, so a custom machine can sit where its latency, jurisdiction, or power and cooling needs are best met.

You can use our configurator as a starting point to see standard configurations and locations, then tell us where they fall short of your workload — the unusual ratio, the extra GPUs, the specific network or storage, the headroom you want for growth — and we build out from there. For machines that should be run as well as built, our managed hosting covers operations; for teams that want root access and quiet, we hand over a tested machine and step back.

Why work with us?

We spec to the workload, not to the order value, which means the advice sometimes points away from a custom build. If a stock plan covers your needs, we will tell you to take it and save the lead time; if a standard base with a couple of changes is the smarter answer, that is what we will propose. When a custom build is genuinely right, we start from the bottleneck, validate that the parts fit before we assemble them, burn the machine in before handing it over, and leave headroom for the growth you can foresee.

The habit comes from building this hardware for our own sending infrastructure, where an oversized machine is wasted money and an undersized one is a migration we have to do under pressure. We would rather design the server your workload actually needs — or talk you out of customizing at all — than quote an impressive spec that does not fit. A machine built around the workload is the service.

Who this is for, and who it is not

A custom dedicated server is for workloads with genuinely non-standard requirements: unusual memory-to-core ratios, multiple GPUs, large NVMe arrays, high-bandwidth networking, specific storage layouts, particular compliance hardware, or a build that has to leave room for known growth. If your workload is one of those, speccing it from the ground up — starting from the bottleneck and validating that the parts fit — produces a machine that serves the work rather than approximating it.

It is not for ordinary workloads that a stock plan already covers, where customization mainly adds lead time and complexity, nor for buyers who want a bespoke machine because it sounds more serious than a standard one. Read this page as a method rather than a pitch: if your workload falls outside the menu, talk to us about speccing it properly; if it fits the menu, we will point you at the plan that already covers it. The least customization that meets the requirement is the service.