Docker best practices in 2026 are not the same advice that floated around when containers were new. Multi-stage builds are table stakes, BuildKit is the default builder, and the security expectations are higher. The teams shipping fast container builds and small, secure images are using a tight set of patterns that compound. The teams shipping 4GB images that take 20 minutes to build are usually missing 5-10 specific things. Here is what to fix first.
Table of Contents
Multi-Stage Builds Are Mandatory
A Node.js image with build tools, dev dependencies, and source maps weighs in at 1.5GB. The same app in a multi-stage build with only runtime dependencies is 150MB. That is a 10x improvement for adding 20 lines of Dockerfile.
Build in a `builder` stage, copy the artifacts into a slim runtime stage. For Go, this drops to single-digit megabytes with a `FROM scratch` final stage. The official Docker multi-stage build guide shows the patterns.
Order Layers by Change Frequency
Docker layer caching is your build speed superpower, but only if you order layers correctly. Things that rarely change (base image, system packages) go first. Things that change frequently (your app code) go last.
The classic pattern: COPY package.json first, RUN npm install, then COPY the rest. A code-only change reuses the npm install layer and saves 30-90 seconds per build. Multiplied across CI runs per day, this is hours of developer time.
Pin Base Image Versions
`FROM node:latest` is a time bomb. Tomorrow’s `latest` will be different. Pin to specific versions, and ideally to specific digests for reproducible builds: `FROM node:20.19.0-alpine@sha256:…`.
Renovate and Dependabot can auto-PR base image updates so you stay current without surprise breakage. See our CI/CD pipeline setup guide for automated dependency management patterns.
Run as Non-Root
The default Docker runs containers as root. Container escape vulnerabilities then become host root vulnerabilities. Add a USER directive to drop privileges in your Dockerfile.
Most official images now ship with a non-root user available — `node` for Node.js, `nginx` for nginx. Use them. For your own apps, create a user with a fixed UID/GID so volume permissions are predictable across hosts.
Use .dockerignore Properly
A missing or incomplete `.dockerignore` is a common reason builds are slow and images are huge. Without it, Docker sends your entire working directory (including `node_modules`, `.git`, build artifacts) to the daemon as build context.
A good `.dockerignore` mirrors `.gitignore` plus build outputs. The first build after fixing this often shrinks 5-10x. The Docker context documentation covers the syntax.
Wrap Up
Docker best practices done right shrink your images, speed your builds, and harden your security posture without slowing your team. Multi-stage builds, smart layer ordering, pinned versions, non-root users, and a real `.dockerignore` cover most of the gap between average and excellent. Combine these patterns with Kubernetes basics and you have a solid container deployment story for any production workload.
Frequently Asked Questions
Should I use Alpine or Debian-slim base images?
Alpine for absolute minimum size when your dependencies support musl libc. Debian-slim for compatibility (Python with C extensions, Node native modules). The size difference matters less than build reliability.
How do I scan images for vulnerabilities?
Trivy, Grype, or Snyk in CI on every build. Fail the build on high/critical CVEs in your runtime layer. Most CI platforms have integrations that comment scan results on PRs.
Should I use Docker Compose in production?
For single-host deployments, Docker Compose is fine and underrated. For multi-host, you need an orchestrator (Kubernetes, Nomad, ECS). The line is roughly: if a single VM crashing is acceptable downtime, Compose works.
How do I handle secrets in Docker?
Never bake secrets into images. Use Docker secrets, environment variables from a secret manager at runtime, or mount config files at runtime. Build args are visible in image layers.
Is Buildah/Podman worth switching to?
For rootless container building and OCI compliance, yes. For most teams already on Docker, the migration cost outweighs the benefits unless you have a specific reason (security policy, license concerns).
