“VPS” describes three quite different things depending on the provider: a KVM virtual machine with its own kernel, an LXC container sharing the host's kernel, or an OpenVZ container from a lineage that predates both. The price lists rarely say which. We only sell KVM, and this post explains what the other two give up, where they are legitimately better, and how to tell which one you are being sold.
Three ways to slice a host
KVM is hardware virtualisation. The host runs a hypervisor; each guest boots its own kernel on virtual hardware with dedicated memory pages and virtual CPUs mapped onto real cores. The guest cannot see the host or other guests, and the host cannot see inside the guest without the guest's cooperation.
LXC (and its cousins under Proxmox and LXD) is operating-system virtualisation. All containers share the host's kernel and are separated by namespaces and cgroups. It is lighter, boots in a second, and lets the host oversubscribe memory transparently because containers only use what they touch.
OpenVZ is the same idea with an older, heavily patched kernel and its own tooling; its modern successor is Virtuozzo. It is still common at the very bottom of the market because it lets a host pack more containers per machine than anything else.
What you give up in a container
- Your own kernel. No custom kernels, no kernel modules, no sysctl changes the host did not allow. WireGuard, ZFS, Docker with certain storage drivers, nftables features, and anything that says “requires kernel 6.x” depend on what the host runs, which is often several years old.
- Honest RAM. Container memory is a cgroup limit on a shared pool. Providers can and do sell more RAM than the host has, betting that not everyone uses theirs. When they lose the bet, your process is killed by an OOM you did not cause.
- Docker without caveats. Nested containers need privileged flags or user-namespace tricks that many hosts disable. On KVM, Docker runs exactly as it does on your laptop.
- Isolation. A kernel vulnerability on the host is a vulnerability in every container on it. A KVM guest's attack surface is the virtual hardware, which is smaller and better audited.
- Swap, file systems, mounts. Containers get what the host gives them. You cannot partition, use a different file system or mount an image.
Where containers are legitimately better
Density and cost. A host that runs 200 LXC containers instead of 40 KVM guests can charge a fifth of the price, and for a workload that idles 95% of the time, a static site, a small bot, a personal proxy, that price can be honest. Boot time is a second instead of twenty. Memory overhead is near zero, so a “512 MB” container really has 512 MB for your app where a KVM guest spends 100 MB on its own kernel.
The problems begin when the workload is not idle, or when the provider counts on it being idle and it is not. The complaints that fill hosting forums about “steal time” and “random OOM kills” are almost all from oversold containers.
What our VPS plans are
- KVM on Linux hosts, one host kernel we control, one guest kernel you control.
- RAM is dedicated: the sum of guest memory on a host never exceeds the host's physical RAM. No balloon drivers, no swap-backed guests.
- vCPUs are shares of physical cores with a fair scheduler; a plan's vCPU count is the parallelism you get, and sustained 100% use on all of them is allowed.
- Disk is a per-guest NVMe budget, published on the pricing page and enforced by the hypervisor, with unused capacity returned to the pool.
- virtio drivers for disk and network; a UEFI boot that supports any distribution and custom ISOs from the console.
The consequence is that everything in the guides on this blog, from WireGuard hubs to Docker Compose stacks to ZFS, works without asking us anything. The Custom ISO option in the order form exists because it is a real virtual machine.
How to tell what you are being sold
If a price list does not say, run one of these inside the server:
systemd-detect-virt # kvm | lxc | openvz | none
cat /proc/1/environ | tr '\0' '\n' | grep -i container
uname -r # a 2.6 or 3.x kernel in 2025 means OpenVZ
ls /dev/kvm /boot/vmlinuz* 2>/dev/null # present on KVM, absent in containers
On any of our servers, systemd-detect-virt prints kvm, and uname -r prints whatever kernel your distribution installed, because it is yours.
The honest summary
| KVM | LXC | OpenVZ | |
|---|---|---|---|
| Own kernel, modules, sysctls | yes | no | no |
| Docker, WireGuard, ZFS out of the box | yes | sometimes | rarely |
| RAM can be oversold by the host | only with balloons, which we do not use | easily | by design |
| Boot time | 10 to 20 s | ~1 s | ~1 s |
| Kernel overhead per guest | ~100 MB | ~0 | ~0 |
| Fair for sustained load | yes | depends on the host | usually not |
For an idle hobby box, a well-run LXC host is a fine deal. For anything you would be upset to lose, a virtual machine whose memory is really yours is worth the extra dollar, which is why the cheapest plan we sell is still KVM.
