Export From Lovable, Bolt, Replit, v0 or Base44: What You Get

Lovable, Bolt, Replit, v0 and Base44 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, last checked on October 9, 2026.

Exporting from AI app builders: key facts

Question	Answer
Can you export code from Lovable, Bolt, Replit, v0 and Base44?	Yes. All five connect a project to a GitHub repository. Lovable, Bolt, Replit and Base44 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, though Lovable’s Git sync works on every plan. Base44’s zip download and GitHub sync both need its Builder plan or higher. 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. Base44: React, Vite, Tailwind CSS and shadcn/ui, connected to Base44’s own backend through the Base44 SDK.
Does exported Base44 code run without Base44?	Not as exported. The front end and the backend functions call Base44’s database, sign-in and functions through the Base44 SDK, so the app keeps depending on Base44 until a developer replaces those calls.
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 five 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, v0 and Base44 export compared

	Lovable	Bolt	Replit	v0	Base44
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	GitHub, two-way, Builder plan or higher; syncs the main branch
Zip download	Paid plans	Project title > Export > Download	Download as zip from the file tree menu	Not documented as a separate step	More actions > Export project as ZIP, Builder plan or higher
Import an existing repository	No; Lovable creates a new repository	Yes	Yes	Yes	Only for apps created with the Base44 CLI
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	React, Vite, Tailwind CSS, shadcn/ui; Base44 SDK for the backend
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	Base44’s managed NoSQL database
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	CSV per table; backup copies as CSV on Elite, Business and Enterprise plans
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	Secrets in the app dashboard, read by backend functions
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	Backend functions on the Deno runtime, run by Base44

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/ or drizzle/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.”

How to export from Base44, and what you get

Base44 is owned by Wix, which acquired it in June 2025 according to Wix’s annual report for 2025. Unlike Wix’s own AI site editor, Wix Harmony, which has no code to export, Base44 hands over its source code. That code is written to run on Base44’s backend, though, which matters more here than with the other four tools.

How export works. Both routes are in the app editor’s More actions menu (three dots), according to Base44’s developer tools page: Export project as ZIP for a one-time copy, and GitHub connection for ongoing sync. The GitHub guide describes two-way sync. Base44 creates a new repository and commits your changes to it automatically, and work merged into the repository’s main branch appears back in the app, where you click Publish to make it live. Some limits to know:

• Sync works only with a branch called main, so a repository whose default is master won’t sync.
• Only the app owner can connect the repository. Sync can’t be paused, and changes can’t be pushed by hand.
• After connecting, Version History can’t go back to versions from before the connection, because those versions aren’t in the repository.
• Linking an existing repository is documented only for apps created with the Base44 CLI. Apps that used the older one-way Export to GitHub option need to be reconnected with two-way sync.

Plans. The developer tools page says “Downloading a ZIP file and connecting to GitHub both require a Builder plan or higher.” Base44’s billing guide lists the plans as Free, Starter, Builder, Pro and Elite, then Business and Enterprise, so apps on the Free and Starter plans can’t be exported. Backend functions and connectors also need the Builder plan or higher, according to the integrations guide.

Stack. Base44’s app code introduction lists React with React Router, Vite, Tailwind CSS and shadcn/ui on the front end. The backend is Base44’s own: a managed NoSQL database, built-in sign-in, serverless functions on the Deno runtime, and realtime updates over WebSocket.

What the repository contains. The project structure page shows the pages and components in src/, data model definitions in entities/, and backend functions in functions/, with the @base44/sdk package listed in package.json. It also notes that once two-way GitHub sync is on, Base44 keeps the entity definitions itself, so the repository doesn’t hold them.

What the code depends on. Generated apps read and write data, sign users in and call functions through the Base44 SDK, which the SDK overview describes as the interface to Base44’s backend services. Backend functions use the same SDK. The developer tools page says the front end can be hosted somewhere else, but the data, sign-in and functions behind it stay on Base44. The Base44 pages checked here don’t describe running an exported app without Base44’s backend, so moving it off Base44 means replacing every SDK call with another database, sign-in system and function host.

Running it locally. The project structure page gives npm install then npm run dev. The GitHub guide’s local setup adds the Base44 CLI and base44 dev, which runs a local Base44 backend alongside the front end. With base44 dev --remote, the front end uses the live backend instead, and Base44 warns that “writes go to your live app’s production data.” A developer should test against the local backend or a separate app.

What stays in Base44:

• Data. Each table can be exported from Dashboard > Data as a CSV file, as described in managing your app data. On the Elite, Business and Enterprise plans, automatic backups also let you download a table as CSV from an earlier point. The CLI’s eject command copies an app into a new local project, but that copy is a new Base44 app, and “The ejected project has an empty database.” Base44 documents migrating projects into Base44 from Lovable and Bolt, but the pages checked here describe no way to move a whole database out.
• User accounts. Sign-in is built in, with email, Google and other providers. The pages checked here don’t describe exporting user accounts or their passwords, so a developer should plan how sign-in will be replaced before any users move.
• Secrets. API keys go in the dashboard’s Secrets settings, and backend functions read them from there.
• Uploaded files. Files that people upload through the app are stored by Base44. The pages checked here don’t describe a bulk download.
• Built-in integrations and connectors. Sending email, AI calls, image generation and file uploads run inside Base44 and use Base44 integration credits, according to the built-in integrations page. Each needs a replacement under your own accounts after a move.
• Function hosting and automations. The function code is in the repository, but Base44 runs it, along with any schedules or database triggers set up as automations.

What stays behind on the platform after an export?

Across all five 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, Base44’s built-in integrations, 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, environment variables the builder sets itself, and in a Base44 app, every call made through the Base44 SDK.
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. Base44 syncs only main, so outside work also goes on other branches until it is merged.
• 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.

If you’d like help moving an app, the process and pricing are published, and you can get in touch to talk through what you’ve built.