pre-deploy-checklist
GitHub部署前检查清单,验证Dockerfile、端口、环境变量、构建命令、依赖锁定及迁移等配置,提前发现部署风险。
Trigger Scenarios
Install
npx skills add nixopus/nixopus --skill pre-deploy-checklist -g -y
SKILL.md
Frontmatter
{
"name": "pre-deploy-checklist",
"metadata": {
"version": "1.0"
},
"description": "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."
}
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
Version History
- cf05d97 Current 2026-08-20 14:52


