Publishing straight from Lovable or Bolt is the right call while you’re still working out whether the idea holds. Once people are paying for the thing, or relying on it for work, running it out of a dwindling balance of build credits starts to look like a strange arrangement, and you want the app on hosting you pay for and control.
The move is four steps. Two of them go wrong in predictable ways, so I’ve written those out in more detail.
What you get out of it
- Your uptime stops being someone else’s decision. The app runs on ordinary hosting with ordinary deploys and ordinary logs, and no plan change at a company you don’t work for can take it down.
- You can hand the project to another developer. With the code in your own repository and the app on a standard host, anyone you hire can pick it up without needing an account on the tool it was built in.
- It usually costs less. Once there’s real usage, application hosting tends to be cheaper than platform credits, and you get environments, rollbacks and a place to add whatever comes next.
Step one: get the code into GitHub
Everything else depends on this, because your host deploys from a repository. Lovable, Bolt and most of the others can sync a project to GitHub in a few clicks, and if you haven’t turned it on yet, here is a short guide.
Once the code is in a repository on your account, the app no longer only exists inside the builder. You can carry on making changes in the builder if you want to. The difference is that you now have a complete copy somewhere it can’t be taken away from you.
Step two: pick a host and do a first deploy
Nothing exotic is needed here. Vercel, Netlify, Railway, Render and Fly.io will all deploy a typical vibe-coded web app straight from a GitHub repository and give you a URL within a few minutes. Which one you choose matters much less at this stage than being on any of them instead of the builder. If the app is a front end plus a hosted database, Vercel and Netlify are the path of least resistance. If it has a long-running server or background jobs, Railway, Render and Fly handle those more naturally.
Connect the host to your repository and let it try a build. There’s a good chance the first one fails, usually because the host picked a different Node version than the builder used, or because the build command it guessed isn’t the one in your package.json. Both are settings you can change in the host’s dashboard, and the build log will tell you which one it is.
Step three: move the environment variables across
The builder set your keys behind the scenes and your new host has its own settings page for them. Until you copy them over, the app will fail in ways that look alarming and are entirely expected: a blank page, a database connection error, a form that submits and does nothing.
Work through every key the app needs, database, AI APIs, email, payments, and set each one on the new host. Two things to be careful about.
First, get the server-side and browser-side ones the right way round. Any variable whose name starts with PUBLIC_, VITE_ or NEXT_PUBLIC_ is compiled into the front end and readable by every visitor. If you copy a service key or a database password into one of those, you’ll have fixed a hosting problem and created a security one. Only the values that genuinely need to be in the browser, a public analytics ID or a Supabase anon key, belong under those prefixes.
Second, reissue anything that was exposed while the app lived on the platform. Most providers let you generate a new key and revoke the old one from the same screen. Do the revoking, rather than leaving the old key alive alongside the new one.
Step four: point the domain at the new host
Your host will give you one or two records to add at your registrar, typically a CNAME on www and an A or ALIAS record on the bare domain. Add those, delete the records left over from the builder, and wait. Propagation takes anywhere from a few minutes to most of a day depending on the TTL that was set on the old records.
The HTTPS certificate is issued automatically once the domain resolves to your host, so a certificate warning at this stage almost always means the DNS isn’t right yet rather than anything being wrong with the app. Change one record at a time and give each change time to settle before you decide it hasn’t worked. dig yourcompany.com from a terminal, or any of the web-based DNS checkers, will tell you what the world can currently see.
When to do it
Do it on a quiet week rather than in the middle of an outage or the day before a launch, and keep the builder’s version published until the new one is confirmed working. When the domain has moved and nothing is on fire, you have a product that runs on infrastructure you understand and can hand to anyone.
Steps three and four are the ones I get asked about most, and they’re the ones where a mistake is expensive rather than obvious: a key left live, or a domain half-moved while customers are trying to use it.
