bolt.new deployment issues: preview works, live app fails

Preview works, but the deployed app fails

For a Vite client app, a working development preview does not prove the production bundle has the configuration it needs. Vite normally uses development mode for its dev server and production mode for its build. A value supplied only in .env.development can therefore be available in preview and absent from the built app. Vite: env variables and modes, read 31 October 2026.

Start with the build and its output, then check which configuration went into it. The example below reproduces one specific mismatch locally. It does not assume that every Bolt project uses Vite or that every deployment failure has the same cause.

If the problem is a generic message inside Bolt before you reach this point, use Bolt “Something went wrong”: find the real error.

First, identify what failed

Bolt recommends checking its status page before troubleshooting. If an incident covers publishing, check again after it resolves. This is a diagnostic link, not a claim that an outage is active. Bolt publishing guidance, read 31 October 2026.

For this guide, separate these observations:

The output-folder and secure-connection branches come from Bolt's publishing guidance, read 31 October 2026. The configuration branch is reproduced below using Vite's documented mode behavior, read the same day.

Check the actual production build

In a local copy of your own project, read package.json and the Vite configuration before running commands. The commands here apply when the build script runs vite build and the preview script runs vite preview. Use your project's package manager and scripts if they differ. Vite static deployment guide, read 31 October 2026.

npm run build
npm run preview -- --host 127.0.0.1

Run the preview command only after the build succeeds. Vite's local preview serves the built files, whereas the development server uses development mode. Open the local address printed by the command and repeat the action that fails. Vite preview is a local check, not a production server. Vite static deployment and env modes, read 31 October 2026.

Check the output folder too. Vite defaults to dist, but build.outDir can change it. Confirm that the folder contains the generated site files and that the publishing setup expects that same folder. Do not rename a folder to dist without checking the configuration. Bolt builds the site first and then looks for its output; a missing or unexpected folder can stop publishing. Vite static deployment and Bolt publishing guidance, read 31 October 2026.

Expected observation: if the production build fails, or the required output is missing, resolve that before testing the deployed app. If the built app opens but reports missing configuration, continue below.

Verify when the app reads the value

For client code using import.meta.env.VITE_API_URL, Vite substitutes the value during the build. It does not wait for the visitor's browser to read a hosting environment variable. Variables with the VITE_ prefix are exposed in the client bundle, so use this mechanism only for public configuration, never a private API key or database password. Vite env variables, read 31 October 2026.

Check the exact variable name and the mode used by the build. Vite loads general env files alongside mode-specific files. A mode-specific value overrides the general file's value; an environment variable already present when Vite starts has higher priority than either. Restart the development server after changing an env file. Vite env loading priorities, read 31 October 2026.

Expected observation: a value that exists only in .env.development is not supplied by that file to a default production build. A successful build alone does not detect this application-level omission, as the following fixture demonstrates.

A small local reproduction

We tested a synthetic Vite client app with a #result element and this module:

const endpoint = import.meta.env.VITE_API_URL;
document.querySelector('#result').textContent = endpoint
  ? `Configured: ${endpoint}`
  : 'Missing VITE_API_URL';

Initially, only .env.development supplied the value:

VITE_API_URL=https://preview.example.invalid

The test displayed the value; it made no API request. These were the observed results:

For the final test, we added .env.production and rebuilt:

VITE_API_URL=https://production.example.invalid

These are dummy addresses for the fixture. In your app, use the intended public configuration value in the environment that actually builds it. Supplying a value only when serving an already-built static bundle did not fix this test. Rebuilding did. This agrees with Vite's build-time replacement rules, read 31 October 2026.

Apply the fix where the build runs

If you use Bolt's Publish button

Bolt's own publishing process builds your project and then looks for its finished output folder. Start inside the project you are publishing. Bolt publishing issues, read 31 October 2026.

1. Open the project on a laptop or desktop in Chrome or another Chromium-based browser. Click the code icon to open Code view, then choose Terminal in the bottom panel. Wait until Bolt finishes any current response before running a command. The Terminal is unavailable in Safari and on mobile. Bolt Code view and supported technologies, read 31 October 2026.
2. Read package.json. If its build script runs vite build, run npm run build in that Bolt Terminal. After it finishes, inspect the generated output folder in the project: normally dist, unless build.outDir changes it. This tests the build in your Bolt workspace; it does not prove that the separate publish build received the same configuration. Bolt Terminal, Bolt build guidance and Vite deployment guide, read 31 October 2026.
3. For the missing public Vite value demonstrated above, edit or create .env.production in the project's Vite environment directory using Code view, enter the intended public value, and save the file. With the default production mode, Vite loads this file; .env is another supported source, with the precedence described above. If the build script specifies another mode, use that mode's env file instead. Never put secrets in VITE_ variables: their values enter the client bundle. Bolt file editing and Vite env loading, read 31 October 2026.
4. Rebuild and check the output. When ready to apply the change to your existing site, open Publish and click Update. Inspect Publish Output for publishing errors, then open the published URL and repeat the same read-only check of the public setting. Editing the project does not automatically update the live site. Bolt publishing and Publish Output tab, read 31 October 2026.

Expected observation: the build creates its configured output, publishing completes, and the published app shows or uses the intended public setting rather than reporting it missing. A successful workspace build alone is not that final check.

Documentation limit: the Bolt publishing and publishing-troubleshooting pages we read do not document how environment values reach Bolt's publish build. The project-file route above follows Vite's documented loading rules and our local reproduction; we have not tested it on Bolt hosting. Verify it at the published URL. If the setting is still missing there, keep the exact error and check Publish Output before assuming another environment change fixed it. Sources: Bolt publishing, publishing issues, Code view and Vite modes, read 31 October 2026.

If you build locally or use Netlify

For a locally built Vite static app, provide the production value before building and validate the resulting output. If Netlify performs the build, its documentation says the variable must be available to that build; where scopes are selectable, include Builds. Do not assume that a variable set only in your local shell is available to a remote build. Netlify build environment variables, read 31 October 2026.

For this Vite client-code case, treat the sequence as: set the public build value, rebuild, test the built output, then use that output for deployment. A server or function that reads a secret at request time needs its own runtime verification. This fixture does not test server configuration, SSR, database access or login flows; do not apply its VITE_ example to secrets. Vite env variables and static deployment scope, read 31 October 2026.

Our validation checkpoint is to repeat the same read-only action against the local build and your deployed URL, checking the expected public setting or resulting behavior rather than only a “published” label. Record which build you checked. If the local build works but the deployed copy does not, establish which files and configuration reached that deployment before making another code change. This is our diagnosis order, based on the unchanged-bundle and rebuilt-bundle observations above.

If the problem is a domain or secure connection

For a .bolt.host secure-connection error, Bolt recommends testing with mobile data and the VPN off, or another network. If the error persists across the networks you try, its next step is to contact support with the site URL. Bolt publishing guidance, read 31 October 2026.

For a custom domain you own, the free custom-domain SSL checker checks DNS and the certificate presented by the domain and its www counterpart. Use the checker's existing email opt-in if offered and wanted. This is the domain/TLS branch; it does not verify the app's build configuration. Checker page, read 31 October 2026.

Need help checking the production mismatch?

Get help with your Bolt app. Start with the failing URL, the build command and the exact error, with secrets removed.