A container is a packaging boundary
Docker adds value when it makes runtime dependencies explicit and reproducible. The image should contain application code and required binaries, while configuration and secrets arrive at runtime and durable state lives in managed volumes or external services. Treating a container as a lightweight virtual machine loses most of that discipline.
Image design, runtime config, and state are separate
- Use multi-stage builds to separate dependency/build tooling from the final runtime.
- Run as a non-root user when practical and keep the image surface small.
- Do not bake environment secrets or mutable application data into layers.
- Give migrations, workers, and web processes distinct container commands when their lifecycles differ.
- Health checks should test service readiness, not only whether PID 1 exists.
From source to a minimal runtime image
Dependencies and source are built into an immutable runtime image; environment, secrets, network, and persistent data are supplied when the container starts.
Build-time layers versus runtime responsibilities
Dependencies and source are built into an immutable runtime image; environment, secrets, network, and persistent data are supplied when the container starts.
package lock
Containerizing a web app with migrations
A multi-stage image keeps build tools out of runtime
The final stage copies only what is required to run the application.
Dockerfiledockerfile
FROM node:22-bookworm-slim AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --no-audit --no-fund
FROM deps AS builder
COPY . .
RUN npm run build
FROM node:22-bookworm-slim AS runner
WORKDIR /app
COPY --from=builder /app .
CMD ["npm", "start"]Docker habits that create fragile systems
Container checklist
- Use a lockfile and multi-stage build.
- Keep secrets and durable state out of image layers.
- Separate web, worker, and migration lifecycle commands.
- Run minimal privileges and define health/readiness.
- Tag releases immutably and scan final images.