Why Your Cheap VPS Can't Run Docker

Why OpenVZ can't run Docker

To understand the problem, you need to understand two different approaches to virtualization:

KVM (Kernel-based Virtual Machine) gives you a fully isolated virtual machine with its own kernel. You can install any OS, load kernel modules, control cgroups, and use any filesystem. From Docker's perspective, a KVM VPS is indistinguishable from bare metal.

OpenVZ gives you a container that shares the host machine's kernel. You get your own filesystem and process space, but the kernel — including its modules, cgroup configuration, and filesystem drivers — belongs to the host. You can't change it, upgrade it, or load anything into it.

Docker needs four things that OpenVZ restricts:

• Cgroups. Docker uses control groups to limit CPU, memory, and I/O for each container. OpenVZ either doesn't mount cgroups at all or presents a limited subset that Docker can't work with.
• Overlay filesystem. Docker's default storage driver layers container images using the overlay filesystem. OpenVZ's shared kernel typically doesn't have the overlay module loaded, and you can't load it yourself.
• Network namespaces. Docker creates bridge networks with their own virtual interfaces. OpenVZ restricts network namespace creation because it could interfere with other containers on the same host.
• A modern kernel. Docker requires kernel 3.10 or newer. OpenVZ 6 runs kernel 2.6.32 — released in 2009. Docker flatly refuses to start.

The error messages you're seeing

If you're here because you searched one of these error messages, this section confirms the cause and the fix.

On OpenVZ 6 (kernel 2.6.32)

Your Linux kernel version 2.6.32-042stab123.2 is not supported for running docker.
Please upgrade your kernel to 3.10.0 or newer.

Docker refuses to start entirely. You cannot upgrade the kernel because it belongs to the host. No workaround exists.

On OpenVZ 7 / Virtuozzo 7 (kernel 3.10.x)

The kernel version is new enough that Docker tries to start, then fails on cgroup mounts:

Error starting daemon: Devices cgroup isn't mounted

Your kernel does not support memory swappiness
Unable to find cpu cgroup in mounts
Unable to find cpuset cgroup in mounts
mountpoint for pids not found

Even if Docker starts, the storage driver fails:

'overlay' not found as a supported filesystem on this host.
Please ensure kernel is new enough and has overlay support loaded.

And networking breaks:

Error initializing network controller: Error creating default 'bridge' network:
operation not supported

These errors cascade — fixing one reveals the next. The OpenVZ wiki itself labels Docker inside Virtuozzo 7 as "experimental and not supported in production." (Source: OpenVZ Wiki — Docker inside CT vz7)

The fix for all of these: migrate to a KVM VPS. There is no configuration change, Docker version downgrade, or kernel trick that reliably resolves these on OpenVZ.

Providers still selling OpenVZ

The industry is moving away from OpenVZ, but a surprising number of providers still sell it — often without clearly labeling it on the purchase page:

Hostinger killed OpenVZ in March 2026. As of March 1, 2026, all Hostinger OpenVZ plans are non-renewable. There is no automatic migration to KVM — users must manually set up a new KVM VPS and transfer their data. After expiry, OpenVZ servers and all data are permanently destroyed. If you're a Hostinger customer on an OpenVZ plan, migrate now. (Source: Hostinger support article on OpenVZ to KVM migration)

SSDNodes went through the same transition earlier — they discovered that Docker inside Virtuozzo 7 containers was exhausting the cgroup limit on their host nodes, affecting all tenants on the same physical server. They migrated entirely to KVM and sent warning emails to customers. (Source: LowEndTalk discussion, community reports)

How to check before buying

Before purchase

• Look for "KVM" on the product page. If the page says "VPS" without specifying the virtualization type, be suspicious.
• If the price is under $3/year (not per month — per year), it's almost certainly OpenVZ or LXC.
• The word "container" in the product description (not Docker containers — virtualization containers) usually means OpenVZ or LXC.
• Ask support directly: "Is this KVM or OpenVZ?"

After purchase

If you already have a VPS and aren't sure, run:

systemd-detect-virt

Returns kvm for KVM, openvz for OpenVZ, or lxc for LXC.

Or check:

ls /proc/vz

If the directory exists, you're on OpenVZ.

KVM providers where Docker just works

On a KVM VPS, Docker installs and runs with zero virtualization-related issues. apt install docker.io or the official Docker install script works on the first try.

For Docker workloads, the minimum practical spec is 1 vCPU and 1GB RAM (enough for a few lightweight containers). 2 vCPU and 4GB RAM handles most self-hosted application stacks (Nextcloud, Gitea, reverse proxy, database). If you're running Kubernetes (K3s), start at 4GB RAM.

The LXC trap

LXC (Linux Containers) is another container-based virtualization technology that some providers use. It's better than OpenVZ but still has Docker compatibility problems:

• Unprivileged LXC containers (the default for security) restrict Docker's ability to create network namespaces and manage cgroups. Docker updates have repeatedly broken LXC compatibility — documented breakages occurred in May 2023, February 2024, and July 2025.
• Privileged LXC containers can run Docker but create security concerns for the host (the provider is unlikely to offer this on shared infrastructure).
• Missing kernel modules. /lib/modules is often empty in LXC containers, which prevents containerd from finding required kernel features.

The expert consensus as of 2026: don't attempt to make Docker work inside unprivileged LXC containers on shared hosting. The Proxmox community — the primary LXC user base — officially recommends full VMs for Docker. If your provider uses LXC (check with systemd-detect-virt), expect the same class of problems as OpenVZ, just with different error messages.

FAQ