Vibe Coding Deployment Problems: Preview Works, Live Fails

A vibe-coded app that works in preview but fails live has already provided its most useful clue: the environments differ. Do not regenerate the working screen first. Compare the deployed build, production variables, public domain, authentication redirects, API restrictions, data source and logs. Reproduce one failing journey and identify the first request or build step that behaves differently. That usually gives a smaller and safer repair than another broad prompt.

Confirm what “works in preview” actually proves

A preview may run against development services, a signed-in builder session or variables supplied automatically by the platform. It may also bypass the public domain and production cache. Record the exact successful steps and the data they use. Then repeat them in a private browser window against the live URL.

Do not compare different users or records and call the result an environment failure. Keep the test as equivalent as the systems allow.

Read the build result before debugging runtime behaviour

First establish whether the intended version built and deployed. A stale live page may mean the new build failed and the platform retained an older release. Look for the earliest package, compilation or configuration error and confirm the commit or version associated with it.

A generated fix that changes application logic cannot solve a package that failed to install. Keep build faults and runtime faults separate.

Compare environment settings without exposing them

Production may be missing an API URL, public key, callback domain or service identifier that exists in preview. Check names, presence and intended scope without copying secret values into prompts. Confirm which settings are available during the build and which exist only on the server at runtime.

Use the provider’s supported configuration route. Hard-coding a secret into frontend code is not a deployment repair.

Check API and integration restrictions

External services may allow local or preview origins but reject the production domain. Requests can also fail because the live app uses a different base URL, protocol or account. Trace one call from the browser through the relevant server function and inspect its response status and safe error detail.

If the integration is business-critical, test failure and timeout behaviour as well as success.

Authentication redirects often reveal domain mismatch

Sign-in providers and password links need approved callback URLs. A preview hostname and a custom domain are different origins. Check the exact redirect target, protocol and path, then test new login, existing session, logout and recovery on the live domain.

Do not weaken authentication to make the redirect disappear. The route and provider configuration need to agree.

Public routes and direct visits need testing

Client-side navigation can work after the home page loads while a direct visit to a nested route returns a server error. Test refreshing important URLs and opening them from a new browser session. Check the deployed platform’s routing or rewrite configuration and whether required files are present.

This is particularly important for shared links, password flows and public content pages.

Use logs as a timeline, not a wall of text

Trigger one failing action and note the time. Review build, server and integration logs around that event. Find the first relevant error and relate it to the user step. Remove credentials and customer data before sharing an extract.

When logs show several unrelated failures, prioritise the one that explains the repeatable journey. A deployment repair review can connect the browser symptom to the production service.

What common deployment symptoms usually indicate

The build fails before a live version exists

Start with the earliest package, compile or build error. Check whether a dependency is missing, a version changed, the build command points to the wrong script or generated code relies on a development-only assumption. Do not debug login or data behaviour until the production bundle is actually created. Repeatedly prompting the interface cannot repair a build pipeline that never reaches runtime.

The app publishes but shows a blank page or broken route

Confirm the correct output directory, base path and public routes. Test the homepage and then open a nested route directly in a fresh browser session. A client-side navigation journey can work while a direct request to the same route fails. Also confirm the live release contains the latest tested files rather than an older or partially cached build.

Login, APIs or data fail only on the public domain

Compare production environment settings, callback URLs, allowed origins, API restrictions and the live data connection without printing secret values. A successful preview may use a temporary domain or builder session that is not available to real users. Read deployment and application logs around one controlled request, then change only the setting or code tied to the first failure.

These patterns help decide whether the issue belongs to the generated app, build process, production configuration, external service or hosting choice. That classification should come before another broad repair prompt.

Preview-to-live investigation sequence

1. Confirm the intended version built and reached production.
2. Repeat one identical journey in preview and live.
3. Compare public domain, routes and authentication callbacks.
4. Check the presence and scope of environment settings.
5. Trace one failing API or data request.
6. Match it to the earliest relevant production log.
7. Test direct visits and refreshes on important routes.
8. Verify a rollback to the last known-good release.

When to stop changing the app

Stop prompting when preview still works, the live build is not the expected version, or production settings and logs have not been checked. Also pause if the proposed fix moves credentials into public code or disables access controls. Those changes obscure the deployment boundary and create new risk.

Use diagnosis when the first failing layer remains unclear.

Make the next release repeatable

After repair, document the version, settings, release steps and smoke tests used to approve production. Check the core live journey again after the fix and retain a rollback path. The goal of vibe coding repair is not merely to make one deployment pass, but to leave the project safer to change again.

Check data and storage assumptions in production

A workspace may write to a local file or temporary store that behaves differently in the deployed service. Confirm where production records persist, whether the app points to the intended database and how schema changes are applied. Do not assume a successful build means data will survive a restart.

Use a labelled test record, restart or redeploy only through the supported workflow, and verify the record remains. Protect existing data before any structural change.

Caching can make the wrong version look live

A browser, CDN or service worker may retain assets after a successful deployment. Confirm the release identifier or changed behaviour from a fresh session and another device. Check whether HTML and application bundles belong to the same release rather than clearing every cache blindly.

If users can receive mismatched versions, review the platform’s cache and asset strategy. A hard refresh may help diagnosis, but it is not a production fix for every visitor.

Production errors need safe user behaviour

Even after the deployment fault is repaired, external services can fail again. The live app should show a controlled message, avoid duplicate actions and preserve enough context for support. It should not expose raw provider errors or silently pretend a record was saved.

Define whether the user can retry, whether the system queues work and how staff reconcile uncertain outcomes. These operational decisions make deployment repair durable.

Close the environment gap

Keep a written inventory of required variables, domains, build commands, services and callbacks by environment. Use consistent names and a deliberate promotion process. Where feasible, test a staging or production-like release before the customer launch.

An AI app review is useful when the deployment difference exposes deeper assumptions in data or authentication rather than a single missing setting.

Record the repaired production boundary

Document which build is live, how it starts, which settings are required by name, the approved domains and callbacks, connected production services, persistence location and rollback route. Add the smoke-test result that proved the repair. Keep secret values in the supported protected configuration, not in the document.

This boundary makes later diagnosis faster. When preview and live differ again, the team can compare a known production model instead of guessing which hidden convenience the preview supplied. It also allows another person to release a change without relying on the original prompt session.

Use a production smoke test that reflects the business

After each release, run a small set of live checks through the public domain. Confirm the home or entry route, authentication where used, one safe data read and write, the most important integration and a direct visit to a nested route. Use a clearly identified test account and remove test records where appropriate.

The smoke test should be quick enough to run consistently and specific enough to catch environment mistakes. It should not perform real payments or send customer messages without a controlled test path. Record the deployed version and time alongside the result so a later report can be matched to the correct release.

If a check fails, pause promotion, preserve logs and return to the known-good version through the supported route. That discipline prevents an urgent live symptom from starting another uncontrolled prompt loop.