If you have spent any time around backend engineering, you have heard someone say “just build the image and spin up a container.” Those two words — image and container — get used so casually that many developers use them interchangeably for years without ever being forced to explain the difference. This guide exists to fix that, permanently, by building the concept up from first principles instead of just handing you a one‑line definition to memorize.

Here’s the one‑line definition anyway, because you’ll want it early: a Docker image is a read‑only blueprint — a packaged snapshot of an application and everything it needs to run. A Docker container is a running (or stopped) instance created from that image — a live, isolated process with its own filesystem, network, and resource limits. An image is like a recipe; a container is like the meal you cooked from it. You can cook the same recipe a hundred times and get a hundred separate meals. You can run the same image a hundred times and get a hundred separate containers.

A Short History

To understand why Docker split things this way, it helps to know where containers came from. Long before Docker existed (2013), Linux already had the low‑level building blocks: chroot (1979) let a process see a restricted view of the filesystem; cgroups (control groups, added to the Linux kernel around 2007 by Google engineers) let the kernel limit how much CPU, memory, and I/O a group of processes could use; and namespaces (added gradually through the 2000s) let the kernel give a process its own private view of things like process IDs, network interfaces, and mount points.

Projects like LXC (Linux Containers) combined these primitives into a usable toolset well before Docker arrived. What Docker did — and this is the actual historical contribution — was wrap those primitives in a simple, standardized, shareable packaging format (the image) and a friendly command‑line workflow (docker build, docker run, docker push). Docker didn’t invent containers; it made them portable and easy enough that every developer could use them, the same way USB didn’t invent the idea of a cable but made every cable interchangeable.

Before containers, deploying software reliably was genuinely painful, and the pain had a name every experienced engineer has heard: “it works on my machine.” A developer would write code that ran perfectly on their laptop, hand it off, and it would break in staging or production because of subtle differences — a different version of Java, a missing environment variable, a library installed in a different location, a different operating system patch level.

Virtual machines (VMs) were the earlier attempt to solve this. A VM packages an entire operating system — kernel included — on top of a hypervisor, so you get full isolation. But that completeness is also the weakness: each VM might be gigabytes in size and take minutes to boot, because it’s booting an entire OS, not just starting your app.

The core insight was: most of the isolation guarantees people wanted from a VM didn’t actually require a separate kernel. If the host Linux kernel could just fence off what a process could see and use (namespaces + cgroups), you could get “VM‑like” isolation at a fraction of the size and startup time. Docker images and containers are the direct product of that insight — the image is the “what to run,” and the container is “the kernel‑isolated process actually running it.”

Let’s define every term precisely, in plain English, before going further.

Docker Image

A Docker image is an immutable, read‑only template made up of layered filesystem snapshots plus metadata (like the default command to run, exposed ports, and environment variables). “Immutable” means once built, an image doesn’t change — if you need a new version, you build a new image with a new ID or tag. Images are stored as a stack of layers, where each layer represents one filesystem change (e.g., “installed Python,” “copied application code”).

Docker Container

A Docker container is a running instance of an image. When you run a container, Docker takes the image’s read‑only layers and adds one thin, writable layer on top. All the changes that happen while the container runs — new files, modified files, logs — are written to that writable layer. The container also gets its own isolated process tree, network stack, and filesystem view via Linux namespaces, and its resource usage is capped using cgroups.

Key vocabulary, explained simply

• Layer — one saved “diff” of filesystem changes. Images are built from many layers stacked on top of each other, like transparent sheets stacked to form one picture.
• Namespace — a Linux kernel feature that gives a process its own private view of something (process list, network devices, hostname, mounted filesystems) so it can’t see or interfere with other processes’ versions of that thing.
• cgroup (control group) — a Linux kernel feature that limits and measures how much CPU, memory, disk I/O, and network bandwidth a group of processes can use.
• Union filesystem (e.g., OverlayFS) — a filesystem technique that transparently overlays multiple directories (layers) so they appear to applications as one single merged directory.
• Container runtime — the software that actually creates and manages the isolated process (namespaces, cgroups, filesystem mount) — e.g., containerd and runc.
• Tag — a human‑readable label pointing at a specific image version, like node:20-alpine.

Docker isn’t one monolithic program. It’s a small stack of cooperating components, each with a narrow job. Understanding this stack is what makes the image/container distinction click, because each component operates on a different one of the two.

Notice where images and containers sit in this diagram: images live in the image store, a passive, on‑disk collection of layers with no running process attached. Containers exist only once runc has actually asked the kernel to create an isolated process — they are the dynamic, “alive” part of the stack.

How Image Layers Work

Every instruction in a Dockerfile that changes the filesystem (RUN, COPY, ADD) produces a new, immutable layer, identified by a content hash. Docker caches these layers, which is why rebuilding an image after a small code change is fast — only the layers after the change need to be rebuilt; earlier, unchanged layers are reused straight from cache.

Copy‑on‑Write (CoW)

When a container writes to a file that exists in a read‑only image layer below it, the container’s storage driver (commonly OverlayFS) copies that file up into the container’s writable layer first, then applies the change there. The original layer in the image is never touched — it stays exactly as it was, which is what allows dozens of containers to share the same underlying image layers safely and cheaply. This is precisely why containers start in milliseconds: there’s no need to copy gigabytes of files at startup, just create a new thin writable layer pointing at shared read‑only layers.

Isolation Mechanics

cgroups then wrap around that isolated process to cap what it’s allowed to consume — for example, “this container may use at most 512MB of RAM and 0.5 CPU cores.” If it tries to exceed the memory limit, the kernel’s OOM killer terminates it, exactly the way it would kill any runaway process — containers don’t get special mercy from the kernel.

Let’s trace the full journey from source code to a running process, since this is where the image/container split becomes concrete rather than abstract.

The trade‑off in one sentence: you’re exchanging some isolation strength (compared to a full VM) for massive gains in speed, density, and portability — and for most application workloads, that trade is worth it.

Because containers reuse shared, cached image layers via copy‑on‑write, spinning up a new container typically takes well under a second, compared to VM boot times measured in tens of seconds to minutes. This matters enormously for autoscaling: when traffic spikes, an orchestrator like Kubernetes can launch dozens of new containers from the same image almost instantly to absorb load.

Scaling Images vs. Scaling Containers

You don’t “scale an image” — an image is static. What you scale is the number of containers instantiated from a given image, typically managed by an orchestrator that watches CPU/memory metrics and creates or destroys containers to match demand. Keeping images small (fewer, smaller layers, minimal base images like alpine) directly improves scaling speed, because a smaller image pulls faster onto new nodes that don’t yet have it cached.

Because a container is disposable and reproducible from its image, the standard reliability pattern in container‑based systems is: don’t try to heal a broken container — kill it and start a fresh one from the same image. This is often called treating containers as “cattle, not pets.” Orchestrators like Kubernetes constantly run health checks; if a container fails a liveness probe, it’s terminated and a new one is created from the same image automatically.

For true HA, images are usually pushed to a highly available registry (often replicated across regions), and containers are spread across multiple hosts/availability zones so that the failure of one host doesn’t take the whole service down.

Images are static, so there’s nothing to “monitor” about an image beyond scanning it for vulnerabilities and tracking its size over time. Containers, by contrast, are live processes and are what you actually monitor in production: CPU/memory usage (from cgroup metrics), restart counts, and log output (typically captured from the container’s stdout/stderr by a log driver and shipped to tools like the ELK stack, Loki, or CloudWatch).

docker stats                 # live CPU/mem/network usage per container
docker logs -f my-container  # stream a container's stdout/stderr
docker inspect my-container  # full container metadata & state

In practice, the deployment pipeline is exactly the lifecycle from Section 6, automated: CI builds an image on every commit, tags it (often with the git SHA), pushes it to a registry (Docker Hub, AWS ECR, Google Artifact Registry, Azure ACR), and an orchestrator (Kubernetes, ECS, Docker Swarm) pulls that image and creates containers from it across a cluster of machines.

# Minimal Dockerfile for a Java service
FROM eclipse-temurin:21-jre-alpine
WORKDIR /app
COPY target/app.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

docker build -t myregistry/orders-service:1.4.0 .
docker push myregistry/orders-service:1.4.0
docker run -d -p 8080:8080 --name orders myregistry/orders-service:1.4.0

Because a container’s writable layer is deleted along with the container, anything that needs to survive a restart (databases, uploaded files) must live in a volume — a storage location managed by Docker outside the container’s writable layer, which persists independently of any single container’s lifecycle.

docker volume create pgdata
docker run -d --name db -v pgdata:/var/lib/postgresql/data postgres:16

On the networking side, each container gets its own network namespace by default. Docker sets up virtual bridges so containers on the same host can talk to each other by container name, and port mapping (-p 8080:8080) exposes a container’s internal port to the host.

Microservice architectures lean heavily on the image/container split: each service (orders, inventory, payments) has its own Dockerfile and its own image, versioned independently. In production, each service typically runs as multiple containers behind a load balancer for both scalability and fault tolerance — if one container crashes, traffic routes to the healthy ones while the orchestrator replaces it.

Docker’s split between the immutable image and the disposable container is the single most important abstraction in modern application delivery. Once you internalise that images are static blueprints and containers are their live, per‑instance runtime, every other piece of Docker — layers, copy‑on‑write, namespaces, cgroups, volumes, registries, orchestration — slots naturally into place.