Ask ten developers what a container is and at least eight will say "a lightweight virtual machine". It's a handy shortcut. It's also wrong in exactly the places that matter: security, performance, and why your Docker setup behaves differently on a Mac than on a Linux server.

Here's a one-line experiment that shows the real difference. On a Linux machine with Docker, run:

uname -r                          # the host's kernel version
docker run --rm alpine uname -r   # the container's kernel version

Both commands print the same thing. The container is running a different Linux distribution, Alpine, but it's using your kernel. A virtual machine would print its own. That one fact explains almost everything else.

The mental model: houses vs flats

A virtual machine is a detached house. It has its own foundations, plumbing and electricity. Complete independence, but every house needs all of that built from scratch.

A container is a flat in an apartment building. Your own front door, your own furniture, your own lock. But you share the foundations, the water main and the wiring with everyone else in the building.

The shared foundation, in computing terms, is the operating system kernel.

How a virtual machine works

A VM emulates an entire computer. A piece of software called a hypervisor sits between the hardware and the VMs, handing each one virtual CPUs, memory, disks and network cards.

Each VM then boots a complete operating system, with its own kernel, on that virtual hardware. As far as the guest OS knows, it owns a real machine.

• Type 1 hypervisors run directly on the hardware: KVM, Xen, VMware ESXi, Hyper-V. Cloud providers use this kind; an EC2 instance is a VM.
• Type 2 hypervisors run as an application on your desktop OS: VirtualBox, VMware Workstation, Parallels.

Modern CPUs have hardware support for virtualisation, so VMs run at close to native speed. The cost isn't so much speed as weight: every VM carries a full OS, which takes memory, disk space, and boot time.

How a container works

A container doesn't emulate anything. It's a normal process on the host, running on the host's kernel, with two Linux kernel features wrapped around it:

• Namespaces control what the process can see. It gets its own view of process IDs, network interfaces, mount points and hostname. Inside the container, your app thinks it's PID 1 on a machine of its own.
• Control groups (cgroups) control what the process can use: how much CPU, memory and I/O it's allowed.

Add a layered filesystem for the image, and that's essentially Docker: an isolated, resource-limited process with its own files. Since there's no OS to boot, a container starts about as fast as the process inside it.

Three things that surprise people

1. Docker on your Mac or Windows laptop is running a VM

Linux containers need a Linux kernel. macOS and Windows don't have one, so Docker Desktop quietly runs a small Linux VM (on Windows, typically through WSL 2) and runs your containers inside it. That's why file syncing between your laptop and a container can feel slow there, and why it's fast on a Linux server.

2. Containers usually run inside VMs anyway

In the cloud, the question is rarely "containers or VMs". Your containers run on a VM: an EC2 instance, a Kubernetes node, a managed container service. The VM gives isolation from other customers; the containers give you a clean way to package and deploy your app.

3. Root in a container can be closer to root on the host than you think

Because the kernel is shared, the isolation is only as strong as the kernel's features and your configuration. A kernel vulnerability, a container running as root with extra privileges, or mounting the Docker socket into a container can all let a process reach the host. That's why good images run as a non-root user and avoid --privileged.

The middle ground: microVMs and sandboxed runtimes

For running untrusted code, like other customers' functions, the industry has built options in between. Firecracker, created by AWS for Lambda and Fargate, starts tiny VMs fast enough to feel like containers. gVisor, from Google, puts a user-space kernel between the container and the host. Kata Containers runs each container inside a lightweight VM.

You probably won't configure these yourself, but they're worth knowing about. They exist precisely because a shared kernel isn't always enough isolation.

So which should you use?

Reach for containers when:

• You want the same environment in development, CI and production.
• You run several services (app, queue worker, Redis) and want them packaged consistently.
• You deploy often and want fast, repeatable releases.

Reach for VMs when:

• You need strong isolation between tenants or untrusted workloads.
• You need a different operating system or a specific kernel version.
• You're running something that expects a full machine, like legacy software or a desktop environment.

In practice, most web teams use both: VMs as the servers, containers as the way apps get onto them.

The takeaway

A container isn't a small VM. It's a process with blinkers on, sharing the host's kernel. That's why it starts instantly and packs densely, and also why it needs a bit more security care than a VM.

Run that uname -r experiment once and the distinction sticks for good.

Where do you draw the line in your own setup: what runs in containers, and what still gets its own VM?