nixopus/pre-deploy-checklist

Pre-Deploy Checklist

Run through this checklist before triggering any deployment. Each check uses workspace tools. Report all findings, do not stop at the first failure.

Checklist

1. Dockerfile exists and is valid

• Use read_file on the Dockerfile path
• Verify it has a FROM directive
• Verify it has an EXPOSE directive matching the expected port
• Verify it ends with a CMD or ENTRYPOINT
• If using multi-stage, verify the final stage copies the built artifacts

If Dockerfile is missing: Use the dockerfile-generation skill to generate one.

2. Port configuration matches

• Compare: Dockerfile EXPOSE value, app's actual listen port, any PORT env var, and the port configured in the Nixopus application
• All must agree. Mismatched ports are a top deployment failure cause.
• If using docker-compose, also check the ports: mapping

3. Required env vars are set

• Run env detection (use env-detection skill) to find all required vars
• Cross-reference with what's configured in the Nixopus application
• Flag any missing required vars
• Flag any vars using placeholder values (your-api-key-here, change-me, TODO)

4. Build command works

• Check package.json scripts.build (or equivalent) exists
• If TypeScript, check tsconfig.json exists and outDir is set
• Check that the build output directory referenced in the Dockerfile matches the actual build output

5. Dependencies are locked

• Check for a lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml, Cargo.lock, poetry.lock, go.sum)
• Using npm install instead of npm ci in a Dockerfile without a lockfile leads to inconsistent builds

6. .dockerignore exists

• Check for .dockerignore file
• Must include at minimum: node_modules, .git, dist, .env
• Missing .dockerignore causes bloated build contexts and potential secret leaks

7. Healthcheck endpoint

• For API servers: check if there's a /health or /healthz or /api/health endpoint
• If the Dockerfile or compose file includes a HEALTHCHECK, verify the endpoint exists in code
• Not strictly required but recommended — flag as warning if missing

8. Database migrations

• Check if the app has a migration system (prisma, typeorm, knex, alembic, django migrate, goose)
• If yes, verify the migration command is included in the deployment flow (compose command:, Dockerfile CMD, or Nixopus pre-deploy hook)
• Unmigrated databases after deploy cause runtime crashes

Result format

Report as a table:

| Check | Status | Details | |-------|--------|---------| | Dockerfile | PASS/FAIL/WARN | What was found or missing | | Port match | PASS/FAIL | Expected vs actual | | Env vars | PASS/FAIL | Count of missing vars | | Build command | PASS/FAIL | The command found | | Lockfile | PASS/WARN | Which lockfile, or none | | .dockerignore | PASS/WARN | Present or missing | | Healthcheck | PASS/WARN | Endpoint found or none | | Migrations | PASS/WARN/N/A | Migration tool and command |

Only block deployment (report FAIL) for checks 1-4. Checks 5-8 are warnings that should be reported but don't block.

Summary Format

Report the checklist table, then: Ready: what looks good Warnings: non-critical issues Blockers: must fix before deploy Recommendations: specific fixes with code blocks