What Breaks When You Export a Lovable App (And What Ports Cleanly)

What actually ports cleanly when I export a Lovable app?

Your frontend ports cleanly. The React/Vite source, components, routes, styling, package.json, and most client-side logic land in your GitHub repo exactly as written, and run on any host that builds a static or Node app. If your app were pure frontend with no backend, export would be nearly painless. The breakage is concentrated entirely in the backend layer Lovable provisions for you.

Lovable's GitHub export is real source code, not a black box — you own it and can read every file. The build config, TypeScript, Tailwind, and your component tree all transfer. What you are really exporting is the half of the app that lives in your repo. The other half lives in a Supabase project and Lovable's edge runtime, and that is where the What-Breaks-on-Export map matters.

The clean mental model: code ports, infrastructure does not. Anything that is a file in your project survives. Anything that is a row in a managed database, a policy attached to a table, a secret in an environment store, or a function deployed to an edge runtime needs to be recreated or re-pointed by hand.

Related: Export Lovable code to GitHub · Run your Lovable app locally

What is the complete map of what breaks when I export?

Here is the full What-Breaks-on-Export map. Frontend and code port cleanly. The backend layer — auth password hashes, RLS policies, storage objects, edge functions, secrets, and cron — does not travel with a GitHub export. Each row below is a distinct failure mode with its own fix. Treat this table as your migration checklist, not a summary.

The pattern is consistent: green rows are files, red rows are managed infrastructure. The single most dangerous assumption in a Lovable migration is that a successful GitHub export means a successful migration. It does not — it means you successfully moved the easy half.

Why do my users get logged out — what happens to auth and password hashes?

Auth does not live in your code, so export cannot carry it. Your users, their password hashes, sessions, and identities all sit in the auth.users table inside the Supabase project Lovable provisioned. If you point your exported frontend at a fresh, empty Supabase project, every account vanishes and every login fails — even though the login screen renders perfectly.

The critical rule: never rebuild auth from scratch during a migration. Password hashes are one-way — you cannot read them out and re-insert them into a new project through the normal API, and you must never reset everyone's password. The correct path is to migrate the existing Supabase project itself (claim it, or transfer the database) so the auth schema and hashes move intact.

If you truly must move to a different Supabase organization, the supported route is a database-level migration of the auth schema, not a re-signup flow. Anything that asks all your users to reset their password is a red flag that the migration was done the wrong way — and it is the most common reason a self-attempted export turns into a support fire.

Related: Move to your own Supabase the right way

Do my Row Level Security (RLS) policies come along when I export?

No. RLS policies attach to Postgres tables, not to any file in your repo, so a GitHub export leaves them behind entirely. The danger is silent: your exported app will connect and run, but if the new database has no RLS, every row is exposed through the public API — or, if RLS is on but policies are missing, every query returns empty and your app looks broken for the opposite reason.

This is the highest-stakes line on the What-Breaks-on-Export map. A missing RLS policy is not a crash — it is a data-leak waiting to be discovered, where one user can read another user's records because the table has no policy enforcing tenant isolation. Migrations that copy the schema but skip the policies are the classic way a Lovable app ships a security hole into production.

To carry RLS across, dump the policy definitions from the source database and re-apply them on the target before you let real traffic touch it. Verify by signing in as two different test users and confirming each sees only their own data. Do not treat 'the app loads' as proof — load is not isolation.

1. On the source Supabase project, open the SQL editor and select pg_get_expr and pg_policies to list every existing policy per table.
2. Save each CREATE POLICY statement, including the USING and WITH CHECK expressions, into a migration SQL file.
3. Confirm Row Level Security is ENABLED on every table in the target project (ALTER TABLE ... ENABLE ROW LEVEL SECURITY).
4. Apply the saved CREATE POLICY statements to the target database.
5. Test isolation with two separate user sessions and confirm neither can read the other's rows before going live.

Related: Lovable RLS and auth best practices · Supabase RLS permissions explained

What happens to my storage buckets, uploaded files, and edge functions?

Both disappear from an export. Uploaded files live as objects in Supabase Storage, and edge functions are deployed to a serverless runtime — neither is a file in your repo. After export, your image URLs return 404 and any feature backed by an edge function (payments, webhooks, AI calls, emails) silently does nothing, because the function it calls was never re-deployed to your new project.

Storage objects must be copied bucket-to-bucket. You re-create the bucket structure and policies on the target, then transfer the actual files using the Storage API or CLI — pointing your new app at an empty bucket leaves every avatar and upload broken even though the database rows referencing them are intact.

Edge functions must be re-deployed one by one. The function source may be visible in your repo under a supabase/functions folder, but being in the repo does not mean it is running — it has to be deployed to the new project's edge runtime, and its own secrets re-set. A function that exists as code but is not deployed is the classic cause of a feature that 'used to work' going quiet after migration.

Why do my environment variables and secrets vanish after migrating?

Because secrets are never in your code — by design. API keys, Supabase URLs, Stripe keys, and webhook signing secrets live in Lovable's and Supabase's secret stores, not in your repo (and should not be). When you deploy the exported app to a new host, every one of those values is blank until you re-enter it. This is The Vanishing Env-Var: the build succeeds, then the running app crashes on first use.

The symptom is a clean build followed by a runtime failure like 'supabaseUrl is required' or a third-party SDK throwing on an undefined key. The frontend ones (VITE_-prefixed) go on the host; the backend ones (service-role keys, Stripe secret keys, webhook secrets) go in the edge-function secret store and must never be exposed to the client.

Make a complete inventory before cutover. List every secret the app reads, where it is read (client vs. edge function), and re-enter each on the correct side of the new deployment. Missing exactly one of these is the single most common reason a migrated Lovable app appears broken on launch.

1. List every variable your app references — grep the repo for import.meta.env and process.env to find them all.
2. Sort each into client-side (safe, VITE_-prefixed) versus server/edge-only (service-role and signing secrets).
3. Add the client variables to your new host's environment settings.
4. Add the server/edge secrets to the edge-function secret store on the target project — never to the client bundle.
5. Redeploy and exercise every feature that calls an external service to confirm no key is still blank.

Related: How env vars vanish on deploy · Move secrets into edge functions safely

What about scheduled jobs, cron, and third-party webhooks?

These are the most easily forgotten. Scheduled jobs run via pg_cron inside the database scheduler — invisible in your code, so they do not export and simply stop. Webhooks from Stripe, Resend, or other services point at your old deployment URL, so after a domain change they fire into the void. Nothing errors loudly; the work just quietly stops happening.

Cron jobs must be re-created on the target database. Query the cron schema on the source to list every scheduled job, then re-define each one against the new project. Because there is no visible failure when they are missing, the only way to catch this is to inventory them deliberately before cutover.

Webhooks must be re-pointed at the new URL and, for signed webhooks like Stripe, the signing secret rotated and updated in the edge function. A webhook still aimed at the old domain will keep returning errors on the sender's side while your new app sees nothing — payments and emails silently fail until you update every callback URL in each provider's dashboard.

How do I migrate without breaking everything — and when should I hand it off?

Run the migration as a parallel cutover, not a switch-flip. Stand up the new database, storage, functions, secrets, RLS, and cron alongside the live app, verify each line of the What-Breaks-on-Export map on the new stack, then change DNS only once everything passes. The mistake that breaks migrations is treating a green GitHub export as 'done' and deploying with the backend half still missing.

If the app has real users, real data, or payment flows, the auth-hash and RLS lines are unforgiving — a wrong move there means locked-out users or leaked data, and both are far more expensive to fix than to prevent. That is the point where a managed migration pays for itself: we move the existing Supabase project intact, re-create policies, re-deploy functions, re-enter secrets, and verify isolation with test sessions before any DNS change.

We do this as a fixed-scope engagement with a rollback plan, and you keep full ownership of your code, data, and accounts throughout. If you have already exported and something is now broken, that is also fixable — bring the repo and the original project and we re-attach the missing backend half.

Related: Managed Lovable migration service · Plan your full move off Lovable