How DevOps Engineers Harden Docker for Production
For DevOps and platform engineers · Based on ByteMonk Docker-to-AI Infrastructure Framework
// TL;DR
DevOps and platform engineers use this framework to move Docker stacks from 'runs on my machine' to production-hardened. It covers Docker Hardened Images (95%+ fewer CVEs, SBOM, cryptographic provenance, 7-day CVE patching), non-root container users, multi-stage builds that strip compilers from runtime images, docker scout integrated into CI/CD, minimal port exposure, and volume strategies that protect persistent data. Use it when shipping images to production, standardising a secure pipeline, or auditing an existing stack against modern 2026 Docker practices.
What makes a Docker image production-ready versus dev-ready?
Security posture and reproducibility. Most container vulnerabilities come from the base image, not application code — so the first lever is the base image itself. Docker Hardened Images (DHI), free under open source licence since late 2025, are minimal by design, ship with a full software bill of materials and cryptographic provenance, and receive critical CVE patches within 7 days. They're reported to have 95%+ fewer CVEs than standard base images. Migrate existing Dockerfiles with the `dhi-ctl` CLI plugin or the Gordon AI assistant.
How do you shrink the attack surface of an image?
Apply multi-stage builds. A first stage carries all compilers, bundlers, and test frameworks to produce the artefact. The final stage is a minimal runtime that receives only the compiled output — no compilers, no test frameworks, no source. The result is a smaller image, faster pulls, and far less to exploit.
Then stop running as root. Add `RUN adduser --disabled-password appuser` and `USER appuser` to every Dockerfile so the application process runs unprivileged. If an exploited process is running as root, the attacker inherits full system privileges.
How do you catch vulnerabilities before they reach production?
Run `docker scout` on every image before shipping, and integrate Scout into your CI/CD pipeline so vulnerable images are caught before deployment, not after. Combined with DHI's SBOM and provenance, this gives you an auditable supply-chain story. By early 2026, Gordon can also scan and migrate Dockerfiles to Hardened Images and provide context-aware terminal hints on command failure.
How should ports and networks be configured for production?
Publish only what genuinely needs external access. Use the `-p` flag for the public entrypoint and nothing else — databases should almost never have a published port. Keep internal services on a user-defined Docker network where they reach each other by container name via internal DNS. This keeps the network layout clean and the attack surface minimal.
What's the safe volume strategy in production?
Use named volumes for anything that must survive container deletion — databases, uploaded files. Use tmpfs for sensitive temporary data like short-lived tokens that must never touch disk. Bind mounts are a development accelerator and don't belong in production.
The single most dangerous command in your vocabulary is `docker compose down -v`: it deletes named volumes along with containers. It's correct for a dev clean-slate reset and catastrophic against production data. Guard it with process, and never run it on production without explicit, backed-up intent.
How do you make startup deterministic across services?
Encode health checks and startup ordering in Compose. Define a health check on each dependency and add `depends_on: condition: service_healthy` to dependents, so services don't crash-loop during initialisation. Use `docker compose` with a space — the hyphenated `docker-compose` was officially removed in 2026. Load all secrets from `.env`, keep `.env` in `.gitignore` and `.dockerignore`, and use `npm ci` for reproducible dependency installs.
Next step: Audit one production image today — migrate its base to a Docker Hardened Image, add a non-root user, convert it to a multi-stage build, and add a docker scout gate to your CI pipeline before the next deploy.
// FREQUENTLY ASKED QUESTIONS
Are Docker Hardened Images worth switching to?
Yes — Docker Hardened Images are reported to have 95%+ fewer CVEs than standard base images, because most container vulnerabilities come from the base image. They're minimal by design, ship with a software bill of materials and cryptographic provenance, and receive critical CVE patches within 7 days. Migrate existing Dockerfiles with the dhi-ctl CLI plugin or the Gordon AI assistant.
Why should containers not run as root?
If an application process running as root is exploited, the attacker inherits full system privileges. Always add a non-root user with adduser --disabled-password appuser and switch to it with USER appuser in every Dockerfile, so a compromised process is constrained. Combined with isolated containers and minimal images, this dramatically limits the blast radius of any exploit.
What's the most dangerous Docker command to guard against in production?
docker compose down -v — it stops and removes containers AND deletes named volumes, destroying persistent data. It's correct for development clean-slate resets but catastrophic on production data and irreversible without backups. Use plain docker compose down to stop containers while keeping named volumes. Guard the -v variant with process and explicit intent.