Readiness and fixes
The readiness scan, what it checks, and how the fix loop works.
Before you can deploy, the platform scans your source to confirm it can build and run. The same scan runs again as a hard gate at build time, so a green check and a real deploy agree.
What the scan checks
The readiness scan runs these checks:
- Preparing your source — fetching the code to scan.
- Dockerfile builds — a valid
Dockerfilein the root. - No hardcoded secrets — no keys or passwords committed in the code.
- Dependencies resolve — your dependencies can be installed.
- No secrets exposed to the browser — no server secrets shipped to client-side code.
- AI review — a broader read of the source for problems the fixed checks miss.
Dockerfile builds, No hardcoded secrets and No secrets exposed to the browser can block a deploy. Dependencies resolve is a warning.
Outcomes
- Ready to deploy — you can deploy.
- Action required — one or more blocking issues. Fix them, then re-scan.
- Checked earlier code — your source changed since the last scan, so it no longer describes what would go live. Re-scan.
Each finding carries a title, a detail, and a fix.
The fix loop
When the scan finds something, it also produces a fix prompt: instructions written for your coding agent to apply to the code you have open.
Get the fix prompt
Copy the fix prompt from the scan, or copy the readiness prompt the wizard offers before scanning.
Apply it
Paste it into your coding agent (Cursor, Lovable, and similar). It edits your code.
Get the fix to the platform
The scan reads the source the platform holds, not your local files. For a GitHub app, commit and push to the connected branch. For a ZIP app, Re-upload ZIP.
Re-scan
Run the scan again. Repeat until it says Ready to deploy.
You can also fix issues by hand — edit your repo or re-upload your ZIP — and re-scan. Nothing forces you to use an agent.
Through a coding agent
An agent connected over MCP runs the same scan with check_deploy_readiness. It returns ready, the per-check summary, the findings, and the same fixPrompt. The agent must push (or re-upload) before re-checking, for the same reason: the scan reads what the platform holds, not the agent's working tree.
What can go wrong
- "The readiness scan found a problem that blocks this deploy. Open the scan to see what it found, fix it, then deploy again." — A blocking finding stands. Work the fix loop above.
- "Our check could not run" / "Scan failed. Please try again." — A problem on the platform side, not your app. Re-scan in a few minutes; if it persists, contact support.