Most people meet the word "container" before they meet the thing itself. It shows up in a README, a job posting, or a coworker's terminal, usually followed by a command that just works. The natural next guess is "a lightweight virtual machine." That guess is close enough to be dangerous—it explains just enough to stop you from asking what is actually going on.
It is worth stopping. The concept underneath containers is simple, and understanding it changes how you use Docker, Podman, or any tool built on the same idea.
Two words people use interchangeably: image and container
Before anything else, separate two terms that get flattened into one in casual conversation.
An image is a snapshot: a read-only bundle of files—application code, a runtime, libraries, configuration—packaged together with instructions for how to run it. It does nothing on its own. It just sits there, the same way a zip file sits there.
A container is what you get when you run an image. It is a live process on your machine, with its own filesystem view, its own process list, and its own network interface, built from that image plus a thin writable layer on top.
One image can produce many containers, the same way one class can produce many objects, or one recipe can produce many meals. Confusing the two is the single most common source of beginner confusion—"I changed a file in the container and it disappeared" almost always traces back to this distinction.
It is not a virtual machine
A virtual machine simulates an entire computer: virtual hardware, a full guest operating system, its own kernel, all managed by a hypervisor sitting between the guest and the real hardware. Starting one means booting an OS.
A container does not do any of that. It runs as an ordinary process on the host's existing kernel. There is no guest OS to boot, no virtual hardware to emulate—just the host kernel enforcing strong boundaries around what that process can see and touch.
That difference is why containers start in milliseconds instead of the seconds or minutes a VM needs, and why a container image measures in megabytes where a VM image measures in gigabytes. It is also why the isolation is a different kind of guarantee: a VM is isolated by hardware-level virtualization; a container is isolated by the host kernel's own accounting rules.
What a container actually isolates
The host kernel gives each container its own view of several things a process would otherwise share with everything else on the machine:
- A filesystem, built from the image's layers, so the container sees its own
/, not the host's. - A process tree, so the container's process 1 does not know the host has thousands of other processes running.
- A network stack, so the container gets its own IP and ports before anything is deliberately published to the host.
- Resource limits, so a container can be capped at a fixed slice of CPU and memory instead of competing unbounded for the host's.
None of that requires a second kernel. It requires one kernel willing to draw careful lines around a process—which is exactly what containers ask it to do.
Why this matters for shipping software
The isolation is interesting, but the reason containers took over software delivery is more practical: an image is a single, versioned artifact that behaves the same way in every environment that runs it.
"Works on my machine" is a version-mismatch problem in disguise—a different runtime version, a missing system library, a config file that only exists on one laptop. A container image collapses all of that into one thing: build it once, and the environment it describes travels with it, unchanged, from a laptop to a CI runner to production.
That is the property the rest of this series builds on. It is also the property the From Laptop to Production series assumes as a starting point—this series exists to make sure that assumption is actually true for you before you get there.
Docker and Podman are tools, not the concept
Everything above describes what a container is. Docker and Podman are two different engines—programs that build images, run containers from them, and manage the whole lifecycle. They are not competing definitions of "container"; they are two implementations of the same underlying idea, built on the same kernel features, largely compatible with the same image format.
That distinction matters because it means the concepts in this article do not change depending on which tool you pick up next. The commands will differ in small ways. What a container fundamentally is will not.
Common misconceptions
- "A container is a lightweight VM." It is not virtualized at all—it is an isolated process on the host's own kernel. That is why it is lightweight.
- "Changes I make inside a running container are safe." They live only in that container's writable layer. Remove the container, and they are gone unless you deliberately persisted them.
- "An image and a container are basically the same thing." An image is a static artifact; a container is a running instance of one. You can run the same image many times over.
- "Docker is the definition of a container." Docker popularized the format, but it is one engine among several implementing the same underlying concept.
Practical checklist
Before moving to the next part, you should be able to say yes to each of these:
- I can explain the difference between an image and a container in one sentence.
- I can explain why a container starts faster than a virtual machine.
- I know that a container's filesystem changes disappear when the container is removed, unless I explicitly persist them.
- I understand that Docker and Podman are two engines implementing the same container concept, not two different concepts.
Next in the series: Installing Docker and Running Your First Container. We will move from theory to practice—install a real engine and run, inspect, and stop your first container.