Leadup deploy checker

LeadUp Deploy Checker

Purpose

Determine if a project can be deployed safely and produce an exact readiness report. This skill checks and plans only — it never runs the deploy or pushes. Deploy happens after explicit approval.

When to use

Trigger phrases: "prepare deploy", "deploy checker", "is this production ready", "make Docker work", "Coolify deploy", "leadup-server deploy", "can we ship this", "pre-deploy check".

For security posture specifically → leadup-security-review (deploy-checker includes a security gate but defers deep auditing to it).

Inputs needed

• The repo path and target *.leadup.in subdomain.
• Intended branch (usually main) and Coolify service expectations.
• Whether this is first deploy or an update (affects rollback/migrations).

Step-by-step workflow

Use references/deploy-checklist.md.

Deploy target vs. backend: If the project only uses Coolify as a downstream provisioning backend (and itself ships another way — e.g. Docker Compose + rsync to leadup-server), evaluate the project's actual deploy path, not Coolify. Confirm the real target from DEPLOY.md / compose files before running the checklist.

1. Build & run: Dockerfile builds clean; app serves; prod build succeeds; no dev/localhost URLs in prod paths.
2. Environment: .env.example covers every required key (placeholders); DEPLOY.md documents them; no secrets in image/repo/bundle.
3. Ports & networking: correct exposed port; no collision with other *.leadup.in apps; reverse-proxy/subdomain planned.
4. Domain & TLS: subdomain decided, DNS planned, TLS via Coolify.
5. Data: migrations idempotent; persistent volumes mapped (uploads/db); no weak default admin.
6. Source control: correct branch under leadupofficial; tree clean.
7. Rollback: previous tag/commit recorded; rollback steps in DEPLOY.md.
8. Verdict + stop: output READY/NOT READY with failing items and the exact commands the user runs. Do not deploy or push.

Required output format

1. Verdict: READY ✅ / NOT READY ❌.
2. Checklist results — each section pass/fail with evidence.
3. Blocking items — what must be fixed first, with the fix command.
4. Deploy commands the user will run (for them to execute, not you).
5. Rollback plan — explicit.
6. Approval gate: "Awaiting your approval to deploy — I will not push or deploy."

Safety rules

See references/security-rules.md and deploy-checklist.md. Most relevant:

• Never run git push, coolify deploy, or remote SSH — output commands and stop for approval.
• Never put real env values in .env.example or DEPLOY.md.
• Block deploy if secrets are in the image/repo or if data volumes aren't persisted (deploy would wipe data).

Common mistakes

• Marking READY while .env.example is missing required keys.
• Forgetting persistent volumes → uploads/DB wiped on next deploy.
• Port collision with another app already on leadup-server.
• No rollback target recorded before an update deploy.
• Evaluating the Coolify deploy path when the project only uses Coolify as a provisioning backend and actually ships via Docker Compose / rsync.
• Actually running the deploy/push instead of stopping at the gate.

Troubleshooting

• Under-triggers: user said "ship it" — re-invoke; suggest trigger phrases.
• Over-triggers for a deep security audit → route to leadup-security-review.
• Missing tool/MCP: if Docker can't be run here, give the exact commands for the user to run and check their pasted output.
• No internet/browser: fine — checks are local/config; defer DNS/TLS verification with a note.
• Missing project files (Dockerfile/DEPLOY.md absent): mark NOT READY, list them as blockers, offer to scaffold from kickoff assets.
• Build/test failure: capture error, classify (deps/env/Docker), mark NOT READY; never disable checks to force a READY verdict.

Test prompts

Should trigger (5)

1. "Is the jewellery SaaS production ready for Coolify?"
2. "Prepare deploy for the venus school site to leadup-server."
3. "Deploy checker on the salon repo before we ship."
4. "Make Docker work and tell me if we can deploy."
5. "Pre-deploy check for app.leadup.in."

Should NOT trigger (3)

1. "Do a full security audit of the payments code." (→ security-review)
2. "Browser test the login flow." (→ browser-playwright-tester)
3. "Update STATUS.md after deploy." (→ status-updater)

Functional test cases (2)

1. On a repo with a working Dockerfile but missing volumes, verdict is NOT READY with "persistent volumes" as a blocker.
2. The output ends with the approval gate line and performs no push/deploy.

Success criteria

• Every checklist section evaluated with evidence.
• Clear READY/NOT READY verdict + concrete blocking fixes.
• Rollback plan stated; commands provided for the user to run.
• No push, no deploy, no remote command executed.