Docker Hardening 101: The Essential Performance & Security Checklist

The Dockerfile below demonstrates all three principles in a Node.js context:

#Security: Hardening the Perimeter

Never run as root. A container escape vulnerability combined with a root-privileged process can hand an attacker full host access. Adding USER 1001 (or using a :nonroot distroless variant) caps the blast radius before an exploit even fires.

Distroless and Alpine images cut your attack surface drastically. gcr.io/distroless/static-debian12 weighs just ~2 MB. No shell, no package manager, no apt, no exec surface. Think of it as the minimum viable OS. Alpine (~5 MB) keeps a shell for debugging while still being much smaller than Debian or Ubuntu. Use distroless in production; Alpine for dev or debug builds.

Drop capabilities and lock the filesystem. Docker grants a default capability set that most applications never need. Start from zero and add back only what your app requires:

--read-only means a compromised container cannot write scripts or change binaries on disk. --tmpfs /tmp:noexec,nosuid gives the app a writable scratch space in memory but does not allow executing files from it. --security-opt=no-new-privileges blocks setuid escalation.

#Operations: Production Stability

Pin image versions. Always. FROM node:latest is a surprise waiting to happen. The image you pull today is not the same one you will pull in three months. And it will not warn you. Pin to a specific tag: FROM node:22-alpine3.20. Predictable builds are builds you can actually debug.

Set explicit CPU and memory limits. By default, a container has no resource constraints. One runaway or compromised container can OOM-kill its neighbors and bring down the host. Set hard limits in Compose:

Add 20-30% headroom above your P99 observed usage, then load-test before promoting to production.

Scan for CVEs before they reach the registry. Integrate Trivy or Grype as a non-negotiable CI gate. Both tools scan OS packages and application dependencies, fail the pipeline on configurable severity thresholds, and output results in SARIF for GitHub Security dashboards:

Do this early. Scan during docker build, not after pushing to the registry. A CVE caught at build time costs nothing to fix. A CVE found after deployment costs your weekend.

Nine controls. Apply them now. Do not wait for a CVE to make the choice for you.