A Bolt.new application export with WebContainer dependencies under review by a UK senior engineer in a code editor.

Bolt.new App Rescue

Bolt.new lets you build and iterate on a full-stack application from a browser tab. The WebContainer environment it runs in is not a production environment — it is a high-fidelity simulation of one. When you export the project and attempt to deploy it externally, the differences between the simulation and reality become apparent immediately. We close that gap.

Senior UK engineers. Fixed-price diagnostic audit from £495. 3 to 5 working day turnaround.

Book a Diagnostic Audit — £495

Why Bolt.new Apps Fail Outside the Browser

Bolt.new's WebContainer technology is genuinely impressive. It runs a complete Node.js environment in the browser, complete with a filesystem, package manager, and development server. The limitation is that this environment has different characteristics from any real hosting platform. When you export the project and deploy it to Vercel, Netlify, Railway, or any other real hosting provider, those differences surface as failures.

Package incompatibilities after export

Some npm packages that work correctly in WebContainer behave differently in a standard Node.js runtime on a real server. Dependencies optimised for browser execution, packages that use native bindings, and packages that assume specific filesystem behaviour are common sources of failure after export. The build succeeds in Bolt.new because WebContainer handles them; the build fails on Vercel because the real Node.js environment does not.

Environment variable configuration

Environment variables defined in Bolt.new's interface do not export with the project. When you deploy to Vercel, the deployed application cannot find any of its environment variables — Supabase connection strings, API keys, feature flags — because they were never in the codebase to begin with. They existed only in Bolt.new's runtime. The result is an application that builds successfully and fails at the first API call.

The 5,000-line wall

Bolt.new's AI becomes progressively less reliable as codebase complexity increases. A codebase that has crossed approximately 5,000 lines sees a measurable increase in regression errors — the AI begins introducing new faults to resolve the ones it is addressing because it no longer has coherent context across the full project. Founders who have been iterating through a complex build often arrive at a codebase that has been patched so many times that the patches themselves have become the source of instability.

Build configuration for export targets

Bolt.new generates projects using Vite or Next.js depending on the template. Each has specific build configuration requirements for external deployment: output directories, framework presets, server-side function configuration, and static asset handling. These are commonly misconfigured in exported projects because Bolt.new has handled them implicitly and the export does not document them for the target platform.

Database and authentication not production-configured

Bolt.new projects using Supabase frequently have RLS policies left in the permissive state used for rapid development. Authentication is configured for localhost or Bolt.new's preview domain rather than your production URL. Both of these are silent failures — the application works correctly in development but either exposes all data or locks out real users at launch.

What a Bolt.new Rescue Covers

After the Diagnostic Audit establishes the specific fault set, remediation typically covers:

  • Package dependency audit — identification and resolution of WebContainer-specific dependencies that fail in a real Node.js environment
  • Build configuration correction for the target hosting platform (Vercel, Netlify, Railway)
  • Environment variable audit and migration to the hosting platform's variable management system
  • Supabase RLS policy review for production data access requirements
  • Authentication URL configuration for the production domain
  • Code health assessment for circular-fix technical debt — quantifying whether the codebase is patching safely or degrading
  • Domain, SSL, and custom domain configuration

Frequently asked questions

My Bolt.new app builds successfully but shows a blank page when deployed. Why?+
A blank page after a successful build is almost always a build output directory misconfiguration, a framework preset mismatch on the hosting platform, or a client-side routing issue where the server is not configured to serve the index.html for all routes. The Diagnostic Audit will identify the specific cause within 3 to 5 working days.
Can you help with a Bolt.new app that uses Supabase as a backend?+
Yes. Supabase is one of the most common backends in Bolt.new projects and one of the most common sources of production failures. RLS policy review, Edge Function configuration, and Auth URL correction for production domains are all within scope.
The AI keeps fixing the same error in a loop. Is the codebase salvageable?+
Circular fix loops are a common Bolt.new failure pattern as codebase complexity increases. Whether the codebase is salvageable depends on the nature of the underlying architectural issues — which is exactly what the Diagnostic Audit establishes. We will tell you honestly whether the correct path is a targeted fix, a refactor, or a rebuild.
I exported the project to GitHub but the repository seems incomplete. Is that normal?+
Bolt.new's GitHub export exports the project files but does not export environment variables, Bolt.new-specific configuration files, or the content of the WebContainer filesystem that is not part of the tracked project. The repository will be missing all environment variable values — this is expected. It is the configuration step after export that most projects skip, and it is one of the first things the Diagnostic Audit checks.

Bolt.new projects export to GitHub directly

If your project is already in a repository, we can begin the intake process immediately. If you have not exported yet, we can walk you through it on the triage call.

Or call +44 2033 550 558