How to buy a dedicated server: specs, pricing and pitfalls

A dedicated server is the last piece of infrastructure many teams buy without measuring anything. They pick the tier that "sounds right", discover six weeks later that the disk is the bottleneck, and then pay for a migration they could have avoided with an afternoon of profiling. This guide is the afternoon of profiling.

When dedicated actually beats the cloud

Virtual machines are the default for good reasons: they provision in seconds, they scale elastically, and someone else handles the hardware. Dedicated hardware wins in a narrower but very real set of cases.

• Sustained load. Cloud pricing assumes bursty use. If your machine runs at 60%+ around the clock, dedicated is typically 40–70% cheaper for equivalent performance.
• Predictable latency. No noisy neighbours competing for the same cores, cache and disk queue. For game servers and trading systems, p99 latency is the product.
• Heavy I/O. Direct-attached NVMe outruns network-attached block storage by a wide margin, and it does so consistently.
• Large egress. Cloud bandwidth is billed per gigabyte and adds up brutally. Dedicated hosts usually bundle tens of terabytes.
• Compliance and data residency. Sometimes you need to point at a specific machine in a specific building.
• Licensing by socket or core. Some enterprise software is licensed per physical socket, which changes the economics entirely.

CPU: clock speed versus core count

The single most common sizing error is buying many slow cores for a workload that can only use one of them at a time.

Before you specify anything, measure how your workload actually uses the CPU you already have:

# Per-core utilisation — are you saturating one core or all of them?
mpstat -P ALL 2 10

# Which process, which thread?
pidstat -t -p <pid> 2 5

# Run queue depth: sustained > number of cores means you are CPU-bound
vmstat 2 10        # column 'r'

# Steal time on an existing VM: >2% means the hypervisor is overcommitted
top -bn1 | grep '%Cpu'

If mpstat shows one core pinned at 100% while eleven sit idle, buying a 32-core machine changes nothing. Buy clock speed.

Memory: quantity, then ECC, then channels

RAM is the cheapest performance upgrade in existence right up to the moment you run out, at which point everything falls off a cliff. Size it so that your working set — hot database pages, application heap, filesystem cache — fits with headroom.

• ECC memory detects and corrects single-bit errors. On a machine holding a database you care about, this is not optional. Silent corruption is far more expensive than the premium.
• Channel population affects bandwidth. Four 16 GB modules across four channels comfortably outrun one 64 GB module for memory-bound work.
• Swap should exist as a safety valve but never as a working surface. If you are swapping regularly, you are under-provisioned.

# Is your memory pressure real, or just page cache?
free -h                      # 'available' is the number that matters
vmstat 2 10                  # si/so should stay at 0

# On modern kernels, the honest pressure signal:
cat /proc/pressure/memory    # 'some avg60' consistently > 10 = trouble

Storage: where most people guess wrong

Sequential throughput is the number vendors advertise. Random IOPS and latency are the numbers that determine whether your database feels fast.

RAID choices that actually matter

• RAID 1 — mirror. Simple, survives one disk, halves usable capacity. The sane default for a two-disk box.
• RAID 10 — mirrored stripes. Best all-round choice for databases: good write performance and fast rebuilds.
• RAID 5/6 — parity. Efficient on capacity, poor on random writes, and rebuild windows on large modern drives are long enough to be genuinely risky.
• No RAID — acceptable only when the node is stateless and rebuildable in minutes.

# Measure what you actually have (careful: this writes 4 GB)
fio --name=randread --ioengine=libaio --direct=1 \
    --rw=randread --bs=4k --numjobs=4 --iodepth=32 \
    --size=1G --runtime=60 --group_reporting

# Where is time actually going?
iostat -x 2 10     # look at r_await / w_await and %util

Network: read the fair-use clause

Three separate numbers hide behind the word "bandwidth":

1. Port speed — 1 Gbps, 10 Gbps. The maximum instantaneous rate.
2. Transfer allowance — how many terabytes per month before overage or throttling.
3. Commit level — for 95th-percentile billing, the sustained rate you have paid for.

"Unmetered 1 Gbps" almost always means "1 Gbps port, subject to a fair-use policy". Find that policy and read the actual threshold. Then check the things that are easy to forget:

• Is DDoS mitigation included, and at what capacity? Always-on or triggered?
• How many IPv4 addresses are included, and what does an extra /29 cost?
• Is IPv6 provided, and is it routed or just a single address?
• What is the network's peering profile? A cheap host with poor transit will feel slow to your users regardless of port speed.

Location and latency

Distance is physics: roughly 1 ms of round-trip time per 100 km of fibre, before switching overhead. Place the machine near whichever party is most latency-sensitive — usually your users, sometimes your data source.

For a global audience, one machine cannot serve everyone well. Put the origin near your database and push static assets to the edge, rather than paying for a second dedicated box you will only half use.

Managed, unmanaged, or somewhere between

Be honest about who will apply the kernel patch at 2 a.m. on a Sunday. Unmanaged is only cheaper if that person exists and has time.

Pre-purchase checklist

1. Exact CPU model — not "Xeon", but the SKU, so you can look up its clock and cache.
2. RAM quantity, type, ECC yes/no, and how the modules are distributed across channels.
3. Disk model, interface, endurance rating (TBW) and RAID level.
4. Port speed, monthly transfer allowance, and the fair-use threshold in writing.
5. Included IPv4 count, IPv6 availability, cost of extra addresses.
6. DDoS mitigation capacity and whether it is always-on.
7. Out-of-band access: IPMI/iDRAC/iLO, or only a support ticket?
8. Hardware replacement SLA — hours to swap a failed disk or PSU.
9. Backup: included, extra, or your problem entirely?
10. Setup fee, contract length, and the price after any promotional period ends.
11. Reinstall and rescue-mode availability in the control panel.
12. Migration assistance if you are moving from another host.

The first hour on a new machine

Before anything goes into production, spend an hour on hygiene. It is the cheapest security work you will ever do.

# 1. Patch everything
apt update && apt full-upgrade -y     # or dnf upgrade -y

# 2. A non-root user with sudo
adduser ops && usermod -aG sudo ops

# 3. Key-only SSH on a non-default port
#    /etc/ssh/sshd_config
#      Port 2222
#      PermitRootLogin no
#      PasswordAuthentication no
#      KbdInteractiveAuthentication no
systemctl restart ssh

# 4. Default-deny firewall
ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp
ufw allow 80,443/tcp
ufw enable

# 5. Brute-force protection
apt install -y fail2ban && systemctl enable --now fail2ban

# 6. Unattended security updates
apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# 7. Verify the hardware matches the invoice
lscpu | head -20
free -h
lsblk -o NAME,MODEL,SIZE,ROTA,TYPE
nvme list 2>/dev/null

The costs that appear later

Buy for the bottleneck

Profile the workload you already have. Find the resource that saturates first. Buy generously on that axis, adequately everywhere else, and put the savings into backups and monitoring. A modest machine that is correctly matched to its bottleneck will beat an expensive one that is not — every time, and for less money.

Our current dedicated configurations are listed on the dedicated server page, and you can compare them against VPS options in VPS hosting. For hardening a Windows machine specifically, see the RDP setup and hardening checklist.