Pre Deploy Checklist
DevOps & Securitypre-deploy-checklistPre Deploy Checklist is an Agent Skill for devops & security published in the nixopus/nixopus repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.
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.
How to use this skill
Bring this guide into your coding agent with a prompt tailored to the tool you use.
- Open your project in Codex.
- Copy and paste the prompt below.
- Review files and risks before approving any action.
Inspect the Agent Skill at https://github.com/nixopus/nixopus/blob/HEAD/api/skills/pre-deploy-checklist/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/pre-deploy-checklist, but wait for my approval before writing files or running scripts.
Copying this prompt does not install or run the skill. Review third-party files before use.
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_fileon the Dockerfile path - Verify it has a
FROMdirective - Verify it has an
EXPOSEdirective matching the expected port - Verify it ends with a
CMDorENTRYPOINT - 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
EXPOSEvalue, app's actual listen port, anyPORTenv 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-detectionskill) 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.jsonscripts.build(or equivalent) exists - If TypeScript, check
tsconfig.jsonexists andoutDiris 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 installinstead ofnpm ciin a Dockerfile without a lockfile leads to inconsistent builds
6. .dockerignore exists
- Check for
.dockerignorefile - Must include at minimum:
node_modules,.git,dist,.env - Missing
.dockerignorecauses bloated build contexts and potential secret leaks
7. Healthcheck endpoint
- For API servers: check if there's a
/healthor/healthzor/api/healthendpoint - 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:, DockerfileCMD, 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