If I export my app from Lovable, Bolt or Replit, what do I actually get?

Every one of these platforms will tell you that you own your app, and every one of them is telling the truth. The sentence is just much narrower than it sounds when you read it while deciding where to build.

"You own your app" is nearly always a statement about the code. Ownership in the sense that matters — the sense where you could be running somewhere else next month — is four different things, and the code is the one that transfers most easily.

The four things people mean by "own"

The code. The files that make up your application. Easiest to get, most portable, and the least valuable of the four once an app is live.

The data. Your users, their records, your transaction history. Much harder, and the part that determines whether a move is a migration or a relaunch.

The runtime configuration. Environment variables, API keys, storage buckets, edge functions, auth settings, redirect URLs, webhook endpoints. Almost never in any export, on any platform, for reasons that are mostly good ones.

The legal rights. What their terms say about your code, your data and anything the AI generated. Frequently different from what the marketing page says, and free to check.

You can have the first and lack the second and third entirely, and that is the common situation. The general shape across all four platforms: the code is the easy part; the backend is where the lock-in lives.

Lovable

Code comes out cleanly. GitHub sync is available on every plan including the free one, which is the single most important portability fact about the platform, and a zip download is available on paid plans. What you get is a conventional project — historically React with Vite, and since May 2026 new apps are generated on TanStack Start with server-side rendering, so what your export looks like depends on when your app was created. The one Lovable-specific dependency in the build, their component tagger, is MIT-licensed, runs only at build time and can simply be removed.

The database is the interesting part, and it depends entirely on which backend you chose. If you connected your own Supabase project, you already own the data outright and there is nothing to export — that is the whole argument for doing it, and how to move to that position is worked through in moving from Lovable Cloud to your own Supabase. If you are on Lovable Cloud, which is enabled by default, the data lives in a Supabase project you have no dashboard for, no connection string to, and no service-role key for.

For Cloud, an official export shipped in July 2026 and it is a real improvement on the previous position. It gives you the full database including both structure and data. It does not give you the files in your storage buckets, the code of your edge functions, or any of your secrets. There is a 5 GB size limit and you can run it once every twenty-four hours. And the removal operation that accompanies it cannot be undone, which is worth reading twice before clicking.

Their terms are worth being precise about because both halves matter. You own your customer data and you own the AI output. At the same time, the terms grant them a broad, perpetual, worldwide licence over customer data that explicitly includes developing and training models — and there is a free opt-out available on every plan, including free. Both of those things are true simultaneously. The practical implication is not outrage, it is a settings page: if you have not opted out, you have not opted out.

There is also a documented tension worth knowing about. Their ownership page is unusually direct that you are never locked in and that your database, storage and configuration are portable. Storage bucket files and edge function code are not in the export, and secrets by design cannot be. Both statements come from the same company. I do not read that as dishonesty — I read it as the ordinary gap between an intent and an implementation, and it is exactly the gap you should plan around rather than argue with.

Bolt

Code comes out easily: a zip download, and a GitHub integration that commits automatically as you work, which is the better of the two because it means a copy exists continuously rather than at the moment you remember to take one.

The legal position here is the cleanest of the four, and it is the one people know least about. Bolt runs on StackBlitz, and StackBlitz's terms of service state that they claim no ownership rights in your content — and, notably, contain no AI training clauses at all. Bolt's own support material is equally direct that the code is yours. If the training question is the one you care about, that is a meaningful difference from the alternatives.

The database is the gap. Bolt's bundled database is Postgres, and to own it you have to "claim" it into a Supabase account of your own — a step that exists precisely because until you take it, it is not in an account you control. The documentation covers claiming and does not really address exporting the data any other way, and moving in the opposite direction, from your own Supabase into their managed one, is not supported.

So: excellent code portability, unusually clean terms, and the same backend gravity as everyone else. Claim the database early.

Replit

A zip download is available from the three-dot menu, and because it is a full Linux environment you can also simply archive the project from a shell inside it.

Replit's own documentation is admirably clear about what the copy does not include, and the list is the important part: secrets, the database, and deployment configuration are all excluded. Everything that makes the app run in production is outside the thing you downloaded.

The database deserves its own paragraph. Replit's current managed database — introduced for new projects at the end of 2025 — is documented as being reachable only from within your app and never publicly exposed, which is a sound security decision and also means there is no documented path to connect an external tool and pull the data out. If you are on it and you want your data elsewhere, plan on writing an export endpoint inside your own application, because that is the access route that exists.

Authentication is the other one to check before you get attached. Replit Auth signs people in with their Replit accounts, so those identities are not portable to an app running anywhere else. If your users authenticated that way, a move is a re-registration for every one of them.

The exported code also carries the most platform scaffolding of the four. Expect to remove the platform config files, the editor-specific Vite plugins, the hosted-database client library and a server binding option that only makes sense inside their environment. None of it is hard; all of it is an afternoon nobody schedules.

On rights, their terms say you retain your rights in what you submit, alongside a broad licence back to them that includes sublicensing. What their terms notably do not contain — unlike Lovable's and Cursor's — is any clause assigning the output of the AI to you. That is an absence rather than a claim, and absences in contracts are worth noticing.

Cursor

Cursor is a different animal and belongs on this list mainly to correct a misconception. It is an editor. The code was always on your machine and always in your own repository, so there is nothing to export, because there was never an import. On the ownership question it is the strongest of the four: their terms explicitly assign to you whatever rights they might have in the AI's suggestions, and state that they do not train on your code unless you agree to it.

The nuance is that "local editor" does not mean "nothing leaves". Their own data-use documentation is clear that requests pass through their backend, that files are temporarily cached to serve those requests, and that your codebase is uploaded in chunks to build the embeddings that make search work. That is a normal architecture for this kind of tool, and it is a different privacy question from an ownership one. If you work under a client agreement with data-handling terms, that is the paragraph to read.

Cursor has no lock-in in the sense this article is about. Whatever else it has, it does not have your database.

The thing that is true on all four

Every export mechanism above is a feature of an account that is working.

There are three reports on r/lovable from mid-2026 of accounts being blocked with the export route unavailable at the same moment. I cannot verify the circumstances of any of them, and I am not suggesting anybody was treated unfairly — the point does not require that. The point is structural, and it applies to every platform on this page equally: the button that gets your app out is on the other side of the login that stopped working.

That is not a conspiracy, it is just how accounts work. It is also the entire argument for taking the copy while everything is fine, which costs you one afternoon and zero dollars.

What to actually do about it

Four things, in increasing order of effort and decreasing order of urgency.

Turn on continuous code sync today. GitHub integration on the platform you use, pointed at a repository in an account you control. This takes ten minutes and it changes the code question permanently — from "can I get it out" to "it is already out". Do this one even if you read nothing else.

Write down what is not in the export. Every secret and API key by name — not their values, which you cannot read anyway and should not want to — every storage bucket, every edge function, every webhook endpoint and redirect URL. One page. This document is the actual difference between a two-day migration and a two-week one, and you can write it in twenty minutes while looking at your own dashboards.

Take a data export now and check that it opens. Not because you are leaving, but because an export you have never opened is a hope rather than a backup. The same logic as a database restore you have never performed.

Decide about the backend deliberately. The single highest-leverage decision is bringing your own database, auth and storage from the beginning, because it reduces the platform to a code editor with a deploy button — and replacing a code editor is a weekend. If you did not do that, moving to it later is a real project, but it is a bounded one, and it is the piece that makes every future decision cheaper.

And the one to plan for specifically: assume your users will need to reset their passwords. Build the flow and write the email before you migrate, not during. It is a much better experience announced in advance than discovered by a customer who cannot log in.

Where this fits

None of the above is an argument against these platforms, and I want to be clear about that because articles on this subject usually end up there. They compress the first eighty per cent of a product from months to days, which is a genuinely enormous thing, and the trade you make for that speed is reasonable.

The problem is only that the trade is usually made without being noticed. Portability is not paranoia and it is not a statement about anyone's trustworthiness — it is the version of platform risk that is actually in your hands, and it is cheap while things are going well and expensive at any other time.

If you want the fuller picture of how the four platforms differ once an app is live and taking money, that is in Lovable vs Bolt vs Replit vs Cursor in production, and the tenth item in the ten problems every AI-built app has in production is this subject at a smaller scale.

If you want someone to do the inventory with you

The list in the previous section is genuinely doable alone, and most people do not do it because it is dull and never urgent until it is.

I do a Production-Ready Audit that includes a portability review: where your code actually lives, what your export would and would not contain, which credentials exist and where, and what a move would take in days — written down, so it is a decision you can make rather than a question you keep postponing. From $499, back in five to seven days.

If you just want a quick read, tell me which platform you are on and whether you used its bundled backend, and I will tell you what your export would leave behind. No charge — it is a two-minute answer and finding out during a bad week is a much worse way to learn it.

More on the repair and migration work is on the AI SaaS rescue page.