How to self-host a Bolt.new app

The good news first

Compared to most AI builders, Bolt makes getting your code out straightforward. You can download the project, or push it to your own GitHub repository, and what you get is an ordinary front-end project — usually Vite with React and TypeScript. Standard package.json, standard build, no proprietary format.

If your app is genuinely just a front end — no logins, nothing saved between visits — you are nearly finished. Build it, upload the output to any static host, point your domain at it. That is an afternoon at most, and you do not need us for it.

The trouble starts the moment the app remembers anything.

What the browser was hiding

Bolt runs your project inside the browser tab, in a sandboxed Node environment. It is a genuinely clever piece of engineering and it makes the build loop feel instant. It also quietly papers over the difference between “this works” and “this is deployable”.

Everything below behaved perfectly in that sandbox and stops behaving the moment the app has to live on a machine that other people can reach.

Which situation are you in?

You added a database through the builder

If you connected Supabase, then your data, your users and your uploaded files live in a project you may never have opened directly. That is a migration in its own right, and it is the same job whichever builder you started from — the mechanics are written up in detail onthe Lovable page, and they apply here without changes.

You never added one

More common than people admit. The app looks like it stores things because it stores them for you, in your browser, for as long as that tab is open. Two users never see the same data, and clearing site data wipes it.

Here the honest answer is that self-hosting alone will not fix it. You need an actual database and a small server that owns access to it. That is a build, not a move — and anyone telling you otherwise is about to hand you something that breaks the first week it has customers.

You deployed to a static host and stopped there

You have a working URL and a build pipeline, which is real progress. What you do not have is anywhere to run server code, anywhere to put a database, or control over what sits in front of the app. Moving from there to your own machine is the most straightforward version of this job.

What moving it actually involves

1. Get the project into your own repository. Not a zip on a laptop. A repository with history, so the next change is reviewable and reversible.
2. Make it build from a clean checkout. Fresh clone, install, build, with nothing borrowed from the environment it grew up in. This step catches more problems than any other.
3. Give it a real backend if it needs one. Postgres, plus a small server that owns database access rather than exposing it to the browser.
4. Collect every secret. Payments, email, third-party APIs. They were in the builder’s settings, and they are not in your code.
5. Put it behind a proxy with TLS. Certificates that renew themselves, in your account, on your domain.
6. Leave a way to deploy again. Compose files and a pipeline, so the next change does not require whoever did the migration.

Where it goes wrong

• “It works locally” is not the same as building cleanly. Dependencies that were present in the sandbox and absent from package.json surface here, and they surface as a build that fails on someone else’s machine.
• Browser-held data is discovered too late. Usually on the day the app goes live and the second user sees an empty screen.
• Nothing supervises the process. The server runs until it crashes, and then it stays down until a human notices. Restart policies and a health check are ten minutes of work and the difference between an outage and a hiccup.
• No backups on day one. A new database with no dump schedule is a database you will eventually lose.

Or have it done

We take the project from wherever it currently lives and put it on infrastructure you own: your repository, your database, your domain and certificates, plus a pipeline so the next deploy does not need us.

From $600 — about a day of work once we have access. In practice the engineering is the short part; waiting on server credentials is what stretches a migration out. Gather those first.

If your app turns out to need building rather than moving, we say so and quote that honestly instead of pretending it is a migration.