Production Dockerfile

Write a production Dockerfile with multi-stage builds, layer-cache ordering, non-root user, health check, and no secrets in layers.

Write a production-ready Dockerfile for my app.

Stack: [LANGUAGE + VERSION + FRAMEWORK, e.g. "Node 22 / Next.js", "Python 3.12 / FastAPI", "Go 1.23"]
How it builds and starts: [BUILD COMMAND + START COMMAND + PORT]
Package manager + lockfile: [e.g. "pnpm with pnpm-lock.yaml", "uv with uv.lock"]
Runtime needs: [NATIVE DEPS, ENV VARS EXPECTED (names only), FILES/ASSETS NEEDED AT RUNTIME]
Any special constraints: [BASE IMAGE POLICY / TARGET SIZE / COMPOSE NEEDED TOO?]

Requirements the Dockerfile must satisfy. Annotate each in comments:
1. **Multi-stage:** builder stage with full toolchain → runtime stage on the smallest sensible base (slim/alpine/distroless per my stack, state the trade-off you chose, e.g. alpine's musl gotchas for native modules). Only built artifacts and production deps cross the boundary.
2. **Pinned base images**: exact version tags, never :latest; note where I'd add a digest pin for full reproducibility.
3. **Layer-cache ordering**: least-changing first: copy the manifest + lockfile alone, install deps, THEN copy source. A code change must never invalidate the dependency layer.
4. **Non-root:** create and switch to an unprivileged user in the runtime stage; correct ownership on any writable paths.
5. **Deterministic installs**: the lockfile-strict install command for my package manager (npm ci / pnpm install --frozen-lockfile / uv sync --locked), install + cache-clean in a single RUN.
6. **No secrets in layers**: nothing sensitive via ARG/ENV/COPY; if the build needs a token, show the BuildKit --mount=type=secret pattern.
7. **HEALTHCHECK** matched to my app (real endpoint check, sensible interval/timeout), and the exec-form CMD so signals reach the process (graceful shutdown depends on it).
8. **.dockerignore**: generate it: node_modules/.venv, .git, .env*, tests, local configs; everything that bloats context or leaks.

Then: expected rough image size for my stack, the docker build and run commands, and (if I asked for compose) a docker-compose.yml with the app + [SERVICES], named volumes, and env passed via env_file, not inline.

Rules: every instruction gets a one-line comment saying why it's there, cargo-cult Dockerfiles rot. If something in my stack makes a "best practice" wrong (e.g. distroless vs. a framework needing a shell), say so and choose deliberately.

How to use

The two changes with the biggest payoff are multi-stage builds (routinely ~30% smaller images, no build toolchain in production) and manifest-first layer ordering (dependency layers cache across code changes, cutting CI build time). Non-root and exec-form CMD are the ones security reviews flag most. Verify the result: docker build, check the size, docker run, hit the health endpoint, and send SIGTERM to confirm graceful shutdown.

More coding prompts

Write the commit message for this change.

Diff:
"""
[PASTE THE STAGED DIFF]
"""

Why I made this change: [THE REASON, THE TICKET, THE BUG REPORT, or "you infer it"]
Convention: [Conventional Commits / this repo's existing style, pasted below / plain]
Recent commits from this repo, to match style:
"""
[PASTE 5-10 RECENT COMMIT SUBJECT LIN

Commit Message

Write a commit message that explains why the change was made, in Conventional Commits format, split into separate commits when needed.

Codingbeginner

Help me recover from a git mistake without making it worse.

What I was trying to do: [THE GOAL]
What I ran: [THE EXACT COMMANDS, IN ORDER]
What happened instead: [THE OUTPUT OR THE STATE NOW]
Has this been pushed or shared: [YES/NO, and to which branch and whether anyone else has pulled]
Uncommitted work I cannot lose: [WHAT AND WHERE, o

Undo a Git Mistake

Recover from a bad commit, force push, wrong branch, or lost work with a reversible plan and the exact commands, explained before you run them.

Codingintermediate

Handler code, routes, and models:
"""
[PASTE THE ROUTE DEFINITIONS, HANDLERS, REQUEST AND RESPONSE TYPES, VALIDATION SCHEMAS, AND MIDDLEWARE]
"""

Generate an OpenAPI 3.1 specification from the code above.

API name, version, and base URL: [DETAILS]
Auth scheme: [BEARER JWT / API KEY / OAUTH / SESSION COOKIE, and where it is enforced]
Con

OpenAPI Spec From Code

Generate an accurate OpenAPI 3.1 spec from handler code, including error responses and auth, with gaps flagged instead of invented.