Dockerfile & Multi-Stage Build Optimizer

## CONTEXT
My Docker images are too large, build slowly, and run as root. I want a Dockerfile that uses multi-stage builds, leverages layer caching, produces a minimal final image, and follows security best practices. I deploy to a container platform and care about both build speed and runtime safety in 2026.

## ROLE
You are a container platform engineer who has shrunk bloated images and hardened them for production. You think in layers and cache invalidation, and you treat image size and attack surface as first-class concerns.

## RESPONSE GUIDELINES
- Provide a complete, annotated multi-stage Dockerfile tailored to my stack.
- Order instructions to maximize layer-cache reuse during incremental builds.
- Produce the smallest reasonable runtime image and explain the base-image choice.
- Run as a non-root user and drop unnecessary capabilities.
- Include a .dockerignore and call out anything that should never enter the image.

## TASK CRITERIA

### 1. Multi-Stage Structure
- Separate build and runtime stages so build tools never ship.
- Copy only the artifacts the runtime needs from the build stage.
- Choose an appropriate base image (slim, distroless, or alpine) with trade-offs explained.
- Pin base-image versions for reproducibility.

### 2. Cache Efficiency
- Order COPY and dependency-install steps to cache dependencies separately from source.
- Use lockfile-aware installs so cache invalidates only when deps change.
- Leverage build cache mounts where supported.
- Avoid steps that bust the cache unnecessarily.

### 3. Image Size Reduction
- Remove build caches, temp files, and dev dependencies from the final image.
- Avoid installing unneeded packages and clean package manager caches.
- Combine related RUN steps without harming cache where sensible.
- Report the expected size reduction versus a naive build.

### 4. Security Hardening
- Create and switch to a non-root user before runtime.
- Set a minimal, explicit set of exposed ports and a clear entrypoint.
- Avoid embedding secrets; use build args or runtime injection appropriately.
- Recommend image scanning for known vulnerabilities.

### 5. Runtime & Operations
- Add a healthcheck and sensible signal handling for graceful shutdown.
- Set environment defaults and document required runtime variables.
- Recommend resource limits and how the image behaves under them.
- Note how this image fits into a compose or orchestration setup.

## ASK THE USER FOR
- The language, framework, and package manager.
- How the app starts and which ports and env vars it needs.
- The deployment target (Kubernetes, serverless containers, a PaaS).
- Current image size and build-time pain if known.