From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

To fix a Claude Code app that works locally and fails online, identify whether the production build stopped, the server failed to start or a visitor request failed. Give Claude Code the failing revision and evidence from that stage. Ask for one specific fix, then repeat the same check on the deployed version.

Start with what you can observe: the deployment status, the public request and the relevant error. Keep the working local project intact while you investigate. A different host has a different environment, so the agent needs those differences before it changes code that already runs on your computer.

Locate the failure

Check the build result first, then whether the process started, then the failing public action. A compile error needs the build output. A process that exits needs startup diagnostics. A page that loads but cannot save needs the failed request and the server's response. Tell Claude Code which of those you observed.

Record the error with its timestamp and code revision. Give the agent a bounded, redacted excerpt rather than the whole log. The logging guide explains which facts let someone reconstruct a failure. A screenshot of a blank page helps identify the symptom; the failed network request often narrows its cause.

Check both setups

Ask Claude Code to compare the production start command, port and required value names with your local setup. Check whether the server listens where the host routes requests, whether a required value is missing and whether the app writes files to a permitted location. Read the host's runtime rules before changing the framework or adding a service.

The runtime contract worksheet covers those constraints. Check browser configuration too: Vite substitutes exposed environment values during the build. Changing a server variable after deployment does not rewrite an existing browser bundle. Its environment documentation also explains why private keys must stay out of VITE_ values.

Verify the fix

Have Claude Code name the evidence, the proposed change and the check that would prove the fix. Review its diff, publish the changed revision and run the failing action again. Keep the same URL and request in the comparison so a different test does not disguise a failure that still affects your visitor.

For example, a frontend calling your laptop's API needs a reachable production API address. Increasing server memory will not change that URL. If the same failure repeats without new evidence, use the agent stop rules to pause the loop before the agent starts changing unrelated code.

A debugging task

Fill in the symptom and the last revision you attempted to deploy, then paste this into Claude Code. The task separates investigation from a production change. It keeps secrets out of the report and gives you a repeatable acceptance check, so you can use it with any provider that exposes deployment status and suitable diagnostics.

Investigate this deployment failure before editing code.
Public URL:
Failing action and observed response:
Attempted revision:
Last known working revision, if any:

Determine whether the failure is build, startup or a visitor request.
Read the relevant status and bounded diagnostics. Redact secret values.
Compare the production command, port and required value names with local.
Check browser API URLs and build-time configuration where relevant.
Explain one likely cause, its evidence and the smallest proposed fix.
After approval, deploy that fix and repeat the failing action.
Report the running revision and the observed result.
Stop before deleting data, changing credentials or weakening a health check.

FAQ

Does a successful build mean the app works online? A successful build means the build process completed. You still need to check that the application starts and that a visitor can complete the intended action with production configuration.

Should I paste my environment file into Claude Code? Give the agent the required names and describe which are present. Keep secret contents in the approved secret-management path. Redact credentials from errors and copied logs before using them as debugging evidence.

What can Claude Code inspect on aidrop.it? On aidrop.it, service_get reports build state, the runtime envelope and the application currently serving the address. service_logs returns the latest build's bounded log. Combine those facts with the failing public request; the build log is not a record of every request your application handled.

Before the next deploy

Get it running from the session you are already in

Connect your coding agent over MCP and ask it to deploy. aidrop builds the repository and runs it on a public address; when a build or the app fails, the log says why, and your agent fixes it and builds again.