Exporting From Lovable, Bolt, Replit or v0: What You Get

Lovable, Bolt, Replit and v0 all let you take your code out. What the export leaves behind is less obvious. A Git repository or a zip file holds the source code, but the running app also depends on a database, user accounts, uploaded files, server functions and secret keys. Those stay on the platform until someone moves them.

This guide covers each tool in turn: how its export works, which plans include it, what stack the code uses, what stays on the platform, and what a developer needs to run the app somewhere else. It expands the export section of You Built It With AI. Here’s How a Developer Takes It Over, which covers the whole handoff.

These tools change often. Every tool fact below comes from that tool’s official documentation, checked on October 4, 2026.

Exporting from AI app builders: key facts

Question	Answer
Can you export code from Lovable, Bolt, Replit and v0?	Yes. All four connect a project to a GitHub repository. Lovable, Bolt and Replit also document a zip download. v0’s FAQ says the code can be exported for local work, and GitHub sync is the method its docs describe in detail.
Do you need a paid plan to export?	For Lovable’s zip download, yes. Lovable’s Git sync works on every plan. The Bolt, Replit and v0 pages checked here don’t limit export to particular plans, though a Replit workspace admin can block code downloads.
Does the export include the database?	No. You get the code, and in some tools the migration files that define the database structure, but not the records in it. Each tool has its own way to export data.
What about user accounts, uploaded files and secrets?	They stay on the platform until you move them. Secret values are meant to live in each platform’s settings rather than in the code.
What stack does the code use?	Lovable: TanStack Start for apps created from May 13, 2026, React and Vite before that. Bolt: JavaScript, with Node.js for the backend. Replit: whichever language and framework the project uses. v0: Next.js, React, TypeScript, Tailwind CSS and shadcn/ui.
Who owns the exported code?	Lovable’s ownership guide says “Your apps, code, and content you create with Lovable are yours, subject to third-party rights such as open-source licenses.” v0’s FAQ says Vercel doesn’t own code generated from your prompts. Check your own tool’s terms.
Can you keep using the builder after exporting?	Yes, if you use Git sync. All four can pull changes made in the repository back into the builder, so you and a developer can work on the same project.

Git sync or zip download: which should you use?

There are two ways to get code out of these builders, and they suit different jobs.

• Git sync connects the project to a repository and keeps the two updated. Changes are recorded as commits with dates and descriptions, the builder can keep working on the project, and a developer can work on the same code from their own editor. This is the route for a handoff.
• A zip download is a one-time copy of the project’s files. Nothing links it back to the builder, and later changes on either side stay where they were made. It is useful as a backup or for a quick look at the code. Replit’s project copy guide also points out that a zip carries the project’s commit history only if it includes the hidden .git folder.

Whichever you choose, create the repository under an account you control, such as your own GitHub account or your company’s organization.

Lovable, Bolt, Replit and v0 export compared

	Lovable	Bolt	Replit	v0
Git sync	GitHub, GitLab or Bitbucket, two-way, all plans	GitHub, two-way; new repositories start private on main	GitHub through the Git pane; turn on auto-sync for two-way	GitHub, with a working branch and pull request per chat; new repositories are private
Zip download	Paid plans	Project title > Export > Download	Download as zip from the file tree menu	Not documented as a separate step
Import an existing repository	No; Lovable creates a new repository	Yes	Yes	Yes
Stack	TanStack Start (from May 13, 2026); React and Vite before	JavaScript; Node.js backend; Expo for mobile	Depends on the project	Next.js, React, TypeScript, Tailwind CSS, shadcn/ui
Built-in database	Lovable Cloud, which uses Supabase-compatible services	Bolt Database, or Supabase on Pro and Teams plans	PostgreSQL, with separate development and production databases	Marketplace integrations: Neon, Supabase, Upstash, Vercel Blob
Getting the data out	CSV per table, or a full database export (one every 24 hours)	Selected rows as CSV or JSON, or claim the database in Supabase (Pro or Teams)	pg_dump with the database’s connection string	Held in your account with the provider
Secrets	Stored in Lovable, kept out of the repository	Secrets settings, read by server functions	Secrets tool; published apps use a separate set	Environment variables on the linked Vercel project
Server code	Edge Functions in supabase/functions/; TanStack Start server functions	Bolt Cloud server functions	Runs inside the project	Next.js server actions and API routes

The sections below explain each tool’s row in more detail.

How to export from Lovable, and what you get

How export works. Git sync links a project to a new GitHub, GitLab or Bitbucket repository, and you set it up under Project settings > Git. The zip download, called Download codebase, is on the same settings page and at the bottom of the code editor’s file tree. Edits in Lovable become commits, and, in Lovable’s words, “commits pushed to the synced branch appear back in your Lovable project.” Connecting always creates a new repository, because Lovable can’t import an existing one. Lovable follows one branch at a time and warns against force-pushing, rebasing or squashing commits already on that branch, because rewriting its history can lose edits made only in Lovable.

Plans. Lovable’s ownership guide says Git sync “is available on all plans” and that the .zip download “requires a paid plan.”

Stack. “New apps created from May 13, 2026 use TanStack Start, which runs server code. Older apps use React + Vite and build to static files.” The difference matters for hosting. An older app can go on any static host, while TanStack Start apps need hosting that runs their server code. To tell which one you have, Lovable’s hosting guide says to look for the @tanstack/react-start package in the dependencies listed in package.json.

What the repository contains. The application code and configuration. Projects on Lovable’s built-in backend (Lovable Cloud) also get their Edge Functions in supabase/functions/ and their database migration files in supabase/migrations/. The same hosting guide is clear about the limit: “Neither includes the records in your database or the files in storage.”

What stays in Lovable:

• Data. Tables can be exported one at a time as CSV, or the whole database can be exported, which Lovable allows once every 24 hours.
• User accounts. They come with the database export, including password hashes, which means existing passwords still work after a restore into Supabase. Sign-in providers must be set up again, and signed-in users have to sign in again.
• Secrets. Secret values saved in Lovable are never written to the repository. Server code that needs them must have the values set wherever it runs.
• Lovable AI and app connectors. Lovable manages the credentials behind them, and they “cannot be copied out.” In a TanStack Start app these calls fail when the app runs on your own machine, and after a full move they need replacing with your own accounts.
• Uploaded files, which are downloaded and uploaded again by hand.

Where the backend can go. The supported destinations for the built-in backend are managed or self-hosted Supabase. Lovable warns that “Moving the PostgreSQL database alone does not move authentication, storage, realtime, or Edge Functions.”

Running it locally. In a Lovable Cloud project, a clone’s .env file points at the live backend. Lovable’s Git sync page warns that a local app using that configuration “reads and writes the same backend as your published app, so records you create or delete locally change real data.” A developer should test against a separate database.

How to export from Bolt, and what you get

How export works. Bolt’s project guide describes the download: click the project title, then Export > Download, unzip the file, and run npm install && npm run dev with Node.js installed. Its GitHub integration creates a private repository on the main branch, commits automatically whenever a change leaves the project working, and looks for changes on GitHub every 30 seconds. Unlike Lovable, Bolt can also import an existing repository. Two details to know: Bolt doesn’t merge branches itself, so merges happen on GitHub, and if Bolt and GitHub change at almost the same moment, “Bolt keeps your changes and overwrites the GitHub version.”

Plans. The download and GitHub pages don’t mention a plan requirement.

Stack. According to Bolt’s supported technologies page, “Bolt focuses on JavaScript-based web technologies,” with Node.js for the backend and any JavaScript framework that runs in the browser. PHP and Python backends, for example, aren’t supported. Mobile apps are built with Expo.

What stays in Bolt. Bolt projects can run entirely on Bolt Cloud, which bundles hosting, domains, a database, sign-in, file storage and server functions, and which Bolt says is powered by platforms including Netlify and Supabase. A downloaded project contains the code but not those services.

• Data. Bolt’s table settings let you select rows and export them as CSV or JSON. To move the whole database, Bolt’s Supabase guide describes claiming it, which turns the Bolt Database into a Supabase project. You need a Pro or Teams plan to claim it, plus owner permissions in the Supabase organization. Bolt’s database page adds that restoring an earlier project version doesn’t restore the database, and that in unpublished projects Bolt may pause a database after six days of low use.
• Secrets. API keys go in the Secrets settings, where server functions read them, and Bolt’s own advice is never to keep secrets as plain text in the code.
• Sign-in, file storage and server functions run on Bolt Cloud and need equivalents wherever the app moves.

If the project uses your own Supabase project instead of Bolt Database, the data, users and functions are already in an account you control.

How to export from Replit, and what you get

How export works. Replit’s projects and files FAQ covers both routes: open the menu (three dots) above the file tree and choose Download as zip, or connect a repository in the Git tool and turn on auto-sync for two-way syncing. Replit’s project copy guide adds that GitHub only receives what you commit and push, so uncommitted changes and files matched by .gitignore stay in Replit.

Plans. The FAQ doesn’t tie either route to a plan. The copy guide notes that a workspace admin can turn on a setting that bans source code export, which blocks the zip download.

Stack. Replit isn’t limited to JavaScript. The same FAQ shows a secret read from Node.js and from Python, so the code you get depends on what was built.

What stays in Replit. The copy guide’s list of what doesn’t come with the code is a useful checklist even if you are leaving Replit entirely:

• Data. Every Replit app has a development database and, once published, a separate production database that holds the live data. Both are PostgreSQL, and current development databases run PostgreSQL 16. The guide exports data with pg_dump, and notes that the default DATABASE_URL exports the development database, so the production one needs its own connection string from the Database tool.
• Secrets. “Secret values never leave the old project.” The secrets documentation explains that secrets used while developing and secrets for the published app are set separately. Replit also sets its own variables, such as REPLIT_DOMAINS and REPLIT_DEPLOYMENT, that won’t exist on another host.
• Sign-in. Replit Auth signs users in with Replit accounts, and Replit says “The only way to implement Replit Auth is by using Agent.” The alternative, Replit’s managed Clerk Auth, runs on a Clerk tenant that “is not exposed through the Clerk dashboard.” The Replit pages checked here don’t describe taking either option’s users to another host, so a developer should plan how sign-in will be replaced before any users move.
• Uploaded files. App Storage runs on Google Cloud Storage, and a bucket is tied to a single project. The docs say to “Use the official Replit App Storage client libraries to automatically authenticate,” so code that reads or writes files may need changing on another host.
• Connectors and the published app. Integrations are reconnected, and the app is published again wherever it goes.

One caution before sharing a zip: the copy guide says the hidden .cache folder stores Replit’s internal state, “including cached secret values,” and should be left out of zip files you create by hand. Check any zip for that folder before you send it to anyone.

How to export from v0, and what you get

How export works. v0’s GitHub guide says “GitHub sync moves code between v0 and GitHub.” Connect from the Project menu (…) > Settings > GitHub, which sets up a private repository containing the project’s current code. Each chat then works on its own branch, and publishing merges that branch through a pull request, following any branch protection rules the repository has. After connecting, the repository “becomes the source of truth for your project’s code,” and v0 warns that deleting it may leave the code unrecoverable. The FAQ says you can “Export the code to work locally or edit directly in v0,” but the pages checked here don’t describe a separate download step, so GitHub sync is the route to plan around.

Plans. v0’s plan comparison doesn’t list GitHub sync or export as a paid feature.

Stack. “v0 uses Next.js, React, TypeScript, Tailwind CSS, and shadcn/ui.” Its full-stack guide adds that v0 defaults to Next.js and can use other frameworks, though Next.js gives the most reliable results.

What stays behind. The v0 docs checked here describe databases and file storage as outside integrations rather than a v0 service, so more of the app already sits in separate accounts:

• Data and file storage. v0 adds databases through the Vercel Marketplace, with integrations for Upstash, Neon, Supabase and Vercel Blob. Adding one “provisions a new user account on that service,” so the data sits with that provider rather than inside v0.
• Environment variables. These live on the linked Vercel project. v0’s Vercel integration page explains that v0 inherits them from there, and connecting an integration adds its variables to that project. A developer hosting elsewhere needs the same values set on the new host.
• Hosting. Publishing deploys to Vercel. The FAQ notes that connecting the repository to a Vercel project gives “the full experience,” and that “You can still export code and deploy elsewhere.”

What stays behind on the platform after an export?

Across all four tools, the same things stay behind unless someone moves them:

1. The data. The records in the database, exported separately from the code. Some exports include the database structure as migration files, but none of the code exports include the records.
2. User accounts and sign-in settings. Password hashes may come with a database export, but sign-in providers, allowed redirect URLs and email settings are set up again at the destination.
3. Uploaded files. Images, documents and other files in storage buckets, downloaded and uploaded separately.
4. Secret values. API keys, payment keys and database passwords. A list of their names belongs in the handoff notes; the values are shared through a password manager, never in chat or email.
5. Server functions and scheduled jobs. The code may be in the repository, but deploying it and recreating schedules is a separate step.
6. Services the platform runs for you. Lovable AI and app connectors, Replit Auth and connectors, and anything else that runs through the builder’s own accounts need a replacement under your own accounts.
7. The domain and hosting. The live site stays on the builder’s hosting until you move the domain.

Secrets need particular care in an export. Keys that look harmless in a builder can end up in a repository or in code sent to the browser. AI-Built App Security Checklist: What a Developer Checks First covers how a developer finds exposed keys and what to do when one has been committed.

What does a developer need to run an exported app elsewhere?

With the code in a repository, a developer works through a short list before the app runs anywhere else:

1. Access to the repository under your account, with the developer invited as a collaborator.
2. The stack and its install steps. The package.json file (or the equivalent for another language) shows the framework, the dependencies and the start commands. Lovable’s hosting guide notes that some projects only include a bun.lock file, so the install tool should match the lockfile.
3. The names of every environment variable the app reads, and where each value comes from.
4. A test database. A copy of the data, or a separate empty database, so local testing doesn’t change live records.
5. The data export and migration files, applied to the new database in the order they were created.
6. Sign-in configuration, including the local and new production URLs added to the provider’s list of allowed redirects.
7. Replacements for platform-only services, such as builder-managed AI calls, connectors, storage client libraries and environment variables the builder sets itself.
8. A host that matches the stack. Static hosting works for an older Lovable app built with Vite. Apps that run server code, including TanStack Start and Next.js apps, need a host that runs it.

A developer should also check the dependencies. AI models tend to write code for older library versions, a pattern covered in AI Code Generation Has a Version Problem.

The handoff guide’s preparation list covers what to gather before the first call with a developer.

Can you keep building in the tool after exporting?

Yes, as long as you use Git sync rather than a one-time download. Exporting doesn’t remove the project from any of these builders. Lovable’s FAQ confirms that “Your project remains fully editable in Lovable” after connecting.

Two-way sync means two places where code can change, so agree on a working pattern:

• Use separate branches. Lovable suggests keeping Lovable on the synced branch, usually main, and doing outside work on feature branches that are merged in after review. v0 creates a branch for each chat and merges through pull requests.
• Don’t rewrite shared history. Lovable warns that force-pushing or rebasing the synced branch can lose edits made only in Lovable.
• Expect the builder to change your code. Lovable says it handles code you wrote just like code it generated, so a later prompt can change either. Tests and written project instructions protect what matters.
• Decide who changes what. An owner can keep prompting for copy and layout changes while a developer handles data, security and integrations.

If the AI-written code is a plugin for a WordPress site or an app for a Shopify store rather than a standalone app, the platform’s own extension rules apply instead. Using AI to Build WordPress Plugins and Shopify Apps Safely covers that case.

When to bring in a developer

Exporting the code takes a few clicks in any of these tools. Moving the data, sign-in and secrets without losing users or exposing keys is the part that benefits from a developer, especially once real customers, personal data or payments are involved.

Connor on the Web takes over apps started with AI builders, from the first repository review to hosting them on infrastructure you own. The process and pricing are published, and you can get in touch to talk through what you’ve built.