KVM VPS, Shared vCPU or Dedicated vCPU? What the Plan Names Actually Mean

VPS plan pages are full of terms that sound like marketing but change how your server behaves: "KVM", "shared vCPU", "dedicated vCPU", "cost-optimized", "general purpose". Two plans with the same number of vCPUs and the same RAM can differ in price by a factor of five because of them. This post explains what each term means for a developer running PHP, Laravel, WordPress or Docker apps, and how to tell from inside the server what you actually got.

What "KVM VPS" means

KVM (Kernel-based Virtual Machine) is the virtualisation technology built into the Linux kernel. A KVM VPS is a full virtual machine: it runs its own kernel, with virtual hardware, and is isolated from other customers on the same physical host.

In practice that gives you:

• Your own kernel. You choose and upgrade it, load modules, and use features such as WireGuard and nftables directly.
• Docker works normally, with no special provider settings.
• A real swap file and memory limit. The RAM on the plan is yours, not a soft limit shared with the host.

Hetzner, DigitalOcean, Vultr and Akamai (Linode) all use KVM for their cloud servers, as do most mainstream providers today. So "KVM" on a plan page mostly tells you what it is not: an older container-based VPS (OpenVZ or LXC) where every customer shares the host's kernel. Those are still sold by some budget hosts, and they can cause trouble with Docker, custom kernel modules and VPN software. If a very cheap plan doesn't say which virtualisation it uses, ask before you buy.

To check what your server runs on:

systemd-detect-virt

kvm means a KVM virtual machine. openvz or lxc means a container sharing the host's kernel.

Shared vCPU: what you are actually buying

A vCPU is a virtual processor core assigned to your VM. On a shared plan, the host runs more vCPUs than it has physical cores, on the reasonable bet that most customers are idle most of the time. Your vCPU gets a fair share of a real core, and usually much more than that when neighbours are quiet.

That is why shared plans are cheap, and it is fine for the work most small sites do: a PHP request runs for a few dozen milliseconds, then the CPU waits for the database or the network. A WordPress blog, a Laravel app with modest traffic, a few Docker containers behind Caddy: all of these spend most of their time idle and suit shared vCPUs well.

The trade-off is variability. When neighbours on the same host get busy, your share shrinks, and work that needs the CPU for a long stretch slows down.

Dedicated vCPU: when the core is yours

On a dedicated plan, each vCPU is mapped to a physical core (or hardware thread) reserved for you. You get the same CPU performance at 3 am and at peak time, whatever the neighbours do. It typically costs several times as much as a shared plan with the same RAM.

It is worth paying for when your server does sustained CPU work:

• Video or image processing, PDF generation at volume, or builds and CI jobs
• Busy queue workers doing real computation, not waiting on APIs
• A database under constant load, or anything where you promise customers consistent response times
• Game servers and other latency-sensitive workloads

How the providers name them

"Premium", "High Performance" and "Regular Performance" usually mean a newer CPU generation or faster NVMe storage on a shared plan, not dedicated cores. Check the wording on the plan page. For prices at the sizes most small projects use, see our 2027 VPS price comparison and the Hetzner CX23 price tables.

How to tell if a shared vCPU is holding you back: steal time

Linux measures how often your VM wanted CPU time and the host gave it to someone else. It is called steal time, and it is the single most useful number for judging a shared plan.

vmstat 1 10

Look at the last column, st. In top, it is the st value on the %Cpu(s) line.

• 0–2%: normal. Your neighbours aren't affecting you.
• Regularly 5–10% while your app is busy: you are losing noticeable CPU to contention. Worth watching.
• Sustained 10%+ during your busy periods: a dedicated plan, or a move to a different host or provider, will make a real difference.

Steal time only matters while you actually need the CPU. High steal on an idle server is harmless. Check it while you run something heavy, such as a deployment build or an import.

Before you upgrade, make sure CPU is really the problem. Slow pages on a small VPS are more often caused by too little RAM (heavy swapping), too few PHP workers or slow database queries. Our guides to sizing PHP-FPM workers and running out of memory cover those, and vmstat shows memory and swap activity in the same output.

Arm (CAX, Ampere) plans

Arm plans such as Hetzner's CAX line give more cores and RAM for the money than x86 shared plans. PHP, Node, Python, MySQL, PostgreSQL, Redis and most official Docker images run on arm64 without changes. Check first if you depend on a closed-source binary, an old PHP extension built only for x86, or a Docker image with no linux/arm64 build. docker manifest inspect IMAGE lists the architectures an image supports.

Which to choose

• Blog, brochure site, small SaaS, a few containers: shared vCPU. Spend the difference on more RAM.
• Same, but you see sustained steal time during your busy hours: try a different shared plan or location first; it may just be a busy host. Move to dedicated if it continues.
• CPU-heavy work, or response times you have promised customers: dedicated vCPU from the start.

Planning how much downtime you can live with is part of the same decision; our Uptime & SLA Calculator turns 99.9% into minutes per month.

Provider plan names and Hetzner's dedicated-vCPU starting price were checked against each provider's own pricing pages on 30 October 2026.