Skip to content
OneLessTool

Guide · updated

Will your Lovable app keep working after you cancel?

Separate Lovable code export from hosting, data, authentication and running services before deciding whether a paid builder subscription can go.

Canceling a Lovable subscription does not automatically require moving the app, but a working homepage does not prove the whole app will keep working. Lovable says cancellation moves the workspace to Free at the billing period's end and published apps remain live, subject to its inactivity rules. Paid subscription credits become unavailable on Free. Lovable's cancellation documentation.

The decision is whether your app can operate with the entitlements and services you will retain. This guide covers one existing live app, not a promise that every Lovable project survives every downgrade unchanged. Documentation was checked on October 21, 2026; no subscription was changed or live app tested.

Exporting code is only one part of continuity

Standard github.com sync is available on all Lovable plans, including Free. It can export code and synchronize changes in both directions; GitHub Enterprise connection types have separate Enterprise requirements. Lovable's GitHub integration. You do not need to keep a paid Lovable plan solely for standard GitHub sync.

The one-time ZIP download is a different entitlement: Lovable documents it on paid plans. Both methods provide source code, not the database records or uploaded storage files. Lovable's source-code export instructions.

Identify the actual framework before choosing another host. Lovable distinguishes older React/Vite static builds from TanStack Start apps needing a server runtime. Hosting the latter's static files alone leaves server features missing. Lovable's hosting and ownership guide. A repository you can open is an asset; a deployment that completes the customer's job is the acceptance test.

Inventory the running app, not just the builder

Create one row per dependency, with its account owner, backup operator, destination or retained provider, and billing owner. Use this checklist to ask concrete questions:

Part What you must be able to recover or operate
Source and deployment Known commit, build instructions, dependencies and a compatible host
Domain and hosting Domain ownership, DNS configuration, certificates, routing and deployment access
Database Required records, relationships, schema and access rules
Authentication User accounts, sign-in providers, redirects and authorized roles
Uploaded files File contents, paths, access rules and links from records
Functions and jobs Server code, schedules, secrets and failure handling
External services Email, payments, AI and other integrations, including their separate accounts

Lovable's built-in backend includes database, storage, authentication and functions; these are distinct from the frontend. Lovable's backend overview. The table is an inventory to complete, not a claim that exporting one component automatically exports the others.

For a backend move, Lovable documents separate handling for storage, authentication configuration, function deployment and secrets. App-connector connections do not export; calls that depend on them need replacement when the backend moves. Lovable's migration scope. Have a qualified operator inspect the actual export and destination rather than assuming every account or integration is portable unchanged.

Staying hosted still needs an operating budget

Current documentation describes one workspace credit balance, with usage-specific grants and general credits. Building, hosting/backend usage, app AI and some managed connectors draw on that system under different rules. Lovable's credits and usage. Separate the operational dependencies in your worksheet without inventing separate bills or counting the same credits twice.

When eligible Cloud credits run out, backend services can pause even while published pages continue serving. AI-dependent features can fail separately. Lovable says backend data cannot be accessed or exported while the backend is paused. Lovable's out-of-credits behavior. Export and rehearse recovery while access works; loading the landing page is insufficient evidence.

Custom domains require Pro or above; they are not included on Free. Lovable's plan comparison. The cancellation page's statement that published apps stay live does not establish what happens to an already connected custom domain. Before downgrading, confirm that domain's behavior with Lovable and record the answer alongside the app's access and usage arrangements. If you move only the frontend, record which Lovable services remain. Neither route justifies assuming an empty future bill.

UNEXECUTED pilot: restore a copy before changing production

This is a proposed rehearsal for your developer or administrator. We have not executed it. Keep the production app, domain, backend and subscription untouched throughout. Use an isolated copy, dummy accounts and test data; disable outgoing customer messages, payment actions and production webhooks in the copy.

  1. Freeze a reference. Record a source commit, configuration inventory and dated exports. Keep an unchanged archive. Select ten representative records, three uploaded files, two user roles and one background job as a small test set. List expected relationships and permissions before restoring anything.
  2. Build the copy. Use a separate repository or isolated deployment branch with no production auto-deployment. The operator documents the framework, build command and destination. A second person must reproduce the deployment from those instructions.
  3. Restore data and files. Compare the selected records and relationships. Open the three files through the copied app as well as the archive. Have the backup operator retrieve a designated older record and its attachment without help from the exporter. An empty app that accepts new data fails this test.
  4. Exercise access and jobs. Test both roles, sign-out and a new sign-in, an unauthorized file request, a record update and the background job. Use test endpoints for integrations and record which real-service behaviors remain untested. Do not claim a simulated payment proves production payments work.
  5. Rehearse recovery. Introduce a reversible defect only in the copy, restore the saved version and repeat retrieval. Measure elapsed recovery time and have the backup explain what data changed after the snapshot. Agree an acceptable recovery time before judging the result.

Stop if records are missing, an unauthorized role sees data, a required function has no owner, or recovery depends on the original builder's personal account. Retain the current arrangement while resolving failures.

A later production migration needs its own approved plan for writes arriving after the export, including jobs and webhooks. Lovable's migration guide explicitly separates final data synchronization from switching traffic. Lovable's complete-move checklist. Reverting DNS alone cannot reconcile two diverging databases. Keep a documented route back and an owner for that reconciliation.

When to keep paying, and what can actually disappear

Keep Pro or above if the app needs a custom domain on Lovable, or complete and verify a domain and hosting migration before downgrading. Keep the paid builder if ongoing changes require its paid capabilities, the backup cannot maintain the app, or operational support would exceed the removable charge. Keep necessary hosting and runtime services even when building has stopped. A successful copied deployment is evidence for a later decision, not authorization to delete the original backend.

Use your invoices and destination quotes for the same months, app workload and service scope. Record the effective downgrade date, remaining commitment and any continuing top-ups or provider charges:

Potential reduction = current total for this app − remaining total after the proposed change.

Put existing charges in the current total. Put retained hosting, backend and external-service charges plus new replacement costs in the proposed total, each counted once. A retained charge appears in both actual totals; a new replacement cost appears only in the proposed total. Show migration effort and continuing maintenance time separately. If the subscription is committed through the comparison period, the task may move while contractual savings remain zero.

Use the subscription audit to record only a removable charge, and the cancellation checklist to track the final account and invoice checks. Current OneLessTool options are on pricing.