How to Migrate Off Lovable Into Production Infrastructure You Run

Lovable publishes its own portability table, and it is the most useful artefact in the whole migration. Two components move automatically through SQL migrations. Everything else is manual, and one item cannot move at all. | App component | Migration method | Lovable's own note | |---|---|---| | Database schema | Automatic via SQL migrations | Tables, columns, indexes, RLS policies, functions, triggers | | Storage buckets | Automatic via SQL migrations | Includes access policies | | Authentication providers | Manual | Reconfigure Google OAuth, GitHub and others in the new environment | | Environment variables and secrets | Manual | Reconfigure all API keys, tokens and credentials, for example Stripe | | Data (table contents) | Manual | CSV per table, or request a full database export | | Storage files | Manual | Download and upload by hand | | User accounts | Manual and partial | Passwords cannot be exported, so a password reset flow is required | Read that table as a scope of work rather than a warning. The automatic column is the part a competent engineer finishes in a morning: `supabase/migrations/*.sql` applied in timestamp order, then `supabase db push` and `supabase db diff` to confirm the target matches the source. The manual column is where the days go. Every OAuth provider has to be re-registered with new callback URLs. Every secret has to be re-entered, and ideally rotated rather than copied. Every storage file has to move, and every stored URL that points at the old bucket has to be rewritten.

Lovable's documentation states the constraint directly: "You can export user data from the database, but you cannot export user passwords, so you need to trigger a password reset flow. We recommend you plan the migration before onboarding real users." That is a vendor telling you, in its own docs, that the cheap window for migrating closes at your first real user. It is worth taking seriously, because the cost of moving does not rise smoothly with app complexity. It steps up sharply the moment there are real accounts with real passwords, real uploaded files with real URLs, and real scheduled jobs holding real state. A forced password reset is a churn event, not an inconvenience. Every user has to receive an email, trust it, open it and choose a new password. Some of those emails land in spam. Some users signed up months ago and will simply not bother. Some will assume the email is phishing, which is a reasonable assumption when an app they half remember suddenly asks them to reset credentials. If you are already past first users, plan the communication as carefully as the code. Warn people before the cutover, send the reset from a domain they recognise, keep the old environment readable for a fortnight, and expect to hand-hold a portion of your base through it. Base44 has a structurally similar problem for different reasons, covered in migrating off Base44.

Lovable's GitHub integration is a genuine two-way sync, and it has five documented limitations that catch people mid-migration. All five are stated in Lovable's own integration docs, not inferred. - The sync covers one branch at a time. If your team expects feature branches flowing back into Lovable, that is not how it works. - You cannot import an existing GitHub repository into Lovable. Export flows out only. A repo that has moved on independently cannot be brought back under the editor. - Reconnecting after disconnecting creates a new repository rather than reattaching to the old one. Any git history in the original repo has to be merged manually. - Renaming your GitHub username or organisation breaks the connection, and you cannot edit the project in Lovable until you revert the name. This one surprises teams who rebrand mid-build. - GitHub rejects files above 100 MB, and Lovable itself cannot save or edit files above 10 MB. Repositories Lovable creates are private by default on every plan. Commits are authored by `lovable-dev[bot]` with co-attribution to whoever triggered them, which is worth knowing before you try to read the history as if a person wrote it. The Lovable GitHub app also requests Administration write permission on the repository, which is a reasonable thing to review with whoever owns your organisation's security posture. The practical takeaway: treat the moment you disconnect as one-way. Get the repository into a state you are happy to own before you cut the link.

Database exports from Lovable Cloud are capped at 5 GB and limited to one export per 24 hours. Those two numbers control your migration schedule more than anything else on this page. A 24-hour cooldown means you cannot iterate. If the first export is incomplete, or you discover a table you missed, you wait a day before trying again. Plan the export as a deliberate step with a checklist, not something you fire off to see what comes back. If the database is near 5 GB, work out the per-table split before you start rather than after the first attempt fails. The trap that actually loses data is elsewhere. Lovable's docs warn: "Download your export and your storage files before removing Cloud from the project; exports saved to Cloud storage are no longer accessible afterwards." An export you generated but left sitting in Cloud storage disappears with the Cloud connection. Pull every artefact onto hardware you control, verify it opens, and only then touch the Cloud settings. There is also a documented boundary on where you can go. Lovable states that "migration to plain PostgreSQL or other database providers would require implementing equivalent authentication, storage, and edge services and is not supported out of the box." Lovable to a Supabase project you own is a supported path. Lovable to raw Postgres on your own servers means rebuilding auth, storage and edge functions yourself, which is a project rather than a migration.

Two specific technical details account for a disproportionate share of failed Lovable migrations. Both are fixable in an hour once you know about them and cost days when you do not. The first is build-time environment variables. Any variable prefixed with `VITE_` is embedded into the bundle at build time, not read at runtime. Teams used to twelve-factor configuration assume they can change an environment variable in their hosting dashboard and restart. Nothing happens, because the old value is already compiled into the JavaScript sitting on the CDN. Per-environment configuration means per-environment builds, and a staging build cannot be promoted to production by swapping variables. Decide early whether you rebuild per environment or move configuration to a runtime endpoint. The second only bites if your target is Next.js. Lovable generates code against `@supabase/supabase-js`, the browser client, which stores and refreshes sessions in the browser and knows nothing about server-side rendering. Next.js needs `@supabase/ssr` to persist a session across server components, route handlers and middleware. Copy the components across without changing this and you get an app that renders, lets a user log in, then loses the session on any server-rendered route. Several agencies selling this exact migration describe the same sequence: auth callbacks break first, import paths fail on the build server second, routing takes about twice as long as estimated third. If your target is plain Vite on your own hosting rather than Next.js, this second trap does not apply at all, which is a good reason not to change frameworks and infrastructure in the same move.

Assume the app has exposure until you have proven otherwise, because migrating a vulnerable app to new infrastructure just relocates the breach. The security firm Escape scanned 5,600 publicly available vibe-coded applications on 29 October 2025, roughly 4,000 of them built with Lovable, and found 2,038 highly critical vulnerabilities, more than 400 exposed secrets and 175 distinct instances of exposed personal information including bank account data. Escape's own caveat should travel with the number: they used deliberately passive scanning to stay within ethical bounds, so the findings "reflect only a subset of exploitable issues." It is a conservative floor, not a ceiling. The pattern behind most of it is row-level security. CVE-2025-48757, published in 2025, records missing or insufficient Postgres row-level security policies on Supabase databases behind Lovable projects, with 303 vulnerable endpoints found across 170 websites from examining homepages alone. Two things are worth stating honestly. The researcher who disclosed it, Matt Palmer, worked in developer relations at Replit, a Lovable competitor, and said so openly in his disclosure. Lovable disputes the CVE on the grounds that customers accept responsibility for protecting their own application data. That is a real disagreement about shared responsibility, and both positions are arguable. The general risk is not platform-specific. Veracode's 2025 GenAI Code Security Report, published on 30 July 2025, tested 80 curated coding tasks across more than 100 large language models and found that when a model could choose between a secure and an insecure implementation, it chose the insecure one 45% of the time. Java was worst at a 72% failure rate. So before the migration: enumerate every table's row-level security state, every secret sitting in a client-side bundle, and every remote procedure callable with the public anon key.

Run the migration in this order. Auth comes first because copying components feels like progress while nothing can actually be tested until login works. 1. Dependency review. List every Edge Function, every row-level security policy, every storage bucket policy and every OAuth provider the app uses. Each one is a thing you will reconfigure by hand. 2. Security audit. Fix the row-level security gaps in place before moving anything, so you are not carrying a known hole to a new address. 3. Auth in isolation. Stand up Supabase Auth in the target environment, re-register every OAuth provider with new callback URLs, and get login working against a test account before any other code moves. On Next.js this is where `@supabase/ssr` replaces the browser client. 4. Schema, then data. Apply `supabase/migrations/*.sql` in timestamp order, verify with `supabase db diff`, then move data separately, respecting the 5 GB export cap and the 24-hour cooldown. 5. Secrets, rotated not copied. Reissue every API key and OAuth credential rather than transplanting it. Anything that has lived in a generated codebase should be treated as compromised. 6. Storage files and URL rewriting. Move the files, then rewrite every stored URL pointing at the old bucket. This one fails silently and gradually as the old subscription lapses. 7. Environments and CI/CD. Set up automated deploys gated on tests and linting, remembering that `VITE_` variables need a build per environment. Prefer OIDC federation to your cloud provider over long-lived credentials in repository secrets, which is Lovable's own documented recommendation. 8. Monitoring before cutover. You are now doing what the platform did invisibly. Alerts, ownership and a rollback path need to exist before the switch, not after. 9. Verify with real accounts and real data. Test login, permissions, writes, uploads, functions and integrations against actual accounts. The characteristic failure of a bad migration is not a crash. It is an app that looks finished while one customer quietly sees another customer's data.

You will find confident timelines online for a Lovable to Next.js migration: three to five days for a solo developer with Next.js experience, two to three weeks without it. Treat those as advertising, not benchmarks. Every source publishing them sells the migration service being described. That does not make them useless. As a hypothesis they are plausible, and the shape of the estimate is more informative than the number: the same vendors consistently say most of the time goes on authentication rather than routing or components, which matches the technical reality of the browser client and server-side session problem. One vendor advertises a Lovable to Next.js migration audit at US$299 (about A$456 at July 2026 rates), which is a useful market signal for what an assessment-only engagement costs. What nobody has published is a measured figure. No independent source establishes a user count, request rate or data volume at which a Lovable app stops being viable, and every "it breaks at scale" claim traces back to an agency selling rescue work. Anyone quoting you a scale ceiling as though it were a known constant is repeating marketing. Our own view, stated as opinion: the variable that predicts migration effort best is not app size, it is how many real user accounts and stored files exist. A twenty-route app with no live users is a weekend. A six-route app with 800 registered users, uploaded documents and three scheduled jobs is a proper project with a communications plan attached. If you want the decision framed before the work, when to move off a vibe coding platform covers the trigger points.

Does Lovable let me take my code? Yes, and more openly than most. Lovable's documentation states "you own your code" and "Lovable is intentionally built so that you are never locked in." You get a standard Vite and React project through GitHub sync or a ZIP download on paid plans, and you can host it anywhere. The constraint is the backend, not the source code. Can I move a Lovable app to plain Postgres instead of Supabase? Not without rebuilding several services. Lovable's docs say migration to plain PostgreSQL or another database provider "would require implementing equivalent authentication, storage, and edge services and is not supported out of the box." Lovable to your own Supabase project is the supported path. Anything else means writing replacements for auth, storage and edge functions yourself. Will my users have to reset their passwords? Yes, if you are migrating user accounts. Lovable's documentation states that passwords cannot be exported and a password reset flow must be triggered. Plan it as a customer communications exercise: warn people first, send from a domain they recognise, and keep the old environment readable for a couple of weeks while stragglers come through. Why does my migrated app 404 on refresh? Because Lovable uses React Router's `BrowserRouter` for client-side routing and your new host has no rewrite rule. The server looks for a file at `/dashboard`, finds nothing, and returns 404. Add an SPA fallback that serves `index.html` for unmatched paths and the problem disappears. How big can my database export be? Lovable Cloud database exports are capped at 5 GB with one export permitted per 24 hours. Treat the export as a planned step rather than a trial run. Download it and your storage files onto hardware you control before removing Cloud from the project, because exports left in Cloud storage become inaccessible once Cloud is removed. Is it safer to migrate early or wait until we need to? Early, on the evidence. Lovable's own recommendation is to plan the migration before onboarding real users, because passwords, stored files and running automations are the components with no automatic path out. The work is not proportional to app size, it is proportional to accumulated real-world state.