VPS vs dedicated server: when you actually need bare metal

Almost every version of this comparison is a table with cores and gigabytes on both sides, a note that dedicated servers are "more powerful" and virtual ones are "more flexible", and no conclusion. It settles nothing, because you can buy sixteen cores either way and the specification sheet is the part that does not differ. What actually differs is who else is executing on the same silicon, what happens when your workload is busy at the same moment as somebody else's, how much of the machine exists below the operating system and answers to you, and the point at which paying for a whole box stops being extravagant and starts being the cheaper option. Here is the comparison with those things in it.

What you are actually renting in each case

A VPS on a serious host is a KVM virtual machine — hardware-assisted virtualization, your own kernel, your own modules, your own firewall rules. It behaves like a real machine because in almost every respect it is one. What it is not is alone. A physical host runs a hypervisor and a number of guests, and that hypervisor decides which guest gets a core in any given microsecond, whose disk request is serviced next, and how much memory bandwidth each one may consume. You get a guaranteed share, and on a well-run host that share is genuinely honoured. What you do not get is the machine.

A dedicated server is the machine. No hypervisor sits between your kernel and the silicon unless you install one yourself, there is no other tenant to be scheduled against, and nothing abstracts the storage controller. You get the BIOS, the boot order, the disk topology and an out-of-band management interface that keeps working when the operating system does not. The mental model worth carrying: a VPS is a tenancy, and a dedicated server is a lease on the building.

• CPU time. A VPS receives a scheduled share of physical cores, which is why a "vCPU" is a claim on a thread rather than a piece of hardware. On bare metal, cores are yours whether you use them or not, and nothing preempts them.
• Memory. Virtual machines get an allocation the hypervisor manages, and the host can in principle inspect it. On bare metal the DIMMs are populated for you alone, and the only software touching that memory is software you installed.
• Storage. A VPS lives on a shared array — fast, redundant, and sharing its IOPS budget with neighbours. A dedicated box has its own disks, its own queue depth, and lets you decide the RAID layout instead of inheriting one.
• The network port. Both can be unmetered, but a dedicated server has a physical port rather than a share of one, which matters the moment you are actually saturating it rather than merely capable of it.
• Everything below the operating system. Boot order, firmware settings, kernel-level virtualization features, custom ISOs, disk partitioning before first boot — on a VPS the provider owns that layer, and on metal you do.
• The failure domain. A VPS is normally rebuilt elsewhere if its host dies, because that is what a hypervisor cluster is for. A dedicated server is one physical object, and when a power supply fails it is your outage until somebody walks to the rack.
• Provisioning. A VPS appears in about a minute and can be destroyed just as fast. Bare metal is racked hardware — same-day on stock configurations, and not something you spin up for twenty minutes of work.

The isolation difference nobody puts in the table

There is a dimension to this comparison that hosting pages skip and that matters a great deal if privacy is why you are here in the first place. Virtualization creates a trust boundary that simply does not exist on bare metal, and removing that boundary is a real gain — narrower than the marketing suggests, but real, and worth stating precisely rather than gesturing at.

• A hypervisor can see everything its guests have. Guest memory is host memory, guest disks are host files or volumes, and encryption inside the guest is decrypted by a key that lives in memory the host allocated. This is not a flaw; it is how virtualization works, and it is the reason a VPS can never be private from the machine underneath it.
• Co-tenants are a measured risk rather than a hypothetical one. Two decades of research on cross-VM side channels — shared caches, memory buses, speculative execution — has repeatedly shown information leaking between guests on the same silicon. Mitigations exist and are deployed, and the attacks are difficult and noisy, but the category does not go away because the neighbour never goes away.
• Single tenancy deletes the neighbour outright. Not mitigated, not scheduled apart — absent. Nothing else is executing on those cores, so there is no cache to share, no bus to contend for and no guest to be adjacent to. For a workload holding key material this is the cleanest argument for bare metal there is.
• What single tenancy does not remove is the operator. Whoever racks the machine has physical access to it, and physical access to a running computer beats software every time. The provider changes from "runs the hypervisor above you" to "owns the building around you", which is better, and is not the same as absent.
• Disk encryption changes meaning slightly rather than dramatically. On both, full-disk encryption protects a powered-off machine, a disposed drive and a failed disk sent back under warranty. Neither protects a running box whose volume is already unlocked. What metal adds is a console you can reach at boot — which is the difference between an encrypted server you can actually reboot and one you cannot.

That ordering is worth keeping straight, because it is easy to spend a lot of money on the wrong layer. The account layer decides whether the machine is connected to your name at all; the jurisdiction decides who can compel the operator and how hard that is; the hardware model decides who shares the CPU with you. They are three independent purchases, and for most people the first is worth more than the other two combined. A VPS bought from a burner email and funded in crypto is more private than bare metal bought with a card in your legal name, and it is not close. We go through exactly what changes at the account layer in no-KYC VPS versus a traditional VPS.

Performance: what changes, and what does not

The performance argument for bare metal is real but far narrower than it is usually sold. Modern virtualization overhead on CPU-bound work is in the low single digits, so a workload that fits comfortably inside a VPS plan is not being meaningfully slowed by the hypervisor. What bare metal changes is not the ceiling on a quiet machine — it is the behaviour of a busy one, and the shape of the worst case rather than the average.

• Sustained all-core load is where the gap opens. Bursty work fits neatly into a shared host, but a compiler farm, a video encoder or a simulation that pins every core for hours is precisely the workload a fair scheduler has to arbitrate. On metal there is nothing to arbitrate.
• Tail latency separates the two more than throughput does. Average response times on a well-run VPS are excellent; it is the ninety-ninth percentile that reveals a neighbour flushing a cache or saturating an array. If your users feel the slow requests rather than the median, that is the number that matters.
• Storage-bound work benefits most and is the most commonly overlooked. Local NVMe with a queue nobody else is filling behaves differently from a shared array under load — databases doing many small synchronous writes are the clearest case.
• Very large memory is often simply unavailable virtually. Above a few hundred gigabytes you are into configurations that only exist as physical machines, and an in-memory dataset that fits in 768 GB of DDR5 has no virtual equivalent at a sane price.
• Nested virtualization wants the real thing. Running Proxmox, ESXi or a fleet of your own VMs on top of somebody else's hypervisor works, but you are paying the tax twice and inheriting their scheduling decisions underneath yours.
• Anything that wants hardware directly needs hardware. Custom kernels with exotic modules, precise NUMA pinning, PCIe passthrough, hardware RAID controllers, real-time tuning — these are the cases where "it is basically a real machine" stops being true.

The opposite list is just as important, and it is longer than most people expect. A web application serving normal traffic, a reverse proxy, a mail relay, a WireGuard endpoint, a Bitcoin or Monero node, a CI runner, a bot, a personal cloud — none of these will go measurably faster on bare metal, because none of them are limited by the hypervisor. They are limited by network round trips, by disk sync, by an upstream API, or by nothing at all because the machine is idle most of the day. Buying metal for a workload in that list purchases a worse cost profile and no speed, and it is the single most common mistake in this whole decision.

The cost crossover, with real numbers

The pricing intuition most people carry is that dedicated servers are the expensive option. That is true at the bottom of the range and stops being true surprisingly early, because virtual plans price a slice at a premium while metal prices the whole machine at wholesale. It is worth doing the arithmetic on actual plans rather than in the abstract.

• At the small end there is no contest. A 2 GB instance at $3.99 a month has no bare-metal equivalent, and inventing one would mean paying sixteen times as much for capacity you would never touch.
• The crossover sits around the middle of the VPS range. Our 8 vCPU, 32 GB plan is $47.99 a month; the entry dedicated machine is $64 and brings six real cores, 64 GB and two 1 TB NVMe drives. Sixteen dollars buys double the memory, several times the raw storage and cores nobody else is scheduled on.
• Above the crossover metal wins outright. The largest VPS — 16 vCPU, 64 GB, 800 GB — is $89.99; a Ryzen 9 with sixteen physical cores, 128 GB of DDR5 and 4 TB of NVMe is $115. Twenty-five dollars is not a premium for that difference, it is a discount.
• Consolidation is where the real saving hides. Six or seven separate VPS instances that each idle at ten per cent are six or seven separate reservations you pay for continuously. One dedicated box running your own hypervisor turns that into a single bill and a pool of capacity that any one service can borrow when it needs to.
• Unused capacity is the cost that runs the other way. A dedicated server bills the whole machine whether you use eight cores or none of them, and paying for 48 threads to run a service that needs two is the same waste as the previous point in the opposite direction.
• Billing granularity is a genuine difference and not a footnote. VPS plans bill hourly, so an experiment that lives for an afternoon costs pennies and stops costing anything the moment you destroy it. Racked hardware is a monthly commitment because a technician physically installed it.

IPMI: the difference in how you operate the machine

The feature that changes day-to-day life on bare metal is rarely mentioned in comparisons, because it is invisible until the moment you need it. Out-of-band management — IPMI, or KVM-over-IP — is a small independent computer on the motherboard with its own network connection, and it works when the main system is off, unbootable or locked out. On a VPS the equivalent is a support ticket.

• You get a console before the operating system exists. Watch POST, enter the BIOS, change boot order, read the panic that scrolled past — all the things that are trivial on a machine in front of you and impossible on a machine you can only reach by SSH.
• You can mount your own ISO and install what you actually want, including an operating system your provider never templated, with a partition layout you chose rather than one you inherited.
• You can type a passphrase at boot. This is what makes full-disk encryption practical on a remote machine: an encrypted volume needs a key at every start, and without a console the only options are storing the key on the box, which defeats the purpose, or unlocking over the network from a pre-boot environment you had to build yourself.
• You can recover from your own mistakes without involving anyone. A firewall rule that locked out SSH, a broken fstab, a kernel that will not boot — all of them are a five-minute fix at the console and a support conversation without one.
• You can power-cycle on your own authority. A hung machine comes back when you decide it does, rather than when a ticket is read.
• It is a separate attack surface and deserves to be treated as one. Management controllers have a poor security history, so put the interface behind a VPN or an allow-list, change the default credentials immediately, and never expose it to the open internet.

Reliability: the failure domain you inherit

This is the axis where the virtual side wins, and it is usually left out of comparisons written by people selling metal. A dedicated server is one physical object with one set of power supplies, one motherboard and one set of disks. Redundancy is something you build on top of it, not something it comes with. Virtualization exists in part to abstract exactly that, and pretending otherwise leads to unpleasant surprises.

• Hardware fails on hardware's schedule. Power supplies, DIMMs, fans and NVMe drives all have failure rates, and on a single box each one is a single point of failure until you have paired it.
• A VPS is designed to survive its host. Instances normally restart on other hardware when a physical node dies, which converts a hardware failure into a reboot instead of an outage measured in hours.
• RAID protects against a dead disk, not against a mistake. It is not a backup, it does not survive a deleted directory or a bad migration, and every guide that conflates the two has cost somebody their data.
• Snapshots are usually a virtual-only luxury. Taking a full instance snapshot before a risky change and rolling back in seconds is a workflow bare metal does not natively give you.
• Recovery time is different in kind. A failed VPS is rebuilt from an image in minutes; a failed dedicated server waits for a human to reach the rack and for a replacement part to exist, which is why in-band monitoring and off-machine backups matter more here.
• The honest mitigation is the same either way and people skip it either way: backups that live somewhere the machine itself cannot reach, and a restore you have actually performed once on purpose.

A decision procedure that takes ten minutes

1. 01Measure before you theoriseLook at what your current machines actually do. Sustained CPU above roughly sixty per cent, disk queues that never drain, or memory pressure are real signals. An idle box that feels slow is almost never short of hardware.
2. 02Name the resource you are short ofCores, memory, IOPS, bandwidth or isolation — they have different answers. Being short of memory is often one plan larger; being short of predictable latency is a different class of machine.
3. 03Check whether you need anything below the OSNested virtualization, a custom ISO, an exotic kernel module, a specific RAID layout, disk encryption you unlock at a console. If any of these are on your list, the decision is already made.
4. 04Add up the whole fleet, not one instanceCompare your total monthly spend across every server against one machine that would replace them. Consolidation is where bare metal usually wins, and it is invisible if you compare one to one.
5. 05Ask how spiky the load isBursty and unpredictable favours virtual, because you can add and destroy capacity hourly. Steady and continuous favours metal, because you are paying for a reservation you actually use.
6. 06Decide how much a bad hour costsIf an outage measured in hours is genuinely damaging, one physical machine is the wrong shape without a second one behind it. A pair of VPS instances in different regions may serve you far better than one large box.
7. 07Separate privacy from hardwareIf the reason you are considering metal is privacy, check first that the account carries no identity, that the balance is funded in crypto, and that the machine itself is hardened. Those three cost nothing and matter more than the hardware model does.
8. 08Test on the cheap side firstDeploy the largest VPS for a month and put the real workload on it. If it is comfortable, you have your answer for a fraction of the price. If it is saturated, you now know exactly which resource to buy.

When a VPS is simply the right answer

It is worth stating plainly, because a page on a hosting site has an obvious incentive to say otherwise: most workloads belong on a VPS, and moving them to bare metal makes them more expensive and no better. These are the cases where virtual is not a compromise at all.

• The workload is small, steady and unremarkable. A site, an API, a bot, a proxy, a personal service — the machine is idle most of the day and the hypervisor is not what limits it.
• You want more than one location. Several small instances across regions beat one large machine for latency and for resilience, and cost less than the metal equivalent.
• The lifespan is short. Anything measured in hours or days should bill in hours, not months.
• You value the rebuild button. Snapshot, roll back, redeploy from a clean image — this workflow is genuinely valuable and it belongs to the virtual side.
• You need it immediately. About a minute versus same-day is decisive when you are in the middle of something.
• The privacy requirement is at the account layer. If the goal is that no name is attached to the server, that is settled at signup and payment, not by the hardware model.

Mistakes that make this choice worse than a coin flip

• Buying bare metal for a workload that has never once saturated a VPS, and paying for idle silicon every month to fix a problem that was never measured.
• Comparing one dedicated server against one VPS instead of against the fleet it would actually replace, which hides the only cost argument that reliably favours metal.
• Assuming single tenancy makes the machine private from its host, when it removes the neighbour and leaves the operator exactly where it was.
• Treating a single physical box as more reliable than a virtual instance because it is "real", when it is the one with no cluster underneath it.
• Consolidating six services onto one machine and inheriting a shared failure domain nobody planned for, so that one bad reboot now takes down everything at once.
• Exposing the IPMI interface to the internet with its default credentials, which hands away a computer that can reinstall the operating system.
• Migrating to metal for tail latency without ever measuring the ninety-ninth percentile, and having no way to tell afterwards whether it helped.
• Choosing hardware to solve a jurisdiction problem, or a jurisdiction to solve a hardware problem — they are unrelated layers and swapping one for the other fixes neither.

The summary that survives contact with reality is unglamorous. Start virtual, because it is cheap, immediate and reversible, and because most things never outgrow it. Move to metal when you can name the resource you are short of and point at the measurement, when the fleet you are already paying for costs more than the machine that would replace it, when you need the layer below the operating system, or when removing every other tenant from your silicon is a requirement rather than a preference. Both are the same offshore network, the same 14 regions, the same prepaid crypto balance and the same absence of identity checks — so this is a question about the shape of your workload, and not about how private the server is.