Blog
3 min read

Docker Image vs Container: What's the Difference?

An image is a read-only template; a container is a running instance of it. The difference explained with analogies and commands, what happens to files when a container is removed, why data belongs in volumes, and how tags, registries and layers fit in.

Two words come up constantly in Docker, and they're easy to mix up:

  • An image is a template: a packaged, read-only snapshot of an app and everything it needs.
  • A container is a running instance of an image.

(What is Docker?)

Analogies

  • Recipe vs dish. The image is the recipe; each container is a dish made from it. You can cook many dishes from one recipe.
  • Class vs object, if you program. One class, many instances.
  • Installer vs installed program. The image is like an installer file; a container is the program running.

In commands

docker pull postgres:18          # download an IMAGE
docker images                    # list IMAGES

docker run -d --name db1 postgres:18   # create and start a CONTAINER from it
docker run -d --name db2 postgres:18   # another CONTAINER from the same image
docker ps                        # list running CONTAINERS

One image, two independent containers.

You make images with docker build from a Dockerfile. You make containers with docker run.

Side by side

Image Container
What it is Template / snapshot Running (or stopped) instance
Changes? Read-only Has its own writable layer
Created by docker build, docker pull docker run, docker create
Listed by docker images docker ps -a
Shared? Pushed to a registry, reused Lives on one machine
Removed by docker rmi docker rm

What happens to files written in a container

Each container gets a thin writable layer on top of the read-only image. Files your app writes — uploads, logs, a SQLite database — go there.

When you remove the container, that layer is deleted, and the files with it. A new container from the same image starts clean.

That's why data must live in a volume (or outside storage), not inside the container. (Docker volumes vs bind mounts, Where should user uploads go?)

Stopping a container (not removing it) keeps its writable layer, but don't rely on that.

Layers: why images are efficient

An image is built in layers — one per Dockerfile step. Images that share a base (say, node:24-slim) share those layers on disk and in downloads. Ten containers from the same image don't take ten times the disk space. (Docker image layers and OverlayFS)

Tags and registries

postgres:18 is name:tag. The tag usually marks a version. latest is just a default tag name — it doesn't automatically mean newest, and it changes over time, so pin real versions in production.

Images are stored and shared in registries: Docker Hub, GitHub Container Registry (ghcr.io), and cloud providers' registries. You push your images there and pull them on servers.

"I changed my code but the container didn't change"

Very common confusion. A container runs the image it was created from. After changing code you need to:

  1. rebuild the image — docker build -t myapp .
  2. replace the container — stop/remove the old one and run a new one

With Compose: docker compose up -d --build does both. (Docker vs Docker Compose)

(In development you often mount your source folder into the container instead, so changes appear immediately.)

The summary

  • Image = template. Container = instance.
  • Many containers can run from one image.
  • Container files vanish when it's removed; keep data in volumes.
  • Changed code → rebuild image → recreate container.

EasySpawn runs your app's containers on a server with persistent volumes and daily backups, so data survives every rebuild. See how it works or join the waitlist.

Related: What Is Docker? · Dockerfile Explained · Docker Volumes vs Bind Mounts · Containers vs Virtual Machines

Keep reading