IndustriesWorkPlaybookHow it worksAboutBook a systems auditBring us your idea

Playbook  /  I built it, now what: going live

How do I move my app off Lovable, Bolt or Replit to my own setup?

Straight answer

To move an app off a builder, you take control of three things: the code, the database, and the secret keys. Export or connect the code to your own repository, move the database to a host you control, and reset any exposed keys. Then deploy to your own host and point your domain at it.

Information current as at 5 July 2026

At some point the builder that got you started becomes the thing holding you back: the bill climbs, the limits bite, or you simply want to own what you made. Moving off is very doable, but it is not one button. It is taking control of three separate things, in order.

Plain English
Repository
The stored, versioned home of your code, usually on a service like GitHub.
Environment variable
A secret setting, like a database password or API key, kept out of the public code.
Migration
Moving your database and its data from one home to another without losing anything.
Vendor lock-in
When a platform makes leaving hard because your code or data is trapped inside it.

Step by step

  1. Get the code into a repository you ownMost builders either export the project or connect to a GitHub account. Do that first, into a repository in your own name. This is the moment your code stops being trapped in someone else's dashboard and becomes an asset you hold. If the tool only offers a download, download it and push it to your own repository so it is versioned and safe. Do not start changing anything yet; just secure a copy you control.
  2. Find where the data lives and take control of itIf your app remembers anything (users, orders, entries) it has a database. Often that is a service like Supabase or a database the builder set up for you. Work out where it is and whose account owns it. If it is in the builder's account, create your own account on the same kind of database and plan to migrate the data across. Owning the data is more important than owning the code, because data cannot be rebuilt from scratch.
  3. Reset every secret keyAI builders are notorious for leaving keys and passwords exposed in the code or logs. Before you go live on your own, treat every secret as compromised: regenerate your database passwords and any API keys, and store the new ones as environment variables, which keep them out of the public code. This one step closes the most common serious hole in AI-built apps, and it costs nothing but an hour.
  4. Deploy to your own host and test hardConnect your repository to a host you control, set the environment variables there, and deploy. Test everything on the new setup before you switch your domain: sign-ups, logins, saving data, payments if you have them. Run it in parallel with the old version until you trust it. Only when the new one genuinely works do you point your domain at it and retire the builder.
  5. Decommission the old platform deliberatelyOnce your domain points at the new host and everything works, do not just abandon the old account. Export a final copy of any data, note anything still living there, then downgrade or close it so you stop paying and stop leaving a second, unmonitored copy of your data online. A tidy exit is part of owning your system rather than renting it.
No pressure
Show us what you built.

If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.

Common questions

Questions, answered

Will moving off the builder break my app?
It can if you rush, which is why you run the new setup in parallel and test everything before switching your domain. The risky parts are usually the database connection and the secret keys. Move them carefully, verify each piece, and keep the old version running until the new one is proven.
Do I need to be a developer to do this?
The exporting and account-creating parts are doable by a careful non-developer following each platform's guide. The database migration and key handling are where people get stuck or leave holes. If your app takes payments or holds customer data, this is a sensible point to get a second pair of eyes.
What is the most common thing people get wrong?
Leaving the old secret keys in place. AI builders frequently expose them, and copying the app without resetting them carries the hole straight into your new setup. Regenerate every password and key as part of the move, and store them as environment variables.
Can I keep using the builder and just add my own domain?
Often yes, as a first step: many builders let you attach a custom domain while still hosting the app for you. That buys you a professional address without a full migration. You move off fully when the cost, the limits or the need to own it outweigh the convenience.
Keep reading
Who owns the code an AI wrote for me? →What is an exposed API key and why it matters? →What is a database and does my app have one? →The custom platforms system →All playbook articles →
No pressure
Show us what you built.

If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.

Start here

Two doors. Same senior team.

Whether you can name exactly what you want built, or you just know something is leaking, the next step is the same conversation.