Leaving Lovable can mean moving the hosting, moving the database out of Lovable Cloud or no longer building with the tool, and the first two work without the third: at Sistema Forja, infrastructure went from about R$ 2,000 to about US$ 20 a month and the client kept editing the app in Lovable. If you are still validating the idea, stay where you are. Rebuilding only makes sense for one part, when search is the product or when money flows through the app.
What "leaving Lovable" actually means#
Leaving Lovable can mean three things: moving the app's hosting, moving the database out of the cloud built into the tool, Lovable Cloud, or no longer building by talking to the AI. The first two work without the third. Lovable's own documentation describes this setup, with development in Lovable and the live app running somewhere else.
Lovable's documentation lists three setups. In the first, which is the one they recommend, everything stays on Lovable. In the second, Lovable remains where you develop and the production app runs on a platform such as Vercel, Netlify or AWS. In the third, all the infrastructure belongs to the company. In the last two, what connects Lovable to production is GitHub: the code syncs both ways with a repository, and the hosting platform deploys from it. And, according to the same documentation, the code belongs to whoever built it.
When the app does not need to leave Lovable#
The app does not need to leave Lovable while it is still validating the idea, while the monthly bill is small and predictable, and while no payment or sensitive data depends on a rule that runs on a server. At that stage, the speed the tool gives you is worth more than any infrastructure savings, because you still need to be able to change your mind quickly.
A product with a few dozen users, still finding out whether anyone will pay for it, gains little from its own hosting and ends up with one more account to look after. When someone comes to us at that stage thinking they need to migrate, our advice is usually to stay.
One of the reasons people want to leave, showing up on Google, also lost weight in 2026. According to Lovable's documentation, since May 13, 2026 every new project is created with server-side rendering, using a framework called TanStack Start, and the page arrives ready for any visitor or crawler. Older projects can be upgraded to that format by the tool itself.
Even when migrating makes sense, it rarely means rewriting the app. At Sistema Forja, an app built on Lovable that we audited when it already had 1,312 active users, the audit found the architecture adequate for that scale, and what changed was where the database and the hosting lived.
The signs that the app needs to leave, and the path for each one#
The signs that an app needs to leave Lovable are a cloud bill growing with no explanation, the product becoming a company asset that has to be in the company's name, organic search being what drives the business, and money flowing through the app. Each sign calls for a different path, and only some of them call for rebuilding part of the app.
| Sign | What it means | Path |
|---|---|---|
| Still validating the idea, with few users and nothing charged through the app | the product is in discovery, and speed matters more than infrastructure | stay |
| The project predates May 2026 and its pages do not show up well on Google | the app builds the page in the visitor's browser | stay and upgrade the project to the server-rendered format |
| The monthly bill keeps growing and nobody can say why | database and hosting are paid with the same credits as building | move only the hosting and the database |
| The product needs backups, direct database access and accounts in the company's name | the app has become a company asset | move only the hosting and the database |
| One more person is going to touch the code, or a change has already broken the live app | there is no path between work in progress and what users see | move only the hosting, with GitHub and a working branch |
| The business depends on being found in search, with a page for each job, product or company | search is where customers come from | rebuild one part: the public site |
| The app is going to charge subscriptions, unlock plans or move credits | the rule has to run on a server and check every notice from the payment provider | rebuild one part: the layer that receives payments |
| The app needs to talk to the ERP or another company system | the integration needs a server that keeps the credentials | rebuild one part: a server of your own next to the app |
When rebuilding shows up in the table, it is always one part. The interface and flows the owner built by talking to the AI almost always stay, and the reason is explained in what can be saved from AI-generated code.
When the Lovable Cloud bill starts to weigh#
The Lovable Cloud bill starts to weigh once the app has real usage, because database, hosting and server functions are paid with the same credits that pay for building through chat. At Sistema Forja, a Brazilian app, infrastructure cost about R$ 2,000 (Brazilian reais) a month on the tool's cloud and dropped to about US$ 20 a month in the client's own accounts.
According to Lovable's documentation, Cloud usage comes out of the same credit balance as building. Plans get a monthly Cloud grant of 20 credits, anything above it comes out of the general balance, and paid plans offer auto top-up. The owner sees a single number and has a hard time telling how much went into building and how much went into keeping the app running. With your own Supabase, the database usage is billed by Supabase, on the plan of whoever owns the account.
At Sistema Forja, a platform for habits, goals and personal finances built by its founders on Lovable, there was a daily charge that kept debiting for days without anyone noticing, and credit purchases above actual usage. With the database on its own Supabase and the site on dedicated hosting, the bill dropped to about US$ 20 a month, with automatic backups and without taking the product offline.
This move has a detail that catches people off guard. Lovable's documentation says there is no one-click migration from Lovable Cloud to your own Supabase: you have to export the data, create a new project connected to Supabase and rebuild the database structure, and users and files are also moved by hand. At Forja, that meant opening a new Lovable project already connected to the client's database, and that is the project the client kept working in.
When the app needs to show up on Google and in AI answers#
The app needs server-side rendering when the business depends on being found in search. A page that is only assembled in the browser arrives empty for many crawlers. According to an analysis by Vercel and MERJ published in December 2024, the AI crawlers from OpenAI, Anthropic, Meta, ByteDance and Perplexity do not execute JavaScript. Google's and Apple's do.
A single-page app, the format of Lovable projects until May 2026, delivers an almost empty page plus a program that builds the content in the browser. A crawler that only reads what comes from the server sees the whole site as a single page. Google runs the JavaScript after a rendering queue, and Google's own documentation recommends server-side rendering, because not every crawler can run JavaScript.
A job board that came to us built on Lovable stopped right there. The owner had built a jobs site with a candidate area, a company dashboard and an admin panel, and the last requests he made to the tool, in June, were all about getting the site to show up on Google. The tool's own answer was that the project did not do server-side rendering, and it recommended moving the site to Next.js, outside Lovable.
Today Lovable's documentation tells a different story. Older projects get a pre-rendered version of their pages, served only to verified crawlers: Google, Bing, link-preview bots and the AI search engines of ChatGPT, Perplexity, Claude and Gemini. The documentation describes this for apps published by Lovable itself and does not say what happens to it when the hosting moves elsewhere. The safe assumption is that it stays behind, so upgrade the project to the new format before migrating.
For the job board, rendering was only the first wall. A jobs site depends on every job and every company being a page of its own, with its own title, that a crawler can read. In his app, many of the pages listed in the sitemap returned the home page content, and the city pages pointed to an address that did not exist. Moving the hosting does not fix that. In the scope we are modeling, the public site is built from scratch with server-side rendering, and what he built on Lovable became the reference for the screens and behavior of a custom-built system.
When money flows through the app#
When the app charges subscriptions, unlocks plans or moves credits, the rule that decides it has to run on a server and check every notice that comes from the payment provider. It is the part of the app where chat-generated code fails most often, and the part most worth rebuilding, even if the rest of the product stays on Lovable.
At Sistema Forja, the payment endpoints accepted requests with no authentication and no signature verification, and anyone who found the address could fake an approved purchase. The fix was to redo that layer, so that a notice without the correct secret is rejected before any processing. The app stayed on Lovable, and the rest of the product was not rewritten.
In the job board, billing did not exist at all. The only business decision the owner had already made, free for candidates and paid by companies, was exactly what the app did not do: no payment provider was connected, no company was tied to a plan, and the payments screen in the dashboard showed sample numbers. The AI will draw a billing screen in a single request, but the payment provider's notice, the failed attempt and the plan that drops when the card is declined only exist once someone writes the rule.
Before charging your first customer through the app, it is worth running an audit of the AI-built app that starts with that layer.
How to move the hosting off Lovable and keep editing in it#
You can move the hosting and the database off Lovable and keep building with the tool. The code lives in a GitHub repository in the company's account, the hosting deploys from it, and Lovable works on a branch separate from the one that is live. That is how Sistema Forja was handed back to the client, who kept editing the app in Lovable.
At Forja, the product was delivered running in the client's own accounts: the repository on his GitHub, the hosting on Vercel linked to that repository, the database on his Supabase and the domain pointed to the new setup. Every change made through chat in Lovable becomes a commit on a working branch, which does not go live. To publish, someone merges that branch into the main one, and the hosting updates the app on its own. Lovable's documentation confirms the pieces: GitHub sync works both ways and follows one branch at a time, chosen in the project settings.
There are two things to watch. The first is the database. In the setup we delivered there is a single database, with no staging environment, and a structural change made through chat takes effect immediately, even before the branch goes live. That was handed to the client in writing, as a risk that stayed with him. The second is the project format: according to the documentation, projects created from May 13, 2026 run code on the server and need hosting that executes that code, not just a place that serves files.
What the owner takes on when hosting leaves Lovable#
When hosting leaves Lovable, the owner gets the account in the company's name, direct access to the database and a bill that can actually be read. In exchange, the owner becomes responsible for what Lovable handled on its own: monitoring, the domain certificate, database operations, login and what to do when the app goes down on a Saturday night.
Lovable's documentation is direct about it: the tool cannot monitor or debug infrastructure it does not control, and the list includes deployment, certificates, logging, database operations, authentication and security scanning. If nobody at the company knows how to look after that, someone has to be hired to do it, even if only for a few hours a month.
Moving the hosting pays off when your own infrastructure will cost less than today's bill and there is someone to look after it. Until there is someone, the best move is to stay on Lovable and understand the credit bill before changing anything.
Frequently asked questions#
Can I keep editing in Lovable after moving the hosting?#
Yes. With the project synced to a GitHub repository, the hosting platform deploys from it and Lovable stays the place where you build, an arrangement Lovable's own documentation describes. At Sistema Forja, the client kept editing in Lovable on a working branch and publishing by merging that branch into the main one.
Does an app built on Lovable show up on Google?#
Yes. According to Lovable's documentation, projects created since May 13, 2026 have server-side rendering, and older ones get a pre-rendered version served to verified crawlers such as Google, Bing and AI search engines. To rank, the site still needs its own page, with its own title, for each thing people search for.
What is the hard part of moving from Lovable Cloud to your own Supabase?#
According to Lovable's documentation, there is no one-click migration. The database structure moves through migrations, but data, users, files and login providers are moved by hand, and you have to create a new Lovable project connected to Supabase. At Sistema Forja, the move happened without taking the product offline and without losing a single record.
Do I own the code built on Lovable?#
According to Lovable's documentation, the apps, code and content you create there are yours, subject to third-party rights such as open-source licenses. Code syncs with GitHub on every plan. In practice, what secures ownership is having the repository, the hosting and the database in accounts held by your company.
Do I need to rewrite the app in another technology for it to grow?#
Almost never the whole app. What usually gets rebuilt is one part: the layer that receives payments, the integration with another system or the public site, when search is the product. At Sistema Forja, the audit found the architecture adequate for its scale at the time, and the client kept evolving the app in Lovable.
Sources#
- Lovable, deployment, hosting and ownership options (the three setups, code ownership and where the database can go): https://docs.lovable.dev/tips-tricks/deployment-hosting-ownership
- Lovable, deploying and hosting outside Lovable (what is migrated by hand, hosting for server-rendered projects and what becomes the host's responsibility): https://docs.lovable.dev/tips-tricks/external-deployment-hosting
- Lovable, Lovable Cloud (no one-click migration to Supabase): https://docs.lovable.dev/features/cloud
- Lovable, connect to Supabase (who bills database usage): https://docs.lovable.dev/integrations/supabase
- Lovable, credits and usage (the monthly Cloud grant and auto top-up): https://docs.lovable.dev/introduction/credits-and-usage
- Lovable, sync your project with GitHub (two-way sync, one branch at a time): https://docs.lovable.dev/integrations/github
- Lovable, SEO and AI search (server-side rendering since May 13, 2026 and pre-rendering for verified crawlers): https://docs.lovable.dev/features/seo-aeo
- Lovable, upgrade a project to TanStack Start: https://docs.lovable.dev/features/upgrade-to-tanstack-start
- Vercel and MERJ, "The rise of the AI crawler", December 17, 2024: https://vercel.com/blog/the-rise-of-the-ai-crawler
- Google Search Central, JavaScript SEO basics: https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
Next step#
If your app was built on Lovable and you are unsure whether to stay, move the hosting and database, or rebuild one part, that is the question we answer in our vibe coding audit. We look at the code, the database and the bill, and tell you what stays, what moves and what needs to be redone, as we did at Sistema Forja.