Base44 Export Code: What You Actually Get, and How to Move Off It

A Base44 code export gives you a real React frontend, the source of your backend functions and a schema file for your data. It does not give you the backend those pieces run on. Every data read, login, file upload and AI call still goes through the @base44/sdk to Base44's servers, so the export is a starting point for a migration, not a copy of your app you can host anywhere.

That is the whole answer in one paragraph. This post is for founders and developers with a Base44 app on the Builder plan or higher who want to own their stack. The rest of it is what to do about it. It covers what is in the box, why it breaks the moment it runs on its own, how to size the job in ten minutes with four grep commands, and a staged Base44 migration that keeps your app live while each piece moves.

How to export your Base44 code

Base44 offers three routes, and all of them need the Builder plan or higher, per Base44's developer tools docs:

1. ZIP download. In the editor, open Code and choose Export project as ZIP. You get a snapshot of the current saved code.
2. GitHub sync. Connect a repository and Base44 commits your changes to it automatically. The sync is two-way: commits pushed to GitHub flow back into Base44.
3. API. GET /api/apps/{app_id}/coding/export-to-zip with a personal access token returns the same ZIP, per the export endpoint reference. Useful for a nightly backup.

If you are planning to leave, use GitHub. A ZIP is one moment in time; a repo gives you history, diffs and a place for a developer to work while you keep building in Base44.

What you actually get

The left column is genuinely yours and genuinely portable. React is React. The right column is what your app actually does all day.

A common assumption is that the SDK is proprietary. It is not a black box. `@base44/sdk` is open source under the MIT license. You can read every line. What you cannot take with you is the service it talks to.

Why the export fails when you run it

Open any page in the export and you will find calls like these, adapted from the SDK README and the integrations docs:

import { base44 } from "@/api/base44Client";

const tasks = await base44.entities.Task.list();
await base44.auth.loginViaEmailPassword(email, password);
const { url } = await base44.integrations.Core.UploadFile({ file });

Each line is a network call to Base44. npm install succeeds, the dev server starts, the login screen renders, and then the first screen that needs data fails. Founders read this as "the export is broken". It is not broken. It is a frontend that needs its backend.

The SDK covers eight modules: entities, auth, functions, integrations, agents, connectors, analytics and app-logs. Each one you use is a service you will either keep renting from Base44 or replace.

Size the job before anyone quotes you

Migration cost scales with how many places your code touches Base44, not with how many pages the app has. Clone the repo and run these from its root:

grep -rn "base44.entities" src | wc -l        # data reads and writes
grep -rn "base44.auth" src | wc -l            # login, session, current user
grep -rn "base44.integrations" src | wc -l    # AI, email, file uploads
grep -rl "npm:@base44/sdk" . --exclude-dir=node_modules | wc -l   # backend functions

Backend functions import the SDK as npm:@base44/sdk, which is why the last line counts them that way regardless of folder names.

Write the four numbers down. They are the most useful thing you can bring to a call with any developer.

Disclosure: HeyDev runs Base44 migrations as a paid service. Everything in this post works without hiring us. A dozen entity calls and no functions is a short job. Hundreds of entity calls, ten functions and heavy use of InvokeLLM is a real project, and anyone who quotes it without asking for these numbers is guessing.

The staged way off Base44

The mistake is treating this as one rewrite. The SDK is already split into modules, so the migration can be too. Your app stays live through every stage.

Stage 0: get everything out

Before any code changes, take a full copy of what you would lose if your account closed tomorrow.

• Code: connect GitHub.
• Data: in Dashboard, Data, export each table to CSV, per Base44's data docs. The SDK caps a single list() or filter() request at 5,000 items, so for large tables use the CSV export or a script that pages through.
• Users: export the user list from the users table.
• Files: list every file URL stored in your entities. You will copy these to your own storage in Stage 3.

Stage 1: host the frontend yourself

Deploy the exported React app to Vercel or Netlify, still pointed at Base44. The SDK README documents exactly this setup: an external app using Base44 as its backend through createClient({ appId }). Test login, uploads and every role on the new domain before you send real users there.

You now own your hosting, your domain and your deploys, and nothing about the backend has changed yet.

Stage 2: move the data and rebuild the access rules

Create tables in Postgres from the entity schema (an entity is Base44's word for a data table). Supabase is the usual choice because it gives you Postgres, auth and storage in one place. Import the CSVs and keep Base44's id values so relationships survive.

Then rebuild the access rules. Base44 enforces per-entity permissions on its servers: per the entities docs, anonymous users see only public entities and regular users can only read and update their own User record. In Postgres, none of that exists until you write it as Row Level Security policies, the per-row access rules Postgres checks on every query. This is where migrations quietly create data leaks, and it is the step we check first in every vibe-coded app audit. Supabase's own defaults changed in October 2026 too; see Supabase stops auto-exposing new tables.

Finally, write a small data layer with the same shape as the SDK (Task.list(), Task.create(), Task.update()) so the page code barely changes. Swap the import, not every call site.

Stage 3: replace auth, functions and integrations

• Auth. Import users by email into Supabase Auth or your provider of choice. We have not found a documented way to export password hashes from Base44, so plan a password reset or magic-link sign-in on cutover day, and email users first.
• Functions. Base44 backend functions run on Deno, per the functions docs. Supabase Edge Functions also run on Deno, so most of the logic ports almost line for line. Rewrite the base44.entities calls inside them to use your database client, and keep the Supabase service-role key server-side only. Base44's asServiceRole only works inside Base44-hosted functions, so any function that uses it has to move together with the data it touches.
• Integrations. Map each integrations.Core call to a provider you own: InvokeLLM and GenerateImage to OpenAI or Anthropic, SendEmail to Resend or Postmark, UploadFile and UploadPrivateFile to Supabase Storage or S3 with signed URLs.
• Files. Copy every stored file to your bucket and rewrite the URLs in your tables.

Stage 4: cut over

Freeze writes in the Base44 app, run a final data export and import, switch the frontend's data layer to the new backend, and send the password-reset email. Keep the Base44 app on its plan for a few weeks, read-only, as your rollback.

Should you move to Next.js while you are at it?

Only if you have a reason Next.js solves: server-rendered pages for SEO, API keys that must never reach the browser, or webhooks and scheduled jobs. If none apply, keep the exported Vite app and move only the backend. The same rule appears in our Lovable fix-or-migrate guide, and the reasoning is identical: change the parts that are holding you back, not the parts that work.

What we did not verify

We built this from Base44's documentation, its API reference and the open-source SDK, as of October 2026. Folder names inside exports vary by app age, so the grep paths above may need adjusting. We have not run these commands against every export layout, and we have not confirmed whether Base44 offers password-hash export on request or on enterprise plans; ask their support before you plan the reset email. Base44 ships changes fast, so check the linked docs for anything that moved after this date.

Getting it done

If the four numbers came out small, you can do this yourself with this post as the checklist. If they came out large, or the app holds data you cannot afford to leak, we can run the migration in the stages above with the app live the whole time. Send us the four counts and we return a fixed-price quote within 48 hours of the call.

Book a 30-minute call or email mahima@heydev.us with your counts and what the app does.