Docker has been in production use since 2013. By 2026, it is infrastructure — no longer a novel tool but a standard part of the development and deployment stack. Here is how developers actually use it, past the tutorial level.
The Core Problem Docker Solves
“Works on my machine” is the problem Docker was built to eliminate. Before containers: differences in operating system, installed libraries, environment variables, and dependency versions caused code that worked in development to fail in production. Docker containers package application code with all its dependencies (OS libraries, runtime versions, configuration) into an isolated, reproducible unit. A Docker image built on a developer’s MacBook runs identically on a Linux server in a data centre. The container runtime (the low-level technology) is provided by containerd (Docker’s runtime) or CRI-O (used by Kubernetes). Docker Desktop is the developer tool that runs containers on Mac and Windows via a lightweight Linux virtual machine.
The Dockerfile
A Dockerfile is the recipe for building an image. Practical patterns that matter: multi-stage builds (build the application in one stage, copy only the output binary into a minimal final image — dramatically reduces image size); layer caching (Docker caches each instruction layer; put frequently-changing instructions last to avoid cache misses); non-root user (running as root inside a container is a security risk; create a dedicated user with `RUN useradd -m appuser && USER appuser`); minimal base images (`python:3.12-slim` instead of `python:3.12` reduces image size by ~150MB). A well-structured Python Dockerfile: `FROM python:3.12-slim AS builder`, copy requirements.txt and `RUN pip install`, then `FROM python:3.12-slim`, copy only the installed packages and app code from the builder stage. The resulting image is significantly smaller and has fewer potential CVE vulnerabilities than a naive single-stage image.
Docker Compose for Local Development
Docker Compose is where most developers spend most of their Docker time. A `docker-compose.yml` defines the services (app, database, cache, message queue) that make up the local development environment. Key patterns: `depends_on` with health checks (ensure the database is actually ready before the app starts, not just that the container is running); volume mounts for code (mount the local code directory into the container so changes are reflected immediately without rebuilding); environment variables from .env files (use `env_file: .env.local` to separate secrets from the compose file). Common anti-pattern: building a production-like Docker image for every code change in development — use a volume mount for the code and a hot-reload development server instead.
From Development to Production
Container registries: Docker Hub (public), AWS ECR, Google GCR, GitHub Container Registry — push your built image to a registry; pull it to deploy. In production, Docker is typically not used directly — Kubernetes (k8s) or managed container services (AWS ECS, Google Cloud Run, Azure Container Instances) orchestrate containers at scale. Cloud Run in particular has become very popular for simpler deployments: push a container image, Google manages scaling, and you pay per request with zero-to-zero scaling (no cost when not receiving requests). The common development-to-production path for a small team: Docker Compose locally → CI/CD builds and pushes the image → Cloud Run or ECS pulls and deploys the image. This pipeline is faster to set up than Kubernetes and sufficient for many production workloads.
