What this prompt does
This prompt optimizes a Dockerfile for a [application_type] whose image is currently [current_size]. It produces a multi-stage build (builder to production), a minimal [base_image], layer caching ordered most-to-least changing, security hardening (non-root user, no shell, read-only filesystem), a .dockerignore for [ignore_patterns], a health check, graceful-shutdown signal handling, build arguments for [build_args], a dev docker-compose with hot reload, and a production compose with [production_services], targeting under [target_size].
The structure works because it attacks size and attack surface at the same time. A multi-stage build leaves build tools behind in the builder stage, and a minimal, non-root, shell-less image shrinks both the download and what an attacker can do inside it. Ordering layers from least to most volatile maximizes cache hits, so rebuilds stay fast. The Hadolint config and [scan_tool] vulnerability scan are guardrails that keep the gains from regressing on the next change.
When to use it
- A Docker image that has ballooned to
[current_size]and is slowing your pipeline. - Hardening a container before it goes to production (non-root, read-only, no shell).
- Setting up a clean dev-versus-production compose split with hot reload locally.
- Reducing image pull time and cold-start latency for a
[application_type]service. - Adding Hadolint and
[scan_tool]scanning so image quality doesn't regress. - Establishing a health check and graceful shutdown for orchestrated deployments.
Example output
You get an optimized multi-stage Dockerfile built on [base_image], a matching .dockerignore covering [ignore_patterns], a dev docker-compose.yml with hot reload, a production compose wiring [production_services], a Hadolint config, a build-time benchmark note, and a vulnerability-scan step using [scan_tool]. The Dockerfile includes a non-root user, health check, signal handling, and build args for [build_args], aiming under [target_size].
Pro tips
- Give an accurate
[current_size]and a realistic[target_size]; "under 200MB" is achievable for many Node images but not all. - Pick a truly minimal
[base_image](alpine or distroless) only if your app's native dependencies support it. - Order your COPY steps so dependency manifests come before source, maximizing the layer-cache benefit on rebuilds.
- Keep
[ignore_patterns]thorough; a fat build context (tests,.git, node_modules) silently inflates build time. - Run the
[scan_tool]step in CI, not just locally, so a vulnerable base image can't slip through unnoticed. - Verify the read-only filesystem doesn't break paths your app writes to; mount explicit volumes for those.
