Get your code out of the builder.

You can get a copy of your code out of Lovable, Replit, Bolt and Base44. Put it in GitHub or save it as a ZIP. The code is only one part of your app: the database, the logins, the stored files and the keys stay behind until you move them, so this guide ends with a list of what is still in the builder's hands.

You get a copy of the files that make your app's screens and logic. You do not get the whole app.

Three words come up in every export, so here they are in one line each. GitHub is a website where developers keep and share code. A repository is one project's folder on GitHub, with its full history of changes. A ZIP is one file that packs many files together, which you download and keep.

Think of your app as three separate things. The code is a copy you can hold in GitHub or in a ZIP. The data is a different thing: database records, users and stored files. The accounts are a third: the login service, the keys and the hosting. The data and the accounts stay with the builder until you move them. A ZIP or a GitHub link does not mean the app has left the builder.

This guide comes out of our study of 157 community posts and 34 jobs from founders moving off a builder. That count is our study's, not search volume, and not every founder.

Here is what each builder gives you.

Checked 22 October 2026 in each builder's own documentation. Plans and labels change; check before you rely on them.

Bubble does not work the same way. For Bubble, see Can you export Bubble code?.

Which builder to be on in the first place is a different question. The comparisons each have a "can you leave" section: Replit vs Lovable, Lovable vs Bolt and Lovable vs Base44 vs v0.

Connect the project to your own GitHub account. Lovable then syncs the code both ways. GitHub sync is on all plans; a direct download of the code is on paid plans.

What to do, in order. Each point is from Lovable's GitHub integration page, checked 22 October 2026:

1. Decide which GitHub account or organisation should hold the code. Use one you control. If you do not have a GitHub account, create one first.
2. In your Lovable project, open the GitHub connection and sign in to that account. Lovable's page shows the exact screens.
3. Let Lovable create the repository. It always creates a new repository; it cannot link one you already have. Open it on GitHub and check that your project's files are there.
4. Do not disconnect and reconnect to "fix" something. Reconnecting creates another repository.

Older advice says that renaming the repository always breaks sync. Do not rely on that. The current documentation describes the renames and owner transfers it supports, with conditions, so check the page before you change anything.

Founders hit the same snags.

In November 2025 a project owner on the Vercel Community asked how to import a Lovable project's connected repository, and whether to disconnect or create another one (Sean, Vercel Community, 28 Nov 2025).

It is an example that the question exists, not a measure of how common it is. The role is self-reported.

Sync does not move your app. The code is now in your GitHub. The database, stored files and secrets are still in Lovable: the data is covered in how do I get my data out too. To run the app somewhere else, see Lovable to Vercel.

Download the project as a ZIP from the file-tree menu, or connect a GitHub repository through Replit's Git tool, which syncs both ways.

The same steps answer how to download your files from Replit or move a Replit project to GitHub. Checked 22 October 2026 in Replit's projects and files page: this is access to your project files. It is not a bundle that moves the whole service.

A ZIP gives you the files as they are today. A repository gives you the files plus the history of changes. If you only want a safe copy, a ZIP is enough. If you plan to keep working on the code, a repository is better.

Now the part founders trip on. Your database, your stored files and your login are separate resources in Replit. Replit's docs treat database records and App Storage files as separate things, and a login as either a Replit-account login or its own Clerk tenant. A Clerk tenant is a separate login service attached to your app. Find out which one your app uses before you describe a move. Secrets for development and for the published app are also set up separately.

The database address in your development version may not work from outside Replit. Replit's connection details page separates the development credentials, which are scoped to the app, from production access through a PostgreSQL-compatible client. Do not assume you can copy the address and carry on.

In January 2026 a Replit user finished an app, wanted every file on a server they owned, and asked whether changing the database means changing the code (NewEra_Jack, r/replit, 12 Jan 2026). It is the right question. It shows the difference between downloading files and moving what the files depend on. The role is self-reported and unverified.

The data steps are in the data section below.

Open the project title and choose Download. That saves a ZIP.

The Export menu is a different thing. It opens the project in StackBlitz, an online code editor. Bolt's documentation also says that option is not available for projects moved to its newer code-storage format. Checked 22 October 2026 in Bolt's "Manage your projects" page.

Bolt can also sync to an external GitHub repository, with automatic commits. Checked 22 October 2026 in Bolt's GitHub version control page:

1. Only the project owner can connect and manage the link.
2. Disconnecting a project removes the connection permanently. You cannot reconnect it by hand. The docs send you to Bolt support if you need the same repository back.

So do not disconnect to "move". It cannot be undone.

Neither route moves every cloud resource. Your database, logins and secrets are backend resources, set apart from the code, and the live app is published by Bolt or another host. A ZIP or a Git link does not carry them. Check each one at the new place before you rely on it.

Use a ZIP export or a GitHub connection. Both need the Builder plan or higher, and the exported code still depends on Base44.

Checked 22 October 2026 in Base44's developer tools page:

1. A ZIP export needs edit access and a computer.
2. It includes the current front-end code (React and Vite), the backend functions, and the table structure and permissions.
3. It leaves out table records, secrets, app users and version history.
4. GitHub supports two-way work on your own computer, and also needs the Builder plan or higher.

Here is the catch. The exported code still uses Base44's hosted backend. The database, the login and the integrations cannot be self-hosted. If you run the front end somewhere else, that dependency comes with it. To leave Base44 fully, you have to replace the backend as well.

After you export, list every part of the app and write down whose account it is in.

Use this checklist. Copy it into a document. For each line, write three things: whose name it is in, who else has access, and whether you can get it out.

• The builder account. The Lovable, Replit, Bolt or Base44 login that holds the project.
• The code. Your GitHub repository or the ZIP you saved. Is the GitHub account yours, or someone else's?
• The database. Where the records live, and which account pays for it.
• Stored files. Images, documents and uploads, and where they sit.
• The login service. Who signs in to your app, and which service holds those users.
• Keys and secrets. A key is a private password your app uses to talk to another service. List each one by name and purpose, never by value.
• The domain. Whose account the web address is registered in.
• The hosting. Where the live app runs, and whose account it is in.
• App-store accounts, if the app is in one.
• Email and payment services. Who owns each account.

The checklist will have gaps. That is normal. A gap tells you what to ask or fix before you move anything.

This is a list, not a legal view on who owns what. If your question is whether to keep this app, fix it or rebuild it, read Should I keep, fix or rebuild my app?.

A downloaded copy often fails for a short list of reasons, and none of them means the export was bad. Check these, in any order:

• The wrong runtime or missing packages. The code needs a particular version of its programming tools and a set of add-on packages installed first.
• The app's start-up settings. The commands that start the app may differ from how the builder ran it.
• The environment variables. These are the settings an app reads when it starts. They include the keys, and they were not in the export.
• A connection to the builder's own database or login. The code may still point at the builder.
• A hosted function or integration the code still calls. It may only work from inside the builder.

To find your environment variables without exposing them, ask an AI helper that can see your project files. Copy this prompt. It asks for names, file paths and purposes. It never needs a secret value.

Scan the files in this project. List every key, secret and setting the app
reads when it starts (environment variables, config files, anything read
from the settings of the builder).

For each one give: the name | the file path where it is read | what it is
for | which service it belongs to (database, login, payments, email, AI,
other) | whether it lives in the builder's settings and not in the code.

IMPORTANT: Do not print, guess or ask me for any value. Show names only.
If you find a real key or password written in a file, say that it exists
and which file it is in, without repeating it.

Do not paste any secret value into the helper, a repository or a chat. If the helper asks for one, stop.

Then run a first test on your own computer. Open the copy there. Expect it to fail the first time. Use the list from the last section to see why: which names are missing, and which services the code still points at. A ZIP that downloads is not a working, independent app.

When you are ready to run it on a host, see Lovable to Vercel.

If you want a person to look at your app before you move anything, ask for the free Build Audit.

A person on our team records a walkthrough of your app and sends you a one-page note: what stays, what needs fixing, and what blocks launch. It is free.

It does not move your app. It is not a legal opinion on who owns what. It is a clear look at where your app stands, so you know the next step before you spend anything.