VPS, VM, and what's underneath | Note

After trying to work out why one VPS costs twice as much as another with identical specs, the distinction clicked. The names describe how much of a machine you pretend to own, not the physical box you get. Everything comes down to whose kernel is running.

VPS vs VM

A virtual machine is a concept. A VPS is a commercial product.

If you spin up a VM on your laptop with VMware or VirtualBox, nobody calls it a VPS. It becomes a VPS when a hosting provider rents it to you with a public IP, allocated vCPUs, memory, disk, and a preinstalled OS. Cloud instances like AWS EC2 or Google Compute Engine are the same thing, packaged with extra platform services like IAM, private subnets, and load balancers.

Every VPS is virtualized, but not every VPS is a full virtual machine. Some run on KVM with full hardware virtualization. Cheap ones use OpenVZ or LXC containers. That gap explains the price difference.

Nobody owns the hardware, not even the VM

Take a physical host with 32 cores, 128 GB of RAM, and a single network card. A hypervisor slices it up. VM A gets 4 vCPUs, 16 GB of RAM, and a virtual network interface. VM B gets 8 vCPUs and 32 GB.

Those allocated vCPUs and virtual interfaces are not dedicated physical hardware reserved for you. They are virtual abstractions. The physical silicon stays shared among all tenants on that box.

A VM gets its own guest kernel and an isolated hardware interface, but it still shares the physical host with neighbours.

The kernel boundary

A VM brings its own guest kernel. A container shares the host kernel. You can see this inside any Ubuntu container:

cat /etc/os-release   # Ubuntu 24.04
uname -r              # host kernel version

The userland is Ubuntu, but the kernel belongs to the host.

How containers isolate

Linux containers rely on two main kernel features:

Namespaces define what a process can see. This covers process IDs, network interfaces, routing tables, filesystem mounts, user mappings, and hostnames.
Control groups limit how much a process can use. The host kernel restricts CPU time, memory consumption, process counts, disk throughput, and network bandwidth. A provider might lock a container to two cores, 2 GB of RAM, and 50 MB/s disk I/O.

A container never emulates hardware. It fences off processes and meters resources on a shared kernel. That makes it faster and lighter than a full VM.

OpenVZ, LXC, and Docker

Both approaches use OS-level virtualization, but they serve different roles:

Docker runs application containers. Each container isolates a single process like Nginx, Redis, or a backend API, built from immutable images for reproducible deploys.
OpenVZ and LXC run system containers. They behave like a standalone Linux server with init systems, SSH access, and background services, while still running on the host kernel.

Docker packages an application. OpenVZ and LXC package a mini operating system environment.

Why container hosting is cheap

Containers skip virtual hardware emulation, separate kernel boots, and dedicated hypervisor memory overhead. Providers can pack hundreds of container instances onto a single machine, which drives down the price.

That density also creates room to overcommit resources. Providers oversubscribe CPU, RAM, and disk bandwidth, betting that most customers will idle. When multiple tenants spike at once, disk I/O stalls and CPU latency climbs. You end up paying for the activity of your neighbours.

What a container VPS costs you

No custom kernels. You can run any Linux userland distribution you want, but you cannot boot custom kernel versions or pass custom boot parameters.
No custom kernel modules. Running modprobe loads code directly into the host kernel, so providers block it. This rules out specialized filesystems, custom network filters, and certain VPN implementations.
No nested virtualization. You cannot run KVM, Android emulators, or hypervisors inside OpenVZ or LXC. The container has no hardware virtualization extensions to expose.
Fragile Docker support. Running Docker inside a container requires nested namespaces, cgroups v2, OverlayFS, and elevated permissions. Unless the provider explicitly configures and guarantees container nesting, Docker will fail on network configuration or storage drivers.
Tricky VPN setups. WireGuard lives inside modern kernels, but running it in a container still requires access to a TUN device, specific capabilities, and permissions granted by the host. If those are missing, you have to fall back to slower userspace implementations like wireguard-go.

Security and isolation

With a VM, a compromised guest is trapped behind a separate kernel. An attacker must break through the hypervisor boundary to compromise the host or reach other tenants.

With a container, every tenant interacts with the same host kernel. A kernel vulnerability, container escape, or misconfigured capability gives an attacker a direct path to the host OS.

Containers can be hardened with seccomp filters, AppArmor profiles, dropped Linux capabilities, and rootless runtimes. But on budget hosting providers, you cannot inspect or audit the host kernel configuration. A KVM instance remains the safer default.

What “dedicated” actually means

Marketing pages use “dedicated” to mean very different things:

Bare metal servers. You rent the entire physical computer. You have exclusive access to the CPU sockets, memory channels, disks, network interfaces, and firmware.
Dedicated hosts. The provider assigns a physical machine exclusively to your account, but you still run virtual machines on top of it. This is usually chosen for compliance, software licensing, or physical isolation.
Dedicated vCPUs. A standard VM where the hypervisor pins your virtual cores to physical CPU threads rather than oversubscribing them. Memory, storage buses, and network cards remain shared.

When a hosting plan claims to be dedicated, check which layer is actually isolated.

The stack

Bare Metal Host
├── Hypervisor ──> Virtual Machine (KVM) ──> Guest Kernel ──> Userland, Docker, Apps
└── Host Kernel ─> System Container (LXC) ──────────────────> Userland, Apps

Both VMs and containers almost always run on shared physical hardware.

Checking your environment

You can check virtualization details directly from the shell:

systemd-detect-virt      # kvm, openvz, lxc, vmware, or xen
hostnamectl
lscpu
dmesg | grep -i hypervisor
virt-what

Some budget hosts mask these flags in /proc or dmesg, so checking provider documentation and pricing tiers remains the most reliable signal.

Which one to pick

Choose a KVM VPS for:

Docker and nested container workloads
Autonomous AI agents and background workers
VPN servers and custom networking tools
Production databases and mission-critical services

A container VPS works well for:

Static websites and reverse proxies
Lightweight Python or Node.js scripts
Chatbots and cron jobs
Experimenting and learning Linux administration

The core rule is simple. If your workload requires kernel modules, custom network stacks, or predictable performance, pay for KVM. If you only need a basic userland to run an HTTP service or a cron script, container hosting saves money.

What to check before buying

Virtualization type. Look for explicit KVM support rather than unspecified “cloud instances”.
Docker support. Confirm whether the provider allows container nesting and OverlayFS.
Network devices. Verify TUN and TAP device access if you plan to run WireGuard or OpenVPN.
Storage architecture. Check whether disks are local NVMe drives or shared network volumes.
Port restrictions. Many budget providers block outbound SMTP, custom VPN ports, or traffic on port 25.
Resource limits. Read the acceptable use policy for CPU throttling thresholds and bandwidth caps.

Both VMs and containers run on shared physical hardware. The real boundary is the kernel. A VM runs its own independent kernel, while a container relies on the host’s kernel and isolates processes with namespaces and control groups. If you need full isolation and unshared hardware, bare metal is the only tier that delivers it.