How to Move a Lovable or Bolt App to Your Own Hosting

Lovable and Bolt make it easy to build an app and put it online without thinking about servers. That is their strength. But when the app becomes important to your business, you may want it to live in accounts that are yours, not inside the tool that generated it. Both tools allow this. This guide explains why founders do it, the steps in order, and the problems to expect.

Why move to your own hosting?

• Ownership. The code, the database and the domain sit in accounts in your name. If a tool changes its rules, or you stop using it, your app stays online.
• Cost control. You pay the host and the database for what the app uses. You can see each bill and change provider if one becomes too expensive.
• Freedom to hire anyone. A freelancer or a studio can work on a standard project in GitHub with their usual tools. They do not need to work inside your builder account.

You do not have to leave the builder to do this. Many founders keep building in Lovable or Bolt while the code also lives in their GitHub account.

What exactly are you moving?

An app is not one thing. It has four parts, and each one moves in a different way:

• The code. The files that make the screens and the logic.
• The backend. The hidden part: the database, the logins and the stored files.
• The secrets. The keys and passwords the app uses to talk to the database, the payment service and other services.
• The domain. The address people type to reach the app.

This gives you two levels of move. The first level moves only the code and the hosting, and the app keeps talking to the same backend. The second level also moves the backend to an account you own. The first level is quick. The second needs more care, because it touches your users and their data.

The six steps, in plain words

• 1. Get the code into your own GitHub account. GitHub is the service where code is stored. Lovable and Bolt can both connect a project to GitHub. Create the account yourself, with your own email address, and connect it from the builder. Do not let the code live only in the account of a freelancer.
• 2. Own the database account. If your app already uses a Supabase project that you created, you own it already. If it uses the backend built into the builder, check the current documentation: Lovable describes how to move a project to your own Supabase account, and Bolt lets you claim its database in Supabase.
• 3. Set the secrets. Secrets are never stored with the code, and that is a good thing. On the new host you add them one by one as environment variables (settings that the host keeps private and gives to the app when it runs).
• 4. Deploy on a host. Create an account on a host such as Vercel or Netlify, connect your GitHub project and start the first deploy (the step that builds the app and puts it online). You get a temporary address to test with.
• 5. Connect your domain. Buy the domain in your own name if you have not done so. Add it on the host, then change the DNS records (the settings that tell the internet where your domain points) as the host asks.
• 6. Test everything. Sign up with a new email, log in, reset a password, upload a file, make a test payment. Do it on a phone too. Keep the old version online until the new one passes every test.

Moving the code takes an afternoon. Moving the data and the logins without losing a user takes a plan.

What usually goes wrong?

• A missing secret. The app builds, but the page is blank or nobody can log in. In most cases one environment variable is missing or has a wrong name.
• Logins that point to the old address. Login with Google and confirmation emails send users back to an address you set earlier. After the move, the new address must be added in the login settings.
• Data that does not follow. When you change backend, the structure of the database can be recreated, but the content and the uploaded files must be exported and imported. Check the numbers before and after.
• Users who must log in again. After a backend move, open sessions do not carry over. Tell your users before you do it.
• Payment messages sent to the wrong place. Your payment service sends messages to your app (called webhooks) to say a payment worked. If they still go to the old address, people pay and get no access.
• Features that used the builder. Some AI features or connections run through the builder itself. If you leave its backend, you must replace them with your own account at another provider.

Does moving make the app ready for real users?

No, and this is important. A move changes where the app lives. It does not change how the app is written. If one user can see the data of another user before the move, it is still true after. Hosting and security are two separate jobs.

The good news is that the move is a perfect moment to check the rest. Our guide on launching a Lovable app to real users lists the eight points to verify, and the free launch check shows where you stand in two minutes.

When should you ask for help?

• Real users are already in the app. A mistake during the move can lock them out or lose data.
• You take payments. The payment settings must move at the exact same time as the app.
• You need to move the backend, not only the hosting. This is the part with the most steps and the most traps.
• Someone else holds your accounts. Getting the code, the domain and the hosting back into your name comes first.
• The first deploy fails and you do not understand the error. Asking the chat to fix it again and again often makes the code harder to read.

At Swipe Up, we do this as part of finishing AI-built apps. When it makes sense, we move the app onto hosting and a database you own, so you are no longer tied to the tool that generated it. It starts with a fixed-price audit, and everything stays in your name. If you wonder whether your app should be moved as it is or partly rebuilt, read rebuild or fix a half-built app first.

The bottom line

Moving a Lovable or Bolt app to your own hosting is possible, and both tools support it. Start with the easy level: code in your GitHub account, deployed on a host you pay yourself, on your own domain. Move the backend only when you have a reason and a plan. And remember that a new home does not repair the app. Check the security and the payments at the same time, while everything is open in front of you.