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
1---2name: pre-deploy-checklist3description: Validate deployment readiness before triggering a build — check Dockerfile, ports, env vars, healthchecks, and resource config. Use before any deployment to catch common configuration issues early.4---56# Pre-Deploy Checklist78Run through this checklist before triggering any deployment. Each check uses workspace tools. Report all findings, do not stop at the first failure.910## Checklist1112### 1. Dockerfile exists and is valid1314- Use `read_file` on the Dockerfile path15- Verify it has a `FROM` directive16- Verify it has an `EXPOSE` directive matching the expected port17- Verify it ends with a `CMD` or `ENTRYPOINT`18- If using multi-stage, verify the final stage copies the built artifacts1920**If Dockerfile is missing**: Use the `dockerfile-generation` skill to generate one.2122### 2. Port configuration matches2324- Compare: Dockerfile `EXPOSE` value, app's actual listen port, any `PORT` env var, and the port configured in the Nixopus application25- All must agree. Mismatched ports are a top deployment failure cause.26- If using docker-compose, also check the `ports:` mapping2728### 3. Required env vars are set2930- Run env detection (use `env-detection` skill) to find all required vars31- Cross-reference with what's configured in the Nixopus application32- Flag any missing required vars33- Flag any vars using placeholder values (`your-api-key-here`, `change-me`, `TODO`)3435### 4. Build command works3637- Check `package.json` `scripts.build` (or equivalent) exists38- If TypeScript, check `tsconfig.json` exists and `outDir` is set39- Check that the build output directory referenced in the Dockerfile matches the actual build output4041### 5. Dependencies are locked4243- Check for a lockfile (`package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, `Cargo.lock`, `poetry.lock`, `go.sum`)44- Using `npm install` instead of `npm ci` in a Dockerfile without a lockfile leads to inconsistent builds4546### 6. .dockerignore exists4748- Check for `.dockerignore` file49- Must include at minimum: `node_modules`, `.git`, `dist`, `.env`50- Missing `.dockerignore` causes bloated build contexts and potential secret leaks5152### 7. Healthcheck endpoint5354- For API servers: check if there's a `/health` or `/healthz` or `/api/health` endpoint55- If the Dockerfile or compose file includes a `HEALTHCHECK`, verify the endpoint exists in code56- Not strictly required but recommended — flag as warning if missing5758### 8. Database migrations5960- Check if the app has a migration system (`prisma`, `typeorm`, `knex`, `alembic`, `django migrate`, `goose`)61- If yes, verify the migration command is included in the deployment flow (compose `command:`, Dockerfile `CMD`, or Nixopus pre-deploy hook)62- Unmigrated databases after deploy cause runtime crashes6364## Result format6566Report as a table:6768| Check | Status | Details |69|-------|--------|---------|70| Dockerfile | PASS/FAIL/WARN | What was found or missing |71| Port match | PASS/FAIL | Expected vs actual |72| Env vars | PASS/FAIL | Count of missing vars |73| Build command | PASS/FAIL | The command found |74| Lockfile | PASS/WARN | Which lockfile, or none |75| .dockerignore | PASS/WARN | Present or missing |76| Healthcheck | PASS/WARN | Endpoint found or none |77| Migrations | PASS/WARN/N/A | Migration tool and command |7879Only block deployment (report FAIL) for checks 1-4. Checks 5-8 are warnings that should be reported but don't block.8081## Summary Format82Report the checklist table, then:83**Ready**: what looks good84**Warnings**: non-critical issues85**Blockers**: must fix before deploy86**Recommendations**: specific fixes with code blocks