Replit runs in the workspace but fails when published

1. Read the selected deployment type.

   Open Replit’s Publishing tool and choose Adjust settings. Inspect Deployment type. Static serves files without a backend server; an app that depends on a server needs an appropriate server deployment such as Autoscale or Reserved VM.

2. Open the published address itself.

   Use the URL for the published app in a new browser tab. Repeat the failing page or action and note the time. Do not use the workspace preview for this reproduction; it answers a different question.

3. Read the published app’s logs.

   In the Publishing tool, open Logs and inspect the messages at the recorded time. Use the error filter if needed. Compare startup messages with the configuration in Adjust settings and preserve the first relevant failure, with secrets removed.

4. Match browser and server evidence.

   Use Chrome Inspect, Network on the published page. Select the failed request and read its URL, status and Response. Compare its time with the publishing log. Record whether the request reached the server and whether the failure was during startup or during that action.

WORKSThe selected deployment type runs the app and the public request finishes as intended.

BROKENThe published process cannot start or its request fails with repeatable runtime evidence.

Ranked in the order to investigate, not by claimed frequency.

1. Static publishing was chosen for a server-dependent app.

   Use a deployment type that runs the required backend. Confirm the build and run commands for that application; uploading its frontend files alone cannot provide the server’s API.

2. The published process starts with the wrong configuration.

   Correct the documented run command or required published-app settings indicated by the first log failure. Republish and inspect startup again before retrying the user journey.

3. The published server fails only on a particular request.

   Use that request’s log entry to repair the specific integration or handler. Retest at the public URL and record the successful response alongside the absence of the earlier failure.

• Scheduled deployments run jobs and do not serve a public web page. They are not a substitute for an interactive application server.
• A successful workspace run does not establish that the production data and settings are correct. Confirm the intended production destination before performing writes with real users.

When to stop and hand it over

Stop when the published logs identify a missing service or unfamiliar server failure. Send the deployment type, failing action, time and redacted log excerpt. Do not repeatedly republish without a change supported by those observations.