Single-tenant AMD EPYC, with no virtualisation tax.

Why does single-tenancy matter for performance?

Because virtualisation is never free, and sharing is never invisible. The numbers below are the difference between a machine that performs the same every hour and one whose speed depends on strangers.

The noisy-neighbour problem is the other half. On shared hosts, another tenant can degrade your CPU, memory bandwidth, network, and storage I/O without warning. Cloud platforms add credit systems and bandwidth caps to limit the blast radius, but the contention is structural — you are paying for isolation you do not fully have. Single-tenancy removes the question entirely, and with it a whole class of risk: Single-tenancy means physical isolation, removing the class of hypervisor-escape and side-channel risks that exist in multi-tenant environments.

Cost follows performance here rather than fighting it. For identical specifications, bare metal frequently runs 50–70% cheaper than the equivalent hyperscaler instance, before data-egress charges. The savings are largest exactly where cloud is most expensive — sustained, predictable load and high data egress — which is the profile of most production systems once they settle.

The same logic runs through memory and cache. A virtual machine's memory can be reclaimed by the hypervisor under pressure, and its bandwidth is shared with whatever else lives on the host; on bare metal the full memory bus is yours, and NUMA placement is something you control rather than guess at. For workloads that stride across large datasets — analytics, in-memory caches, big database working sets — that steady, uncontested bandwidth is often worth more than raw clock speed.

Consistency is the quiet benefit underneath the headline numbers. Averages rarely hurt you; tail latency does. A shared host can serve a fast average and still spike at the ninety-ninth percentile when a neighbour gets busy, and those spikes are exactly what a user notices or an SLA punishes. A machine you do not share has far less to spike about, which is why latency-sensitive systems keep coming back to it.

How many cores do you actually need?

Fewer than the top of the price list usually suggests. The instinct is to buy core count, but most real workloads are bound by storage and memory bandwidth long before they run out of CPU. A high-volume mail host spends its time writing to the spool, so fast NVMe and a clean network matter more than another thirty-two cores. Many databases want a handful of fast cores and a lot of fast disk rather than a vast, slower core array. We size to the shape of your workload, not to the most impressive line on a datasheet.

There is a money reason to be disciplined about this in 2026. AI demand pushed component prices up sharply through 2025–2026 — NVMe and DDR5 especially — which is why right-sizing the build matters more than chasing the highest core count. An oversized box is not just wasted capital up front; it is capacity you keep paying to power and cool while it sits idle. We would rather right-size a machine with clear headroom and add to it when your numbers genuinely ask, which is also why we keep Genoa in the mix: for plenty of steady production it is the better value, and the newest cores would never be fully used.

A few concrete shapes help. A high-volume mail host is usually memory- and I/O-led: a moderate, fast core count, generous RAM for queues, and the fastest NVMe we can give the spool. A busy transactional database wants high-frequency cores and low-latency storage more than sheer parallelism. A batch-analytics or rendering node is the case that genuinely rewards many cores, and a GPU host wants the high-frequency parts that keep accelerators fed. We match the build to which of those you are.

None of this is guesswork on our side. We would rather start you on a machine with clear, deliberate headroom and watch the real numbers than sell a configuration you grow into over years. When a host does fill up, adding capacity or a second node is a planned step rather than an emergency, and the data from the first machine tells us what the next one should be.

It also means we are comfortable saying a smaller, faster machine beats a larger, slower one for most jobs. Newer cores at higher clocks, more memory channels, and Gen5 NVMe usually do more for a real workload than a big count of older, slower cores, and they draw less power doing it. Performance per watt is part of the sizing conversation now, for your bill and for the data centres we run in.

Operated, not just racked

Renting a server and operating one are different things, and the gap is where most self-managed projects quietly struggle. With us the hardware, the network, and the DDoS protection are ours to keep healthy: we replace a failing drive, chase a flaky link, and stay on call when something physical goes wrong, so a fault at two in the morning is our pager rather than yours. You still get full root and out-of-band IPMI, so nothing about that operation locks you out of your own machine.

What stays yours is the part you want to own: the operating system, the application, the data, and the configuration. We do not log into your workload or hold your stack behind a console. The line is deliberate — we take the undifferentiated weight of running iron on a network, and leave you the part that is actually your business. When you would rather we operate more of the stack, such as the mail platform itself, that is a conversation we are glad to have.

Operating also means watching. We pair out-of-band telemetry from the BMC — temperatures, power draw, fan and hardware health — with in-band metrics from the operating system, and we track drive SMART data and firmware versions across the fleet, so a disk about to fail or a host that has drifted from its golden image is flagged before it becomes your outage. You see the same health data we do.