How to export your code from Base44, and what the export leaves out

The short version

Base44 offers four official ways to take things out of an app:

• Download the project as a ZIP from the Code tab. You get the frontend project, including your function files and table definitions.
• Two-way GitHub sync. The same code, kept in a repository you choose and updated automatically.
• The Base44 CLI, including base44 eject, which copies an app into a new, separate Base44 project with an empty database.
• CSV export, one table at a time, from the Data dashboard.

The first two need the Builder plan or higher. All four are useful, and none of them produces an app that runs without Base44. The code they give you is a client for Base44’s servers: sign-ins, records, functions, emails and AI calls all still go to Base44. The rest of this article explains each option in detail, then what it takes to get the parts the exports leave behind.

Option 1: download the project as a ZIP

Open your app, go to Code, and click the Export project as ZIP icon at the top right of the code view. Base44’s developer tools page notes that both the ZIP download and the GitHub connection require a Builder plan or higher.

The archive is a standard React app built with Vite. According to Base44’s project structure docs it contains:

• src/pages, one file per route (Home.jsx becomes /, Settings.jsx becomes /settings)
• src/components, including a ui/ folder of pre-built components
• src/api, the Base44 SDK client configuration
• src/hooks, src/lib and src/utils
• entities/, one JSON schema file per table
• functions/, one TypeScript file per backend function
• package.json (which includes @base44/sdk), vite.config.js with the Base44 Vite plugin, a Tailwind config and index.html

You can run it with npm install and npm run dev. What you will see is your app’s interface, talking to Base44’s backend. The data it shows is your live data, served by Base44.

When the ZIP is the right tool: a backup of your code, a handover to a developer who wants to read it, or a snapshot before a risky round of AI edits.

Option 2: two-way GitHub sync

Connecting GitHub keeps your app’s code in a repository and syncs changes both ways. Base44’s GitHub integration docs set out the rules, and a few of them matter if you’re thinking of this as an exit:

• It needs the Builder plan or higher, and only an app owner can make the first connection.
• Changes in Base44 are pushed to the repository automatically; there is no manual push.
• Changes you make locally reach Base44 when you merge them into a branch named main. You still click Publish in Base44 to make them live.
• Entities are managed in Base44 and aren’t in the repository, so your table definitions aren’t part of what syncs.
• After you disconnect, you can’t reconnect the same repository. And once connected, Version History can’t restore versions from before the connection.

GitHub sync is a good way to let Claude Code, Cursor or a developer work on the code without leaving Base44. It gives you a durable copy of your code. It doesn’t move where the app runs.

Option 3: the Base44 CLI and base44 eject

The Base44 CLI (npm install -g base44@latest) has two commands people reach for when they want out.

base44 eject copies an existing Base44 app into a separate local project, as the eject reference describes it. It downloads the frontend code, entity schemas and other backend resources, and creates a new backend project with its own app ID. The new project starts with an empty database: schemas are copied, data isn’t. Your original app is untouched, and the two are independent from then on. The new project is still a Base44 app, hosted by Base44.

base44 dev starts a local development server. Base44’s local development overview is precise about what it does: backend functions run on your machine in Deno, entity data lives in an in-memory database that is cleared when you stop the server, and uploads are saved to a temporary folder. OAuth sign-in and built-in integrations such as sending email or AI generation are forwarded to Base44, and automations don’t run locally. It is a development tool, not a way to host the app.

Option 4: export your data as CSV

In the dashboard, open Data, select a table, click More actions, then Export. You get that table as a CSV file (Managing your app data).

Three details are worth knowing before you rely on this:

1. One table at a time. An app with twenty tables means twenty exports, and relationships between them are just IDs stored in fields. Keep the IDs when you move the data, or those links break.
2. The table view stops at 5,000 rows, the CSV doesn’t. Base44’s docs say the dashboard table shows up to 5,000 items, and recommend exporting to CSV to see everything.
3. Users are a different matter. App users live in the Users section, and Base44’s own privacy documentation states that app users can’t be exported: when it describes cloning an app into another region, it says users will need to sign up again. Password hashes never leave Base44.

Going the other way is limited too: CSV imports into Base44 add new rows only and never update existing records.

What the exports leave behind

Put the four options together and this is where each part of your app ends up:

Why exported code still calls Base44

A Base44 frontend talks to its backend through the Base44 SDK. src/api creates a client with your app’s ID, and every data call in your pages, such as fetching a list of orders or saving a form, becomes an HTTP request to Base44’s API. Backend functions use the same SDK from the server side. Base44’s developer docs are explicit that integration calls always run on Base44 infrastructure, so your secrets never live in your frontend.

That design is why the export feels complete and isn’t. Every line of the app is there, but every line assumes Base44 answers on the other end. To run the code somewhere else you have two choices: rewrite every SDK call against a different backend, or run a backend that answers those calls the same way Base44 does.

Your realistic options

1. Stay on Base44 and keep regular exports. Turn on GitHub sync (or download a ZIP after big changes) and export your important tables to CSV on a schedule. You own copies, not an independent app, but you’re protected against losing work.
2. Rebuild on another stack. Supabase is the common choice; our guide to moving a Base44 app to Supabase lays out what that involves. Expect to rewrite the data layer, the security rules and the functions, and to ask every user to reset their password.
3. Move the whole app to a Base44-compatible backend you own. This is what Unbase44 does. Your code goes into a private GitHub repo, your records into your own database, your files into your own storage, and a documented backend that speaks Base44’s API runs on your hosting. Users keep their passwords, and nothing about the app has to be rewritten.

A checklist before you export anything

• Check your plan: the ZIP and GitHub options need Builder or higher.
• Export every table to CSV and keep the files somewhere safe, whatever else you decide.
• Write down the names of your secrets (the values can’t be exported).
• List your connectors, automations or workflows, and anything your app sends by email.
• Note your custom domain’s DNS records, so you can point the domain elsewhere later.
• If you have paying users, note how payments reach your app (Stripe webhooks, for example), because those addresses change if the app moves.