One of the most common questions we get from customers modernizing their infrastructure is simple: should this run in a VM or a container? With LXD system containers, the answer is often more nuanced — and more interesting — than people expect.
System containers, not application containers
LXD runs system containers, which behave like lightweight virtual machines: a full init system, multiple processes, and a persistent OS environment. This is different from application containers like Docker, which are designed around a single process and an immutable image.
That distinction matters. For lift-and-shift of traditional workloads — the kind that expect a “normal” Linux machine — system containers offer near-VM compatibility with a fraction of the overhead.
Where the density wins show up
Because containers share the host kernel, you avoid the per-VM memory tax of a full hypervisor. On the same hardware, we routinely see meaningfully higher workload density with LXD than with full virtualization, along with near-instant start times.
For development environments, CI runners, and horizontally-scaled services, that density translates directly into lower hardware cost and faster iteration.
When a VM is still the right call
Containers share a kernel, so when a workload needs a different kernel version, strict hardware-level isolation, or to run a non-Linux OS, full virtualization remains the correct choice. The good news: LXD can manage both VMs and system containers from the same API, so you don’t have to pick one tool for the whole estate.