Dedicated servers: when bare metal is the right answer

A dedicated server is one physical machine used by one tenant. That is all the term settles. It does not say who owns the hardware, who replaces a failed part, where the machine lives or how you reach its console, and those are the questions that decide whether the arrangement suits you. This guide sets out the criteria that genuinely favour bare metal, the ones that count against it, and the work you inherit when you choose it.

Four ways to get a server

People compare dedicated servers with “the cloud” as though there were two options. There are at least four, and they differ on questions that matter more than price.

	Rented dedicated server	Colocation	Virtualised hosting	Public cloud instance
Who owns the hardware	The supplier	You	The supplier, or you	The provider
Who replaces failed parts	The supplier, under their process	You, or hands you pay for	Whoever runs the hosts	The provider, invisibly to you
Isolation	Whole machine is yours	Whole machine is yours	Shared host, logical separation	Shared host, logical separation (some offer dedicated hosts)
Time to add capacity	Days to weeks	Weeks to months, including procurement	Minutes to hours	Minutes
Cost shape	Recurring, per server	Capital for hardware, recurring for space, power and bandwidth	Recurring, usually per unit of capacity	Recurring, usually metered

Colocation deserves a note, because it is dedicated hardware without the rental. You buy the servers, and a facility provides the rack space, power, cooling and network connectivity. You gain the widest choice of hardware and the lowest recurring cost per unit of capacity at scale. You also take the whole lifecycle: procurement, spares, firmware, replacement and eventual disposal of storage media.

When bare metal is the right answer

Choose dedicated hardware because of a requirement, not out of habit. The requirements that really do point that way are these.

• Sustained, predictable, high utilisation. If a workload keeps its hardware busy most of the day, the main benefit of sharing, which is filling idle gaps, disappears, and you are paying for a hypervisor layer to do very little.
• Latency and jitter sensitivity. A shared host can introduce variable delay when other guests compete for CPU, memory bandwidth or storage. Workloads that care about consistency, not just the average, may need the machine to themselves.
• Hardware access. GPUs and other accelerators, specific network cards, high-speed local flash, hardware security modules or particular CPU features are sometimes simpler or only possible when you control the machine.
• Isolation requirements. Some regulatory or contractual positions call for single-tenant hardware. Check what the actual requirement says, because it is often stated as isolation in general and satisfied by a logically separated environment.
• Per-core licensing. Software licensed by physical core can make the choice of processor a financial decision, since a smaller number of faster cores may reduce the licence count for the same performance. That is sometimes only practical when you pick the hardware.
• Predictable, stable workloads you intend to keep for years. Fixed hardware cost against a steady load is easy to forecast and, at scale, often cheaper per unit than metered capacity. Work out the figure for your own load rather than trusting a rule.

When it is the wrong answer

• Many small workloads. One lightly used server per application wastes hardware, rack space, power and licences. The arithmetic below shows how much.
• Spiky or unpredictable demand. Dedicated capacity is bought in whole servers and takes days or weeks to add, so you either size for the peak and pay for idle capacity, or size for the average and fall over at the peak.
• A small team with no hardware skills. Somebody must handle failures, firmware and replacements. If nobody can, the burden falls on the supplier, and then you are buying a managed service whether or not you call it that.
• Fast-changing requirements. If you do not yet know what size you need, the cheapest way to find out is a platform where changing size takes minutes.

The consolidation arithmetic

This example is illustrative, with assumptions stated, not a benchmark. Suppose ten independent workloads, each needing 8 cores at peak and averaging 1.2 cores, and a server with 16 cores.

On dedicated hardware you buy ten servers, one per workload. Each averages 1.2 / 16 = 7.5% utilisation and peaks at 50%. You are paying for ten machines to do the work of about 12 cores on average.

On a virtualised cluster, the question is how many workloads peak at once. Measure it, because it is the key assumption. If at most three peak together, the cluster needs about 3 x 8 + 7 x 1.2 = 32.4 cores, which is just over two 16-core hosts, so three. To survive losing one host, the remaining two must still carry that load, and 32 cores cannot quite do it, so plan four hosts, as the sizing guidance in virtualisation describes. Even then, four hosts replace ten servers.

That is a large difference, and it is exactly why sharing exists. It is also why a workload that runs flat out all day does not benefit: for it, the peak and the average are the same number.

What you inherit when you choose bare metal

With dedicated hardware, resilience is something you design in.

• Redundancy inside the machine. Mirrored or striped-mirrored disks for the operating system and data (RAID 1 or RAID 10), redundant power supplies, error-correcting memory, and redundant network interfaces. Parity RAID such as RAID 5 and 6 saves capacity, but rebuilds on large disks take long, and a further failure during a rebuild loses the array, so weigh it carefully. And remember that none of this is backup. See backup, high availability and disaster recovery.
• A plan for when the machine dies. A server with redundant parts is still one server. For a service that must survive its loss, you need a second one and a way to fail over, which doubles the cost you started by comparing.
• Out-of-band management. Most server hardware has a baseboard management controller that provides remote console, power control and sensor readings independently of the operating system. It is powerful and a prime target. Keep it on an isolated management network, never exposed to the internet, with its firmware kept current.
• Firmware and driver maintenance. BIOS or UEFI, storage controller, network card and BMC firmware all need updates, and some require a reboot you must schedule.
• Provisioning and rebuild automation. If rebuilding a server from bare hardware takes a day of manual steps, then your real recovery time is a day. Network-boot installers and unattended configuration shorten it.
• Monitoring that sees the hardware. Operating-system monitoring cannot see a failing disk or a fan. A few read-only checks illustrate what to look for:

# Disk health summary from the drive's own self-monitoring (read-only)
smartctl -H /dev/sda

# Hardware sensors and the BMC's network settings via the management controller (read-only)
ipmitool sdr list
ipmitool lan print 1

The BMC channel number varies between systems, so use the one your hardware documents.

Lifecycle and spares

Hardware ages, and the cost of keeping it running changes shape. Warranty and support terms usually shape the refresh decision, and many organisations plan around a multi-year cycle, but the right interval depends on your hardware’s warranty, the supplier’s terms and your own failure experience, so use those and not a rule of thumb. Plan a refresh as a migration, because it is one, with the same discovery, rehearsal and rollback steps described in server migration. Plan spares: a holding of key parts, or a supplier commitment to replace them, is part of the cost of dedicated hardware.

When you rent, ask how a failed component is replaced, who initiates it, and what you must do. Do not accept an answer expressed only as a marketing promise. Ask for the process in writing, and see managed infrastructure for the questions to put.

How this goes wrong

• One server presented as high availability. Redundant disks and power were taken to mean the service was resilient, until the motherboard failed.
• Sized for peak, forever. Hardware bought for a launch spike sat at single-digit utilisation for years.
• The management controller was reachable from the internet. It ran old firmware and was compromised before anyone knew it was exposed.
• Backups on the same machine. A controller fault took the data and its copies together.
• No spare plan. A failed part took days to arrive because nobody had agreed who would order it.
• Licensing ignored. A per-core licensed product was deployed on a many-core machine and the bill was a multiple of what the workload needed.

What to do next

If your workloads are small and varied, read virtualisation before committing to hardware. If you need to compare dedicated, colocation, virtualised and cloud options against your own requirements, use the architecture comparison matrix, and if you already know you are moving, the migration readiness planner shows what is in the way.