Guide - When to move off Lovable Cloud, and when not to

Most of the advice on this question is written by somebody who wants to move you. I do this work for a living, so read it with that in mind. The honest answer is that a lot of apps should stay exactly where they are.

This guide is about how to tell which one yours is: what the built-in hosting is genuinely good at, and the handful of things that mean it is time to move.

Guide · for owners deciding whether to move

When to Move Off Lovable Cloud, and When Not To

Will Pickeral, William Belle LLC · support@williambelle.co

Most of the advice you will find on this question is written by somebody who wants to move you. I do this work for a living, so take this with that in mind, and then read it anyway: the honest answer is that a lot of apps should stay exactly where they are.

This guide is about how to tell which one yours is.


What the built-in hosting is actually good at

Worth saying plainly, because it usually gets skipped.

Lovable Cloud, and the equivalent in Replit and Bolt, gives you a database, sign-in, file storage and a live address from one button. No accounts to open, no bill to interpret, no decisions about regions or instance sizes. For an app in its first year, that is not a compromise. It is the correct call.

It also keeps the loop tight. You describe a change, the tool writes it, and the change is live in a minute. Once your app runs somewhere else, that loop gets longer. Anybody telling you otherwise has not done it.

So the question is not whether the built-in hosting is good. It is whether your app has picked up a requirement the built-in hosting was never meant to carry.


Four reasons that are not good enough on their own

"A developer told me it is not real hosting." It is real hosting. If your app works, has users, and is not holding records the law protects, this is an aesthetic objection and it should cost you nothing.

"I want to own my code." You already do. Your code exports. Owning the code and choosing where it runs are separate questions, and you can settle the first without touching the second.

"It will be cheaper elsewhere." Usually it will not, at your size. A small app on your own cloud account costs more per month than the built-in plan once you count the database, the certificate, the backups and the monitoring. Moving to save money makes sense at scale, and scale is further away than most owners think.

"I might need to scale one day." One day is not a reason. The move is a few days of work whenever you do it, and doing it early buys you nothing you can spend.


Five signs it is time

These are the ones that actually decide it. One is usually enough.

1. A vendor will not sign the agreement you need. If your app holds health records, tax and financial data, or legal matters, you need a data-protection agreement from every company that holds those records for you. In health that is a Business Associate Agreement. Ask your hosting vendor one plain question, in writing: will you sign one with me, on the plan I am on? Keep the reply. If the answer is no, or the yes only comes on a plan you cannot buy, you have your answer and it has nothing to do with the quality of their hosting.

2. Somebody has asked where the data physically is. Customers in health, finance and legal ask this, and so do the people who review them. You need to be able to name a region and show it. If you cannot answer, that is the sign.

3. A customer security review arrived and you could not fill it in. Not the questions about your code. The ones about who can reach the database, how access is removed when someone leaves, how long you keep records, and what happens if the data is taken. Those are answers about the account your app runs in.

4. You need something the platform does not offer. A private network, a specific region, a background job on a schedule, a connection to a system that only accepts traffic from a fixed address, an unusual sign-in method your industry requires. Every platform has a boundary, and the boundary is not a flaw. It is the price of the button.

5. The bill is now large and you cannot see inside it. This is the late-stage version. When per-usage pricing on a busy app passes what a small cloud setup costs, and you cannot tell which part of your app is spending the money, you have outgrown the arrangement rather than been failed by it.

None of these are about the tool that wrote your code. Notice that.


What the platforms themselves say

This part surprises people. The AI build platforms do not claim their hosting is the right home for every app. Their own guidance sends owners with rules to meet, or with data-residency requirements, toward cloud infrastructure of their own, set up with a developer's help.

Read that as what it is. Not a warning about their product, and not an endorsement of mine. It is a vendor being accurate about where their offering stops, which is more than most do.


What moving actually involves

Fewer surprises here than people expect. Your code does not get rewritten.

  • Your code moves into version control you own, with a history of every change. Often this is the first time it has one.
  • A database is created in your own cloud account, and the data is copied across. Your app talks to the new one instead of the old one.
  • Passwords and keys move into a locked store that only your app can open, rather than sitting in the code or in a settings screen.
  • The app gets an address, a certificate, and backups, and something that tells you when it stops responding.
  • Updates are set up to go live on their own, so a change never depends on remembering the right steps.
  • Someone writes down what was built, so you or whoever you hire next can pick it up.

The tight loop you had is the real loss. You can get most of it back, but not all of it, and anyone who tells you the move is free is skipping this paragraph.

For a normal app this is a few days of work rather than a rebuild. Where it takes longer, the reason is almost always sign-in: the built-in one goes away and yours has to replace it without locking anyone out.


If you are not sure

Try these before you decide anything.

  • Ask your vendor about the agreement, in writing, and keep the reply. This one question settles more cases than everything else on this page.
  • Try to reach another user's record. Sign in as a test user, find the address of a record belonging to a different user, and put it in your browser. If it loads, fix that before you think about hosting at all.
  • Write down where your records are. Not a document. A list. If you cannot complete it, that is the honest starting point.
  • Add up what you actually pay across every plan the app touches, and compare it to what a small cloud setup would cost. Do this before believing anybody, including me.

If none of the five signs apply, stay. Come back to this when one of them does.


Where this usually lands

Most owners I talk to are not being failed by their hosting. They are running a good app on a plan nobody will sign an agreement for, and a customer has finally asked. That is a specific problem with a specific fix, and it does not mean starting over with what you built.

Get a free 20-minute review — show me what you have and I'll tell you what I'd fix first in it, and why. If the answer is that you should stay where you are, that is what you'll hear. No pitch, and nothing to prepare.

Twenty minutes, and no pitch.

I'll tell you what I'd fix first in what you've built, and why. No pitch.