=== DOCKER PRODUCTION READINESS AUDIT === Context: Node.js web API Dockerfile review. Files reviewed: Dockerfile only. No Compose file or deployment config provided. Application type: Long-running API service. Deployment target: Unknown. Overall readiness level: Level 2 — Deployable but fragile. Executive summary: The Dockerfile may build and run locally, but it is not production-ready. The main risks are use of a floating base tag, running as root, copying the full repository before dependency installation, likely missing .dockerignore, possible dev dependency inclusion, no health check, and unclear production command. Critical issues: None confirmed from the provided Dockerfile, assuming no secrets are copied. Secret handling still needs verification. High-risk issues: 1. Runtime likely runs as root. 2. Floating or overly broad base tag may create non-deterministic builds. 3. No health check is defined. 4. Dependency install may include dev dependencies. 5. Build context may include unnecessary or sensitive files if .dockerignore is missing. Medium issues: 1. Build cache likely inefficient if full source is copied before dependency installation. 2. Image may be larger than necessary. 3. Port and runtime command need confirmation. Base image audit: Use an explicit runtime version appropriate for the application. Avoid production reliance on floating tags. Build structure audit: Copy package manifest and lockfile before application source to improve cache reuse. Dependency layer audit: Use deterministic dependency installation based on the lockfile. Ensure production image excludes dev dependencies where appropriate. .dockerignore audit: Recommended exclusions: - local dependencies - Git history - local environment files - logs - coverage - build outputs regenerated during image build - editor files - private keys or certificates Secrets/config audit: Do not copy .env or credentials into the image. Runtime configuration should come from the deployment platform or secret manager. Runtime user and permissions audit: Add a non-root runtime user and ensure file ownership supports the application. Ports/networking audit: Confirm the app listens on the same port documented by EXPOSE and expected by the deployment platform. Health check audit: Add or document a lightweight health endpoint if supported by the application. Entrypoint/CMD audit: Confirm the command starts the production server, not a development server. Safe fix plan: 1. Add .dockerignore. 2. Pin base image version. 3. Reorder dependency install for cache. 4. Use production dependencies in runtime. 5. Add non-root user. 6. Add or document health check. 7. Validate port and production command. 8. Test in staging. Improved Dockerfile draft: The skill returns a reviewable multi-stage Dockerfile draft with no secrets and no destructive operations. Validation checklist: - build succeeds in CI - image starts locally or in staging - app responds on the expected port - health endpoint returns success - container runs as non-root user where possible - no .env or private files are in the image - dependency install is deterministic - production command starts the correct artifact - logs are visible on stdout/stderr Open questions: 1. What framework is this app using? 2. What is the real build output path? 3. Which deployment platform will run this image? 4. Does the app expose a health endpoint?