Replit App Works in Preview But Not Deployed?

If your Replit app works in preview but not when deployed, the app is giving you an important clue. The idea and some of the code may be sound, but the deployed environment is different from the workspace preview. The fault may be in domains, callbacks, routes, cookies, CORS, secrets, server startup or production configuration rather than the visible page.

This is one of the most common points where AI-built apps feel finished but are not yet production-ready. Preview is useful for building quickly. Deployment is where the app has to behave like a real service. Those are related, but not identical.

For a full check, see Replit app repair.

Preview and production are different environments

The Replit workspace preview may have values, URLs and behaviour that the deployed app does not. It may run a development command, use a preview URL, read workspace secrets or tolerate assumptions that fail on the live domain. Production may use a different command, different public URL, different environment variables and stricter routing.

That difference is why a working preview should be treated as encouraging, not conclusive. It proves the app can run somewhere. It does not prove that the deployed version has the right configuration, routes, callbacks, packages and services.

Compare the exact failing journey

Do not compare “preview works” with “live is broken” in general terms. Test the same journey in both places. Open the same route, click the same button, submit the same form, log in with the same kind of account and trigger the same API call. Record what happens in preview and what happens live.

The difference tells you where to look. If only login fails live, check callback URLs, cookies, sessions and auth domains. If only one route fails live, check route handling and direct URL support. If API calls fail live, check secrets, CORS, service URLs and backend startup. If the whole app is blank, check live console errors and runtime configuration.

Check domains, callbacks and cookies

Auth systems and external services often care about exact domains. A preview URL, deployed Replit URL and custom domain may all need separate configuration. If a provider only knows about the preview URL, the live app may reject callbacks, fail login or redirect users back to the wrong place.

Cookies can also behave differently on a live domain. Session cookies, secure flags, same-site settings and redirects can all create bugs that do not show up in preview. If login loops, profile loading or protected routes fail only after deployment, treat domain and cookie behaviour as part of the diagnosis.

Check secrets, CORS and service URLs

A deployed app may need its own API keys, database URLs and service endpoints. If the generated code reads a value that exists in preview but not production, the live app can fail while the preview keeps working. Check exact variable names, public prefixes and whether the code reads the value on the client or server.

CORS can also appear only after deployment. An API may accept requests from the preview URL but reject the deployed domain. If live API calls fail in the browser network tab, check the request URL, response status and allowed origins before changing the frontend logic.

Check routes and server startup

Some deployed apps fail because the server does not start correctly or because the app is served differently in production. A live 404 on direct links may be route handling. A connection failure may be server startup or port behaviour. A blank page may be a runtime error after assets load.

Check the deployed process, command, port and logs. Then test route behaviour directly. If the home page works but `/dashboard` fails on refresh, that is a different problem from the server not starting at all.

Why deployment config matters as much as code

It is tempting to assume code is the only thing that matters because AI generated the code. In production, configuration is part of the app. Secrets, domains, callbacks, routes, commands, package versions and server settings can make correct code fail. A repair that ignores configuration may keep changing working files while the live app remains broken.

If a generated code bug is exposed only in production, AI code repair may be the right fix. If the code is waiting for a missing secret or wrong domain, the fix is configuration. If you are not sure, root cause diagnosis prevents wasted effort.

What not to do

Do not rebuild the app just because deployment differs from preview. Do not overwrite auth flows without checking callback URLs. Do not paste secrets into prompts. Do not fix live-only API errors by changing random components. Do not change many production settings at once without recording what changed.

The safer path is controlled comparison: same route, same action, preview versus live, then logs and console errors from both places.

When to get help

Get help when the app is needed for users, when auth or database behaviour is involved, when the live error does not match the preview error, or when repeated prompts keep making the live build different rather than stable. Preview-to-production bugs are often repairable, but they need disciplined diagnosis.

Practical checklist

• Test the same route and action in preview and live.
• Record exact differences in behaviour.
• Check live console and network errors.
• Check deployment logs and server startup.
• Check production secrets and variable names.
• Check callback URLs, cookies and redirect domains.
• Check CORS and external service allowed origins.
• Check direct route and 404 behaviour.

Conclusion

When a Replit app works in preview but not deployed, the issue is usually the boundary between generated code and production configuration. Compare the environments first, then repair the specific gap.