VPS Guide

Container-Based VPS Explained

Container-based VPS costs less than KVM because it shares more — and the things it shares are precisely the ones that matter when the workload has specific requirements.

Overview

A container-based VPS looks like a server from the inside. You SSH in, you have a filesystem, you have processes, you have network interfaces. What you don't have is a kernel. The host's kernel is shared across all containers on the physical host, which means kernel-level configuration — loading modules, adjusting kernel parameters, using features that require kernel access — isn't available to you. For most web applications, this is irrelevant. For specific workloads, it is a hard constraint.

How to think about it

Full virtualization (KVM, VMware) runs a complete virtual machine with its own kernel on top of a hypervisor. Each VM is fully isolated — different kernels, different kernel versions, different kernel configurations. The isolation is complete. The overhead is higher because each VM runs a full OS stack.

Container-based VPS (OpenVZ, LXC) shares the host kernel across all containers. Each container gets its own filesystem, process space, and network namespace, but the kernel is common. The overhead is lower — containers start faster, use less RAM overhead, and allow more instances per physical host. The trade is kernel isolation. Containers can't run different kernel versions, can't load kernel modules, and can't use features that require kernel-level access.

How it works

For standard web applications — web servers, databases, scripting runtimes, application frameworks — the shared kernel is invisible. These applications run in userspace and interact with the kernel through standard system calls that containers handle normally. The performance of a PHP application or a Node.js API on a container-based VPS is comparable to a KVM-based VPS with similar allocated resources.

The constraints appear at the edges. Docker inside a container-based VPS is constrained or unavailable — Docker needs kernel capabilities that shared-kernel environments restrict. Custom kernel modules are unavailable. Certain system calls that require elevated kernel privileges may be blocked. Low-level networking configurations, kernel parameter tuning via sysctl, and custom security modules operate within what the host kernel and container runtime permit.

Resource isolation in container-based VPS is enforced through cgroups rather than hypervisor hardware partitioning. CPU and RAM limits are soft enforced — the container is restricted to its allocation, but the mechanism is different from KVM's hardware-level partitioning. In practice, resource enforcement is reliable on modern container implementations. The distinction matters more for security isolation than for performance characteristics.

Where it breaks

Running Docker inside a container-based VPS is the most common collision. Docker requires kernel capabilities — specifically the ability to create namespaces and control groups at a level that OpenVZ and some LXC implementations restrict. Some providers have worked around this; many haven't. Checking whether Docker is supported before provisioning a container-based VPS for a Docker-dependent workflow is not optional.

Security-sensitive workloads may require kernel isolation guarantees that shared-kernel environments don't provide. If a container is compromised, the shared kernel is a potential attack surface. KVM VMs are isolated at the hypervisor level — a compromised VM cannot affect the host kernel. Container-based VPS has a smaller isolation boundary. For most applications this is theoretical. For applications handling sensitive data in adversarial conditions, it is a real consideration.

In context

Container-based VPS is cheaper because it's more efficient. More containers per physical host means lower infrastructure cost per unit of allocated resource. For providers offering very low-price VPS plans, container-based virtualization is part of how the economics work. The trade — kernel sharing for lower price — is explicit, even when the hosting page doesn't say 'OpenVZ' in large text.

For workloads without kernel-level requirements, the trade is often favorable. A standard LAMP stack, a Rails application, a Python API, a WordPress installation — none of these need kernel customization. They run identically on container-based and KVM-based VPS. The lower price of container-based VPS is a genuine advantage for these workloads, not a warning sign.

KVM costs more and delivers more isolation. What you give up is the price advantage and the higher VM density that makes container-based VPS cheap. What you get is a full independent kernel, Docker support, kernel module loading, and stronger isolation boundaries. For workloads that need any of these, the KVM premium is the cost of the requirement. For workloads that don't, it's overhead.

From understanding to decision

Before evaluating container-based VPS pricing, the useful question is whether the workload has any kernel-level requirements: Docker, custom modules, specific sysctl parameters, security frameworks that need kernel access. If yes — KVM, no exceptions. If no — the container-based vs KVM distinction is largely invisible in practice, and the pricing comparison becomes the relevant one.

If Docker or container tooling is part of the development workflow→If container-based VPS is being considered primarily for its lower price→If the distinction between virtualization types is still being understood→

KVM vs OpenVZ — the two virtualization types compared directly→How VPS virtualization works at the hypervisor layer→Security implications of different isolation models→Hetzner vs Contabo — KVM infrastructure at different price points→