Bolt.new Deployment Failed? Why Preview Success Is Not Enough

A Bolt.new deployment can fail even when the preview looked finished. Preview success tells you the app can run in one environment. It does not prove the production build, hosting config, routes, environment variables or connected services are correct.

Start with the build logs

Deployment logs usually show whether the build failed before the app went live or whether the app deployed and then failed at runtime. Missing modules, TypeScript errors, incorrect build commands and framework mismatches can all stop deployment.

For hands-on diagnosis, use the Bolt.new app repair page and include the build log if you have it.

If the log points in several directions, separate the build failure from the hosting setup before changing code, deployment settings and environment variables at the same time.

Check environment variables

Production needs its own environment variables. Supabase URLs, anon keys, API keys, callback secrets and service URLs may exist in preview but be missing from Netlify, Bolt hosting or another deployment target. A missing variable can produce a blank screen or broken login after the build succeeds.

Check routes, redirects and 404 behaviour

Single-page apps often need redirect rules so deep links load correctly. If the home page works but internal pages return 404, the app may need hosting redirects rather than a code rewrite. Netlify deployments commonly need this check.

Check blank screens after deployment

A blank deployed app often means a JavaScript runtime error, missing asset, wrong base path, failed import or missing environment variable. Open the live URL console and compare it with the Bolt.new preview.

Check Supabase and auth after deploy

Auth callbacks, allowed redirect URLs, site URLs and cookie behaviour can differ once the app has a real production domain. The focused guide for Bolt.new auth not working covers this in more detail.

When urgency matters

If the deployment failure is blocking a launch, client handover or live customer journey, collect the logs, URL and last change. For time-sensitive failures, emergency website fixes may be more appropriate than slow trial and error.

Checklist

• Read the build log before changing code.
• Confirm the build command and output directory.
• Check production environment variables.
• Check redirects and route handling.
• Compare preview console errors with live console errors.
• Check Supabase auth and callback domains.

Conclusion

Deployment failures are usually solvable once you know whether the fault is build-time, runtime, hosting, routing or connected service configuration. Preview success is useful, but production still needs its own checks.

Preview-to-production differences to document

When a Bolt.new app works in preview but fails live, write down the differences. Is the URL different? Are the same environment variables available? Does the live build use a different Node version? Does the app depend on a domain that has not been allowlisted? Are redirects configured on the hosting platform?

Those details quickly separate a code problem from a deployment problem. Without them, it is easy to rewrite working code while the live host is still missing the value or redirect it needs.

What to send with a failed deployment

Send the deploy log, the live URL, the preview URL, the hosting provider, the build command, the output directory and the first visible browser error after deployment. If the project uses Supabase, include whether auth, reads or writes fail live.