What is the difference between Docker images and containers?

Question

Accepted Answer

A Docker **image** is a read-only **template** (a packaged application with its dependencies); a **container** is a **running instance** of an image. The relationship is like a class and an object: one image can spawn many containers. ## Image vs container ```text IMAGE → a read-only TEMPLATE: the app + dependencies + config, built in layers (like a blueprint/class; stored, shared, versioned) CONTAINER → a RUNNING INSTANCE of an image (with a writable layer on top) (like an object created from a class; has runtime state) One IMAGE → many CONTAINERS (run the same image multiple times) ``` ## Working with images ```bash docker build -t myapp:1.0 . # BUILD an image from a Dockerfile docker images # list local images docker pull nginx # download an image from a registry docker push myapp:1.0 # upload an image to a registry docker rmi myapp:1.0 # remove an image ``` Images are built (from a Dockerfile), stored locally or in registries, versioned with tags (`myapp:1.0`), and shared. ## Working with containers ```bash docker run -d -p 80:80 nginx # RUN a container from an image (-d = background) docker ps # list RUNNING containers docker ps -a # list all (including stopped) docker stop # stop a container docker start # start a stopped container docker rm # remove a container docker logs # view a container's logs docker exec -it bash # run a command inside a running container ``` Containers are created from images, have a lifecycle (run, stop, start, remove), and you can inspect logs or exec into them. ## The layered relationship ```text → Images are built in LAYERS (each Dockerfile instruction adds a layer, cached/shared) → A container = the image's read-only layers + a thin WRITABLE layer on top → Changes in a running container go to its writable layer (lost when removed, unless persisted via volumes) — the underlying image is unchanged ``` ## Why it matters Understanding the distinction between images and containers is fundamental to working with Docker, so it's essential, must-know knowledge. The relationship — an **image** is a read-only **template** (the packaged application with dependencies, like a blueprint or class) while a **container** is a **running instance** of that image (like an object created from a class, with runtime state) — is the core conceptual model of Docker, and confusing the two leads to confusion about how Docker works. Understanding that **one image can spawn many containers** (running the same image multiple times) is key to how Docker enables scaling and consistency. Knowing the practical operations — building, listing, pulling, pushing, and versioning **images** (with tags like `myapp:1.0`), and running, stopping, inspecting (logs), and exec-ing into **containers** (managing their lifecycle) — is everyday practical knowledge for using Docker. Understanding the **layered relationship** (images built in cached, shareable layers; a container being the image's read-only layers plus a thin writable layer where runtime changes go, lost on removal unless persisted via volumes) explains both Docker's efficiency (layer sharing/caching) and an important gotcha (container changes are ephemeral without volumes). Since the image/container distinction is the foundational mental model for Docker, and since understanding it (and the associated operations and layered structure) is necessary for building, running, and managing Docker workloads correctly, understanding the difference between images and containers is essential, fundamental Docker knowledge — the core concept that everything else in Docker builds upon, and a distinction every Docker user must clearly grasp.