Replit app works in preview but breaks after publishing? A founder’s checklist

You test the app in Replit, send someone the link, and immediately hear that login, saving, or checkout does not work. Before asking Agent to rebuild those features, use this Replit production deployment checklist. A difference between the two environments may explain the failure without requiring a new implementation.

Why can an app work in Replit preview and fail live?

Replit preview and the published app are separate environments. The live app can have a different URL, configuration, data, and runtime behavior from the project you are editing.

Replit’s publishing guide explains that publishing creates a production deployment and that later editing does not change it until another publish. First confirm you are testing the intended release. Record the public URL, the last publish time, the failing action, and whether the failure also occurs in a fresh browser session.

Do not collect five unrelated screenshots and ask Agent to fix the whole app. Choose one failure: for example, a new customer receives an error after selecting Save. Record the expected result, actual result, and time. That gives you something specific to compare against the published application’s logs.

Is the app using the right deployment type?

The deployment must support the kind of program your app runs. A set of static files and a full-stack application have different hosting requirements.

As of October 2026, Replit’s deployment types documentation distinguishes Autoscale, Static, Reserved VM, and Scheduled deployments. Check the deployment type under Publishing settings and compare it with the application’s actual needs.

The same documentation says Static is not compatible with apps created using Replit Agent because those apps need a backend. Have a developer confirm the build and run commands if the application has been customized. Buying a larger machine will not repair a missing server route or an incorrect startup command.

Are the required production secrets actually available?

Check the credentials and configuration used by the published app, including their names and intended environment. A key available while developing is not proof that the live integration is correctly configured.

Replit’s Secrets guide directs you to Publishing → Adjust settings → Production app secrets. It also distinguishes sensitive secrets from non-sensitive configuration values. Review the required entries there, without copying their values into a troubleshooting prompt.

1. Ask for a list of required variable names, where each is read, and whether it is used at build time or runtime.
2. Check that the production entries match those names exactly and belong to the intended provider accounts.
3. Keep server credentials on the server; a frontend variable or browser bundle is not a secret store.
4. Republish when the platform or build process requires it, then repeat the original action on the public URL.

Is the published app reading the intended database?

Identify the live database before treating missing production records as a broken interface. Sample data visible in development may not be the data your customers’ app reads.

Replit’s development and production database guide describes separate environments and different setup paths for current and legacy infrastructure. Inspect the production selection in the Database tool and the publishing settings applicable to your app. Do not assume that a tutorial for a different project generation matches yours.

Consider a hypothetical directory app. The preview lists ten businesses, but the live site lists none. Before rebuilding the list component, check whether production contains any approved business records. A deliberate data import or initialization step may be the missing work. Copy only data suitable for live use, and protect existing customer records before any import or schema change.

For a failed write, collect the operation and sanitized error. Ask a developer to distinguish a connection failure from a missing table, a constraint, or an authorization problem. Changing the connection string repeatedly can obscure the original issue and accidentally point development work at the wrong data.

Do files and external callbacks work on the public domain?

Check where uploaded files are stored and which domain external services call. Both can appear correct in a preview while being unsuitable for the published application.

For uploads, Replit App Storage provides persistent object storage. Inspect the current implementation rather than assuming that files written to a runtime folder have the persistence and access controls your product needs. Test uploading, retrieving, and restricting a file after a controlled release.

For login providers, payment webhooks, and email links, review the allowed origins, registered endpoints, and return URLs with the relevant provider. They should refer to the intended published domain where required. Test the entire round trip: leaving your app, completing the provider action, and returning to a useful screen.

Keep a small integration inventory: service, environment, public callback path, secret name, and person responsible. The inventory contains configuration facts, not secret values. It makes later domain changes and handovers much easier to review.

How should you verify the live repair?

Reproduce the original action on the public URL, then inspect the matching production evidence. A successful publish means the release completed; it does not prove every customer workflow succeeded.

Replit’s Monitoring guide explains request statuses, response duration, resource usage, and application logs. Use the failing action’s timestamp to narrow the investigation. High resource use and an application error are different findings, so diagnose before changing capacity.

1. Use a fresh account on the published domain and repeat the exact failing journey.
2. Confirm that the intended record or integration outcome exists after refreshing the page.
3. Check the matching server request or log, then test a nearby failure case safely.
4. Repeat the main journey on a phone and verify that the previous working behavior still works.

What if the deployment still needs development work?

If configuration checks do not resolve the failure, scope development around the specific broken boundary. Bring a reproduction, the deployment settings, sanitized errors, and a map of the services involved.

Use the broader AI MVP production checklist before expanding your audience, or the fix-loop guide if repeated prompts are creating regressions. For help reviewing and shipping the next version, book a call about your Replit app. We can work out whether you need a configuration repair, a focused code change, or a larger release plan.