Docker Best Practices for Production: What Most Tutorials Don't Tell You

Getting a containerized application to work in development is easy. Getting it production-ready — minimal, secure, efficient, and properly structured — requires deliberate choices that most tutorials skip.

Image Size and Base Image Selection

Large images increase pull times, increase attack surface, and waste registry storage. Start from small base images:

• alpine for simple applications — a minimal Linux distribution at ~5MB
• distroless images (from Google) contain only the application runtime with no shell, package manager, or other tooling — dramatically reduced attack surface

Multi-stage builds are essential for compiled languages: build in a full development image, copy the compiled binary into a minimal runtime image.

Security Hardening

Non-root user: Containers running as root are a privilege escalation risk. Add USER nonroot in your Dockerfile. Most official base images have a nonroot user available.

Read-only filesystem: Set the container root filesystem to read-only. Explicitly mount writable volumes only for directories that need write access (logs, temporary files).

Minimal capabilities: Docker grants a default set of Linux capabilities to containers. Drop all of them and add back only what’s needed: --cap-drop ALL --cap-add NET_BIND_SERVICE for services that only need to bind ports.

Build Reproducibility

Pin base image versions with digests, not tags. FROM node:20.11.1-alpine3.19@sha256:abc123... is reproducible. FROM node:lts is not — the same tag can refer to different images over time. Pin package versions using lock files committed to version control.

Layer Caching Strategy for Faster Builds

Beyond the security and size considerations covered above, build performance significantly affects developer iteration speed, and Docker’s layer caching mechanism rewards deliberate Dockerfile structuring. Placing instructions that change infrequently — installing system dependencies, copying package manifests before application code — earlier in the Dockerfile, and instructions that change frequently — copying application source code — later, allows Docker to reuse cached layers for the unchanged portions on subsequent builds, dramatically reducing build time for the common case of an application code change that doesn’t touch dependencies. Teams that structure Dockerfiles without attention to this caching behavior frequently experience unnecessarily slow CI pipeline build times that compound significantly across hundreds of daily builds.

Health Check Configuration That Orchestrators Actually Need

Production containers need properly configured health checks for orchestration platforms to make correct scheduling and traffic routing decisions, yet health check configuration is frequently an afterthought added late in the deployment process rather than designed deliberately alongside the application itself. Effective health checks distinguish between liveness — is the process still running and not deadlocked — and readiness — is the application actually able to serve traffic correctly, which may be false even when the process is technically alive, such as during a slow startup sequence connecting to a database. Conflating these two distinct checks, a common mistake, can cause orchestrators to either kill healthy-but-slow-starting containers prematurely or route traffic to containers that are running but not actually ready to handle requests correctly.

Supply Chain Security for Container Images Specifically

Beyond the general software supply chain considerations covered elsewhere, container images introduce specific supply chain risks worth addressing directly: verifying base image authenticity through image signing and verification, scanning images for known vulnerabilities before deployment as a mandatory pipeline gate rather than an optional check, and maintaining clear provenance tracking for exactly which source commit and build pipeline produced any given running container image, connecting directly to the broader software supply chain security practices increasingly required across the software industry.

---

This article is part of our ongoing coverage of Cloud & DevOps. For related reading, see serverless versus containers and Kubernetes cost optimization.

Resource Limits Prevent Noisy Neighbor Problems

Production container deployments need explicit CPU and memory limits configured, not just requests, to prevent a single misbehaving container from consuming disproportionate node resources and degrading performance for other containers sharing that node. Without configured limits, a container with a memory leak or runaway process can exhaust node-level resources, causing cascading failures across unrelated workloads sharing the same underlying infrastructure — a failure mode that proper resource limit configuration, combined with the broader Kubernetes resource management discipline covered in our analysis of Kubernetes cost optimization, directly prevents.