Docker Production Readiness Auditor

=== 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?