Docker is a platform that packages applications and their dependencies into lightweight, portable containers. A container includes everything needed to run: code, runtime, libraries, and system tools. This ensures your application behaves identically whether running on a developer's laptop, a CI server, or production infrastructure.
How It Works
A Dockerfile defines how to build a container image: starting from a base image (like node:20-alpine), copying your source code, installing dependencies, and specifying the startup command. Building the Dockerfile produces an image: a read-only template. Running an image creates a container: a live instance of your application.
Docker Compose orchestrates multi-container setups. A docker-compose.yml file defines your app server, database, Redis cache, and any other services. One command (docker compose up) starts everything with networking already configured between containers.
Images are stored in registries (Docker Hub, GitHub Container Registry, AWS ECR) and pulled by any machine that needs to run them. This makes deployments reproducible: the exact image tested in CI is the same image running in production.
Why It Matters
"It works on my machine" disappears with Docker. Environment inconsistencies between development, staging, and production (different Node versions, missing system libraries, conflicting dependencies) are eliminated because the container carries its environment with it.
Docker also enables density. Containers share the host OS kernel and start in milliseconds, compared to virtual machines that boot entire operating systems. A single server can run dozens of containers efficiently.
In Practice
A team developing a Next.js application uses Docker Compose to run the app, a PostgreSQL database, and a Redis cache locally. New developers clone the repo, run docker compose up, and have a fully working environment in under a minute. The same Dockerfile builds the production image deployed to Kubernetes.
Pro Tips
Use multi-stage builds to keep production images small: build in one stage with dev dependencies, then copy only compiled output to a minimal final stage. Pin base image versions for reproducibility. Never store secrets in images; inject them at runtime through environment variables. Add a .dockerignore file to exclude node_modules and other unnecessary files from the build context.