Cancelling Lovable: does your site stay online?

Short answer: yes, your published site keeps running. If you cancel your paid Lovable subscription, your workspace moves to the free plan at the end of the current billing period. Your published app stays online — on its .lovable.app address and on your own domain. What you do notice: you can build far less, you lose a few paid features, and your backend needs credits to keep running.

Below is what happens per part, where the pitfalls are, and what to arrange up front if you want certainty that your site keeps working.

What happens when you cancel or downgrade

Cancelling isn't a hard stop button in Lovable: you stop or downgrade the subscription, your current plan runs until the end of the paid period, and after that your workspace falls back to Free.

Part	What happens on the free plan
Published site	Stays live on yourproject.lovable.app
Custom domain	Keeps working; a connected domain is not disconnected
Editor	Still accessible, but you build with 5 daily credits (max 30 per calendar month)
Monthly and rollover credits	Frozen while you're on Free — you can't spend them
Top-up and bonus credits	Remain usable until they expire
Backend (database, auth, storage, server functions)	Data stays; usage is paid from your credit balance
"Edit with Lovable" badge	Reappears on your next publish
Code	Still yours; git sync with GitHub/GitLab remains the safest exit

One common misconception: your project is not locked after a downgrade. You can still edit — you just hit the ceiling quickly with five credits a day. Fine for a copy tweak, not for ongoing development.

Will my site really stay online, months from now?

For the front end of a static or mostly static site: yes. Publishing is a one-off — the live version keeps being served. You don't need to pay monthly to keep a page up.

Two things can disturb that:

1. Your app uses the backend. A database, login, form storage, uploads or an AI feature consumes credits. If your balance runs out, those backend parts can pause. Pages still load, but signing in or fetching data no longer works. That's the scenario people mean when they say their site "went down".
2. You want to change infrastructure. Connecting a new domain or changing plan-bound settings, for example. Existing connections stay in place; adding new things can be limited.

Roughly: a brochure site or landing page survives a downgrade unnoticed. An app with accounts and data needs an ongoing budget, however small.

What you lose on the free plan

• Build speed. 5 credits per day, capped at 30 per month on Free. Rollover and top-ups are no longer available.
• Frozen credits. Leftovers from your paid period still exist but stay out of reach while you don't pay. Come back and they're available again, as long as they haven't expired.
• The badge. If you had hidden "Edit with Lovable", it returns on the next publish.
• Plan-bound extras. Things like scheduled security scans and team/governance features (roles, per-member limits, SSO) belong to Pro, Business or Enterprise.

What you don't lose: your projects, your code, your data and your published site.

Who owns the code — and how do you get it?

Your projects and code are yours. The safest route isn't "I'll download it later", it's turning on git sync to GitHub or GitLab now. Every change then lands in a repository you control, independent of your subscription. Arrange it before you downgrade, not after.

With git sync in place, you always keep the option to host the app elsewhere.

Fully decoupling from Lovable

If you want certainty without depending on a credit balance, move the app:

1. Export the code. Push your project to GitHub (or GitLab) with git sync.
2. Host elsewhere. Deploy that repository on Vercel, Netlify or Cloudflare — often free or a few euros a month for a small site.
3. Point the domain. Update DNS to the new host instead of Lovable.
4. Don't forget the backend. This is where it usually goes wrong. If you used Lovable Cloud, that backend belongs to your Lovable project. For an external host you arrange your own backend — your own Supabase project, for instance — and migrate data plus environment variables. If you already used an externally connected database, it keeps running separately and you pay and manage it yourself.

Expect steps 1 to 3 to take an afternoon, and step 4 to be the real work for an app with accounts and data. For a marketing site the move is usually trivial.

When is cancelling a sensible choice?

• The project is finished. A campaign site, an event page, a calculator that no longer changes doesn't need a monthly build budget.
• You build in bursts. Many people switch the plan on for a sprint month and off again afterwards. That's fine; your site stays up in the meantime.
• You're continuing in code. Developers on the team? Git sync on, build on in your own environment, host wherever you like.

When not: when users log in, enter data or call AI features daily. Then your subscription isn't just build budget — it's the engine under your app.

What we recommend before you cancel

1. Turn on git sync and verify the repository really holds the latest version.
2. Publish once deliberately, so the live version matches what you see in the editor.
3. Export or back up your database if you use one.
4. Write down which environment variables and external integrations your app uses (mail, payments, analytics).
5. Decide who makes changes in the future — and with what budget.

For current terms and rates, see lovable.dev/pricing and the Lovable documentation, since plans and credit rules change regularly.

Want help decoupling, migrating or professionally scaling a Lovable app? We do this daily — get in touch or read how we work from prototype to production.