Take your Bolt app from prototype to production

Bolt runs the editor, the install step and the dev server inside the browser tab, so the first job is to get a copy that lives somewhere else. The project can be downloaded as an archive or pushed to GitHub, and the repository is the version everything afterwards depends on.

That copy is also the first honest inventory. Until the project builds on an ordinary machine from the repository alone, nobody knows whether what you have is the application or just the part of it that happened to be open.

Bolt's own documentation shows three configuration values side by side for a Supabase project: the URL and anonymous key, both prefixed `VITE_`, and the service-role key, deliberately without that prefix. The prefix is not a naming convention. It is the switch that tells the build tool to copy a value into the JavaScript the browser downloads.

So a value renamed to start with `VITE_` becomes public the moment the site is deployed, whatever the file it was written in. This is the single most consequential thing to know about a Bolt project, because adding the prefix is also the quickest way to make a stubborn error disappear during development, and the error does come back as something far worse.

Bolt creates a Postgres database for a project when it needs one, and can also connect to a Supabase project you own. Its introduction to databases describes authentication and permissions deciding who can read and change data, and warns that anyone holding your keys can do both.

What that page does not name is row-level security, which is the mechanism that actually enforces those permissions in Postgres. That gap matters because an app talking to the database from the browser has nowhere else to enforce anything. If the rules are absent, the screens are the only thing standing between one customer and another's records, and changing a number in a request walks straight past them.

Publishing a Bolt project to a host is genuinely one step, and that is the problem: it sets an expectation that everything travelled. Configuration values do not. They are set in Bolt, and they have to be set again in whatever runs the site, which is why a freshly deployed app so often loads and then fails the moment it touches the database.

The things a business needs around a deployment are also not part of that step. A custom domain, a staging copy to try changes on, a way for someone else to ship while you are away, and a record of what was deployed when, all have to be put in place deliberately.

A Bolt app is typically a single-page application: one near-empty HTML file serves every address and the content is assembled afterwards by JavaScript. Anything reading your pages without running scripts therefore sees nothing, which is why a working product can be absent from search results and unknown to assistants at the same time.

The fix is usually cheaper than it sounds, because only the public pages need to be readable. The signed-in application can stay exactly as it is.