Bolt.new app will not deploy: where to actually look

The environment is the difference

Bolt runs your project inside your browser rather than on a server somewhere. That is what makes it fast and what makes it feel like a real terminal. It also means the environment your app grew up in is not the environment it will live in.

Most of the time this does not matter. When it does, it shows up at exactly one moment: the first time you deploy somewhere real.

Read the build log, not the page

A white screen tells you nothing. The build log tells you which of two very different problems you have.

• Failed during build: a dependency that is missing, or an import that does not resolve. Your host is installing packages differently from how Bolt did.
• Built fine, then crashed on start: an environment variable that is not set. This is the most common one by a wide margin.
• Built and started, blank page: open the browser console. Usually a request to a URL that only existed in the preview.
• Works, then fails once more than one person uses it: database connections, not code.

The environment variable list

The single most useful thing you can do before deploying is write down every environment variable your app expects. Not the ones you remember adding — all of them.

Search your project for the pattern your framework uses to read them. Every match is something your host needs to know. An app missing one variable usually fails in a way that looks nothing like a missing variable.

Where Bolt differs from Lovable

Bolt gives you the whole project — the file tree, the terminal, the ability to download everything. That is more control and more rope.

Lovable is more opinionated: it wires up a specific backend for you, so its failures are more predictable. With Bolt, the backend is whatever you told it to build, which means the gaps are wherever your own instructions ran out rather than in a known place.

Practically: with Lovable, check the database rules first. With Bolt, check what the backend actually is first, because that answer varies.

Before you assume the code is broken

It usually is not. Deployment failures in projects from these tools are overwhelmingly configuration, not logic. The code that ran in the preview is generally the same code that will run on your host, once the host knows what the preview already knew.