Do you actually own your Lovable site?

The short answer

You can own a Lovable site’s code, and Lovable makes that easy: on every plan, including Free, a project can be connected to GitHub (or GitLab or Bitbucket) so the source lives in a private repository under your own account, kept in sync both ways. You can own the domain, whether you bought it through Lovable or elsewhere. What you may not own yet is the rest of the live site: if the project uses Lovable Cloud, its database, sign-in, storage and server functions run on Supabase infrastructure that Lovable manages and bills in credits, and if Lovable hosts the site, the publish button is Lovable’s. The ownership question is therefore: is the code in your GitHub, is the backend in your Supabase or in Lovable Cloud, and whose account is the domain in?

Lovable’s own position is clear. Its pricing page says you own your code, the apps and sites you build, the customer data stored in Lovable, and the AI output you generate.

What you should own

What Lovable controls by default

• The code, until you connect GitHub. A new project’s code exists only in Lovable. Git sync is free but has to be turned on, and it only creates a new repository; it can’t attach to one that already exists.
• Hosting. Publishing goes to yourproject.lovable.app, free on every plan, and that address can’t be removed from the project. Lovable’s terms say it owns the lovable.app domain and can reassign or suspend any subdomain, which is one reason to put a real domain on anything that matters. Custom domains need a paid plan.
• The backend, if it’s Cloud. Lovable Cloud runs on Supabase but is managed and billed by Lovable through credits; you don’t get a Supabase project of your own for it, and it pauses if the workspace runs out of credits.
• Secrets. Backend secrets are write-only after saving. You can replace them, never read them.
• The framework. Projects created from 13 May 2026 use TanStack Start, which renders on the server; older ones are React + Vite. Lovable documents deploying the Vite kind elsewhere, not yet the newer kind.
• Built-in AI features call models through a Lovable-managed key.

None of that is unusual, and Lovable is open about all of it. The point is to know which side of each line your project is on.

How to make the site portable

1. Connect GitHub from your own account. Settings, then Git. If someone else connected theirs, disconnect and reconnect with yours; Lovable creates a fresh repository under you. Don’t transfer, delete or rename the account of a connected repository, because that breaks the sync.
2. Decide about the backend. If you connected your own Supabase project, it’s already yours and Lovable is a client of it. If the project uses Cloud, you can keep Cloud and still host the frontend elsewhere, which Lovable supports; or move toward your own Supabase, which is partly an export and partly a rebuild. The guide to moving a Lovable Cloud site toward your own Supabase says exactly which parts are which.
3. List the secrets from the Secrets panel by name, and note which service issued each.
4. Check the domain. A domain bought through Lovable is registered at Name.com as the sponsoring registrar and managed from Workspace settings; it can be pointed at your own nameservers or transferred out after the 60-day lock, as the builder-domain guide describes. A domain you connected from elsewhere is already yours.
5. Prove the deployment path. Connect Vercel, Netlify or Cloudflare to the repository and get the site running on the host’s own address. For a Vite project Lovable documents the settings; for a TanStack Start project a developer or coding agent sets it up.

The full sequence, including DNS and what to do with Lovable afterwards, is in moving a Lovable site to GitHub and your own hosting. You don’t have to complete it to be an owner; steps 1 and 4 are what make the site yours, and the rest is what makes it movable.

What may not move automatically

• Data. The repository holds migration files that describe the database, never the rows. Lovable exports Cloud databases of up to 15 GB, with the export file itself capped at 5 GB, once per 24 hours, into Cloud storage; it disappears if Cloud is removed before you download it. The export doesn’t include storage files, edge function code or secrets.
• User passwords. Cloud exports user records without passwords; users reset them after a migration.
• Storage files, exported separately from the Cloud storage view.
• Secrets, which must be re-issued at their source.
• Lovable Emails, which run on Cloud and are billed in credits; a site using it needs its own sending service elsewhere.
• Sync direction. If Lovable and GitHub diverge, GitHub wins and Lovable’s edits go to a separate lovable-sync branch. Commits made elsewhere reach Lovable only when GitHub notifies it.

What happens if you stop using Lovable

What Lovable’s documentation says, and only that. The cancellation guide compares all four builders and separates downgrading, deleting and being cut off.

• A published site stays live indefinitely; there’s no expiry for inactivity. Downgrading or cancelling doesn’t unpublish it or disconnect a custom domain.
• Apps that use Cloud or built-in AI need available credits to serve requests, and a project pauses when the workspace runs out of credits.
• On a Free workspace, the “Edit with Lovable” badge returns on the next publish, and the code editor is read-only.
• Domains bought through Lovable are billed separately and keep renewing after a plan change.
• For most features, Lovable says it keeps your configuration on a downgrade so they resume if you upgrade again.
• Disconnecting GitHub leaves the repository intact; it stops syncing.
• Removing Cloud permanently deletes the Cloud instance. Deleting a project is permanent. Deleting an account has a 30-day grace period and a workspace 60 days, after which projects, custom domains and data are removed.

What we could not verify: whether Lovable ever deletes inactive projects on a live account, and how long an unpaid Cloud instance is retained before anything is removed. Treat those as unknowns and keep your own exports.

Ownership checklist

The real test

For a Lovable site with GitHub connected and its own Supabase project, the answer is yes: the repository plus the Supabase account is the whole site. With Cloud, the answer is “yes, but the backend stays on Lovable’s meter until it’s migrated”. Without GitHub connected, the answer is no. The portability test scores all nine layers.

Sources

The rules and product behaviour described above were checked against these pages when the guide was last updated. If something here has changed, these are the places to look.

• Pricing FAQ: who owns the code · Lovable
• Terms of service (28 August 2026) · Lovable
• Delete your account · Lovable
• Delete a workspace · Lovable
• GitHub integration · Lovable
• Git sync overview · Lovable
• Subscription plans · Lovable
• Cloud · Lovable
• Advanced settings: export and remove Cloud · Lovable
• Supabase integration · Lovable
• Secrets · Lovable
• Publish · Lovable
• Custom domain · Lovable
• Domain registration terms · Lovable
• External deployment and hosting · Lovable
• Deployment, hosting and ownership · Lovable
• FAQ: TanStack Start and React + Vite · Lovable
• Payments · Lovable