Generate a Production-Ready Dockerfile and Explain Each Line

This prompt produces a hardened, multi-stage Dockerfile for your stack with a comment on every line explaining why it's there, plus a matching .dockerignore and a note on runtime arguments. It's for developers who want a production-grade image — small, non-root, no leaked secrets — and who want to understand the decisions rather than copy-paste a black box. The hard constraints (multi-stage, slim base, dependency-layer caching, no secrets in the image) encode container best practices that are easy to get wrong, and the per-line comments turn the output into a learning artifact you can defend in code review.

What you can expect back

# ---- Build stage ----
FROM node:20-slim AS build       # slim base: smaller, fewer CVEs than full image
WORKDIR /app
COPY package*.json ./            # copy manifests first so deps cache across code changes
RUN npm ci                       # ci = reproducible install from lockfile
COPY . .                         # copy source after deps for better layer caching
RUN npm run build                # produce build artifacts in this throwaway stage

# ---- Runtime stage ----
FROM node:20-slim AS runtime
WORKDIR /app
ENV NODE_ENV=production          # disables dev behavior, trims dependencies
COPY --from=build /app/node_modules ./node_modules  # bring only built artifacts
COPY --from=build /app/dist ./dist                  # no source/build tools in final image
USER node                        # run as non-root to limit blast radius
EXPOSE 3000                      # document the port (does not publish it)
CMD ["node", "dist/server.js"]    # exec form so signals reach the process

.dockerignore:
node_modules
npm-debug.log
.git
.env
Dockerfile

Runtime note:
Pass secrets at runtime, never bake them in: docker run -e DATABASE_URL=... -p 3000:3000 myapp. Keeping .env out of the image (via .dockerignore) and injecting env vars at run time means the image stays generic and credentials never end up in a layer.

Illustrative example — your results will vary by tool and inputs.

Get sharper results

• 01Name the exact runtime version (Node 20, Python 3.12) so the base image tag is pinned and your builds stay reproducible instead of silently drifting.
• 02Ask it to pin the base image by digest as well as tag if you need fully deterministic, supply-chain-hardened builds.
• 03If your app needs build-time native dependencies, mention them so the build stage installs the right system packages and the runtime stage stays slim.
• 04Have it add a HEALTHCHECK instruction tuned to your app's health endpoint so orchestrators can detect a hung container.
• 05Request the equivalent docker build and docker run commands alongside the Dockerfile so you can test the multi-stage build end to end immediately.

Adapt it for your case