Containers vs virtual machines

A virtual machine emulates hardware. A hypervisor runs several complete guest operating systems, each with its own kernel, drivers and init system. VMs are strongly isolated, but each one costs gigabytes of disk, a slice of reserved RAM and tens of seconds to boot.

A container is just a normal process (or a few) on the host, started with kernel features that make it look like it has its own machine: its own filesystem, process list, network interfaces and hostname, plus limits on CPU and memory. There is no guest kernel; every container shares the host's Linux kernel. So containers start in milliseconds, add almost no memory overhead, and you can run hundreds on one machine.

What a container gives you in practice:

• Packaging: the app and its exact dependencies (runtime, libraries, config) travel together as an image, so "works on my machine" becomes "works on every machine with Docker".
• Isolation: apps with conflicting dependencies run side by side.
• Disposability: containers are cheap to create and destroy, which encourages immutable, reproducible deployments.

The trade-offs follow from the shared kernel. Linux containers need a Linux kernel, so Docker Desktop on macOS and Windows quietly runs a small Linux VM to host them. Isolation is weaker than a VM's: a kernel vulnerability can affect every container on the host, which is why multi-tenant platforms sometimes put containers inside lightweight VMs.

Containers and VMs aren't rivals. In the cloud, your containers usually run inside VMs.