The short answer
When a deploy fails, your coding agent reads the failure reason, reads the app's logs, fixes the project and deploys again. You can say "the last deploy failed, fix it" and let it run. A failed deploy never counts against your plan, so it can try as many times as it needs.
Say this to your agent
The last deploy failed. Read the reason and the logs, fix the cause, and deploy again.
What your agent reads
-
The failure reason. Every failed deploy records a one-sentence reason in the deploy history. It names the cause, such as a lock file that does not match package.json, and says what to change.
-
The build log. A failed deploy keeps the end of the build log and what the app printed while Antideploy tried to start it.
-
The app's logs. What the running app printed, newest last. The default is 100 lines and the most it returns at once is 300.
-
Health. Whether the app is running, degraded, down or unknown, and when it was last checked.
-
Metrics. Requests, server errors and response times, for up to 30 days, 7 by default. Your agent checks them when you say the site is slow.
The loop, step by step
-
Read the reason first
The agent reads the failure sentence from the deploy history before it does anything else. Most failures name their own cause, and the sentence is written to be acted on.
-
Read the logs beside it
The reason says what failed. The logs say what the app was doing. The most common failure on Antideploy is an app that builds correctly and never starts listening on its port. The logs show whether it crashed on boot or listened on the wrong port.
-
Fix the project
The agent changes the code, the lock file or the configuration. Redeploying the same code unchanged reproduces the same failure, so the agent should change something first.
-
Deploy again
The agent sends the new version and watches it. If it fails again, it reads the new reason. A failed deploy is free, so there is no cost to trying.
What Antideploy fixes by itself
Some failures are not your code's fault, and some have a fix that is certain from the log alone.
-
Platform faults are retried. If a deploy fails because of the platform and not your code, Antideploy builds the same version again after a few minutes. The retry does not count against your deploys and does not email you.
-
A lock file that does not match. If
package-lock.jsonis out of date, Antideploy installs frompackage.jsonfor that build, in its own copy of the source, and tells you. -
Peer dependency conflicts. If npm refuses a conflict between two packages, Antideploy installs with
legacy-peer-depsfor that build, and tells you. -
Blocked pnpm scripts and Prisma versions. Antideploy allows install scripts that pnpm blocked, and pins the Prisma tool to the version your code uses.
These repairs happen in a copy of your source. Antideploy never edits your repository. You still get a note about what it changed, and the right fix in your own repository is to commit the corrected file.
What to do when it keeps failing
- Change one thing, then deploy. If the reason is the same twice, the fix did not take.
- Ask for the logs. Say "show me the last 200 log lines" and read them yourself.
- Check the exact message. The Fix an error section of this blog has a page for each common message, with the fix.
- Do not paste secrets into the chat. Your agent never needs to read a value back.