Docker for Beginners: Images, Containers and Layers — Visually

“It works on my machine.” Docker exists so nobody has to say that again. In ten minutes you'll know what images, containers and layers really are — and you'll have a Dockerfile that rebuilds in seconds.

The problem: “works on my machine”

Your app needs Node 22, a specific OpenSSL, some environment variables and a dozen packages. The server has Node 18. Your teammate is on Windows. Docker solves this by shipping the app together with its environment, sealed in a box that runs the same everywhere.

Image vs container

• Dockerfile — the recipe: a text file of instructions.
• Image — the baked result: a read-only, versioned snapshot of the filesystem + start command.
• Container — a running instance of an image, isolated from the host and from other containers.

“An image is to a container what a class is to an object.

Layers & the build cache (the part everyone gets wrong)

Every instruction in a Dockerfile creates a layer. Docker caches each layer and reuses it if nothing it depends on changed. But here's the catch: once one layer is rebuilt, every layer after it is rebuilt too.

Try it. Pick Naive Dockerfile + Edited a source file and build. Then switch to Cache-friendly and build again. After that, run a few containers from the same image.

Tutorial: Dockerize a Node.js (or Next.js) app

Step 1 — Install Docker

Install Docker Desktop on Windows/macOS (or Docker Engine on Linux), then check: docker --version.

Step 2 — Add a .dockerignore

node_modules
.git
.next
.env*
npm-debug.log

This keeps images small and — importantly — keeps secrets out of them.

Step 3 — Write a cache-friendly, multi-stage Dockerfile

# ---- build stage ----
FROM node:22-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci                 # cached until dependencies change
COPY . .
RUN npm run build

# ---- runtime stage: only what we need to run ----
FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/package*.json ./
RUN npm ci --omit=dev
COPY --from=build /app/dist ./dist
USER node                  # don't run as root
EXPOSE 3000
CMD ["node", "dist/server.js"]

Step 4 — Build and run

docker build -t my-app .
docker run -p 3000:3000 --env-file .env my-app
# open http://localhost:3000

-p 3000:3000 maps a port on your machine to the container. --env-file passes secrets at runtime instead of baking them into the image.

Multiple services with Docker Compose

Real apps need a database too. Compose starts everything with one command:

services:
  web:
    build: .
    ports: ["3000:3000"]
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/app
    depends_on: [db]
  db:
    image: postgres:17-alpine
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
    volumes: ["pgdata:/var/lib/postgresql/data"]
volumes:
  pgdata:

Run docker compose up. Services reach each other by name (db), and the volume keeps your data when containers are recreated.

Cheat sheet

1. docker build -t name . — build an image
2. docker run -d -p 8080:3000 name — run in the background
3. docker ps / docker ps -a — running / all containers
4. docker logs -f <id> — follow logs
5. docker exec -it <id> sh — open a shell inside
6. docker stop <id> · docker rm <id> — stop · remove
7. docker system prune — clean up unused data (careful!)

Shipping a container to production? Your rendering strategy still matters — see CSR vs SSR vs SSG vs ISR.