Docker in Production: The Practices That Survive Real Incidents

We deploy Docker containers for every client project — from single-container Next.js apps on Railway to multi-service architectures on Kubernetes. The mistakes that cause production incidents are remarkably consistent, and they are almost never about Docker itself. They are about the gap between a Dockerfile that works in development and one that survives real-world traffic, security scans and 3 AM incidents.

Multi-stage builds: the non-negotiable baseline

A production Docker image should contain exactly three things: a minimal OS layer, the language runtime, and your built application. It should not contain build tools, source code, dev dependencies, package manager caches or test fixtures. Multi-stage builds achieve this by using a 'builder' stage to compile and a 'runner' stage that copies only the output.

# Builder stage
FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile
COPY . .
RUN pnpm build

# Production stage
FROM node:20-alpine AS runner
WORKDIR /app
RUN addgroup -g 1001 app && adduser -u 1001 -G app -s /bin/sh -D app
COPY --from=builder --chown=app:app /app/.next/standalone ./
COPY --from=builder --chown=app:app /app/public ./public
COPY --from=builder --chown=app:app /app/.next/static ./.next/static
USER app
EXPOSE 3000
CMD ["node", "server.js"]

This produces an image that is typically 80-150MB instead of 800MB+, has a dramatically smaller attack surface, and starts faster because there is less filesystem to load.

Security: run as non-root, always

The default Docker user is root. This means a container escape gives the attacker root on the host. Running as a non-root user with a dedicated UID is the single most impactful security measure you can take. Combine this with a read-only root filesystem (--read-only flag) and explicit tmpfs mounts for directories that need write access. We also run container image scans (Trivy) in CI and block deployments with critical CVEs.

Health checks that actually work

Docker's HEALTHCHECK instruction and Kubernetes liveness/readiness probes serve different purposes. A liveness probe answers 'is this process broken beyond recovery?' (restart it). A readiness probe answers 'can this instance serve traffic right now?' (stop routing to it). We implement both: liveness checks the process, readiness hits an application endpoint that verifies database connectivity and dependency health. The default 30-second interval with a 5-second timeout works for most services.

HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
  CMD wget -qO- http://localhost:3000/api/health || exit 1

Logging: structured JSON to stdout

Containers should log to stdout in structured JSON. Not to files inside the container (they disappear when the container restarts), not to syslog (it adds a dependency), and not in unstructured plain text (it is unparseable at scale). The orchestrator — Docker Compose, ECS, Kubernetes — collects stdout and routes it to your log aggregation system. We use pino for Node.js, structlog for Python, and slog for Go. Every log line includes: timestamp, level, message, request_id, and any relevant business context.

Resource limits: prevent cascade failures

A container without CPU and memory limits can consume the entire host's resources, starving every other container and the orchestrator itself. This is the most common cause of 'everything went down at once' incidents. Set limits on every container. For Node.js services we typically start with 512MB memory and 0.5 CPU, then adjust based on production metrics. The --memory and --cpus flags in Docker Compose, or resources.limits in Kubernetes, are not optional.

The Compose-to-Kubernetes path

Docker Compose is the right tool for single-server deployments and development environments. When you need multi-node orchestration, automated scaling, rolling deployments and self-healing, you need Kubernetes. We start every project on Compose (or a managed platform like Railway) and migrate to Kubernetes only when the operational requirements justify the complexity. The migration path is straightforward if your containers follow the practices above: stateless, configurable via environment variables, with proper health checks and resource limits.