Base44 Code Export: What You Get and What You Rebuild

This guide is the answer to one question: "Can I just export my base44 code and run it elsewhere?" The short version is no, and this page explains exactly why and what to do about it.

If you are still on the fence about leaving, read when to leave base44 first. If you have decided to leave and want to know what target to migrate to, see Next.js + Supabase or Vercel. This page covers the export step in detail, which is the first phase of any migration.

What the base44 code export actually is

There are two, and base44's docs name both: Export project as ZIP and GitHub connection, each behind the More actions (⋯) icon in the editor's top bar — not in Settings, where most write-ups send you. Either way the files are identical, and either way they are the sharp end of base44's vendor lock-in problem.

When export works, you get:

• A GitHub repo with your React frontend code
• The Tailwind config and design tokens
• Your backend function source files (Deno-flavored TypeScript)
• A schema.json file describing each entity and its fields
• A package.json with declared dependencies
• A README pointing back at base44's docs

When export does not work — and it sometimes does not — you get a partial repo missing backend functions, or a repo that does not exist at all because the export silently failed. This is well-documented on feedback.base44.com, and was the subject of the Nocode.mba reviewer's line that "GitHub export remains in beta...feature shipping too fast, suggesting stability concerns." Note whose word "beta" is: base44's own docs no longer use it, saying as of 2026-09-13 only that you can export "as a ZIP file or to GitHub on a Builder plan or higher". Shipped and occasionally flaky, not a labelled preview.

Who can export, and by which method

Base44's docs gate one-click export at the Builder plan or higher. Against the tiers base44 publishes today (checked 2026-09-13):

Plan	One-click export (ZIP or GitHub)
Free ($0), Starter ($16/mo)	No
Builder ($40/mo), Pro ($80/mo), Elite ($160/mo), Enterprise (custom)	Yes

Note the tier: Builder, not Starter. A month bought purely to get the code out is $40, not $16 — and needing to buy one at all is the lock-in.

The three routes differ in what survives the trip:

Method	Where	What it costs you
ZIP	More actions (⋯) → Export project as ZIP	No git history, no remote, no sync — a snapshot you version yourself.
GitHub	More actions (⋯) → GitHub connection	base44 holds a grant on your GitHub account, and the sync runs both ways.
Manual copy	Workspace › Code, file by file	No dependency manifest, no build config, no backend/functions, no schema.json.

Step-by-step: how to export

1. Verify you are on Builder or higher

Check the plan first — on Free or Starter the button is not there to find. Upgrading is instant; downgrade once the export is in hand.

2. Connect your GitHub account (GitHub route only)

Skip this if you are taking the ZIP. Otherwise More actions (⋯) → GitHub connection, then follow the setup flow. Read GitHub's authorization screen rather than clicking through it — if the grant is account-wide rather than one repo, make a dedicated GitHub org for the export first.

3. Trigger the export

Export as ZIP

More actions (⋯) → Export project as ZIP. No repo, no remote, no history — git init it before you change a single line, or your first migration mistake has nothing to roll back to.

Export to GitHub

With the connection in place, confirm the target repo name and push. The export takes thirty seconds to ten minutes depending on app size.

If the export fails, base44's UI gives you a vague error. Common causes:

• Repo name conflict. A repo with that name already exists. Pick a different name or delete the conflicting repo.
• GitHub auth expired. Re-authorize the GitHub integration.
• App in inconsistent state. If your app was mid-AI-build when you tried to export, base44 sometimes refuses. Wait for the build to complete, then retry.
• Backend functions missing. The most common silent failure. The export completes but backend/functions/ is empty. Re-run the export; it usually succeeds the second time.

4. Clone the repo locally

git clone git@github.com:yourorg/your-base44-app.git
cd your-base44-app
ls -la

You should see roughly this structure:

your-base44-app/
├── README.md
├── package.json
├── vite.config.ts
├── tailwind.config.ts
├── tsconfig.json
├── schema.json
├── src/
│   ├── components/
│   ├── pages/
│   ├── integrations/   ← @base44/sdk adapter
│   ├── lib/
│   └── main.tsx
└── backend/
    └── functions/      ← server-side functions (sometimes missing)

If backend/functions/ is empty or missing, your backend functions did not export. Re-run the export from base44.

5. Try to run it (and watch it fail)

npm install
npm run dev

The dev server starts. The UI renders. Then you click anything that fetches data, and you see something like:

[base44/sdk] Authentication failed: invalid app_id
Error: Cannot read properties of undefined (reading 'find')
    at Dashboard (src/pages/Dashboard.tsx:14:42)

This is expected. The SDK only authenticates against the base44 platform. The exported code cannot run standalone.

Exporting on the free plan

There is no one-click export below Builder, but the source is still on screen: base44 lists the project's files under Workspace › Code, and you can copy them out by hand. Yair Morgenstern documented this route in July 2025 — "Copy the jsx files from base44 into your directory (you can see them under Workspace > Code)" — scaffolding a fresh Vite app around the files, then hand-writing the vite.config, tsconfig and shadcn/ui setup the copy leaves out.

What that buys is JSX and nothing that runs it: no package.json, no build config, no backend/functions, no schema.json. It rescues your design from base44, not your application. With a backend of any kind, one month of Builder is cheaper than rebuilding the rest by hand.

What is in the export, line by line

src/components/

Pure React components, mostly. JSX, Tailwind classes, hooks, props. These are the most portable part of the export. ~80–95% can move to a new framework with light edits.

src/pages/

Page-level components, usually one per route. These reference @base44/sdk heavily. Every base44.entities.X.find() and base44.functions.Y() call has to be rewritten when you migrate.

src/integrations/

The SDK adapter layer. Often a base44Client.ts file that initializes the SDK with your app_id. This whole folder gets deleted in a real migration; you replace it with a Supabase client, a Postgres client, or whatever your new backend uses.

backend/functions/

Your backend function source. These are Deno-flavored TypeScript files that run on base44's server-side runtime. The function bodies port mostly cleanly to Supabase Edge Functions or Next.js Route Handlers — same Deno-or-Node patterns. Replace base44.entities.X calls inside with calls to your new database client.

schema.json

The most useful single file in the export. It describes every entity, every field, and every field's type and constraints. You use this as the source of truth when generating your new SQL DDL or Prisma schema.

Example shape:

{
  "entities": {
    "Project": {
      "fields": {
        "name": { "type": "string", "required": true },
        "ownerId": { "type": "userRef", "required": true },
        "status": { "type": "enum", "values": ["draft", "active", "archived"] },
        "createdAt": { "type": "datetime", "default": "now" }
      },
      "permissions": {
        "read": "owner",
        "write": "owner"
      }
    }
  }
}

Translating this to Postgres DDL:

create table projects (
  id uuid primary key default gen_random_uuid(),
  name text not null,
  owner_id uuid not null references auth.users(id) on delete cascade,
  status text not null default 'draft' check (status in ('draft','active','archived')),
  created_at timestamptz not null default now()
);

alter table projects enable row level security;
create policy "owner_can_read" on projects for select using (auth.uid() = owner_id);
create policy "owner_can_write" on projects for all using (auth.uid() = owner_id);

This is forty percent of the work of any migration. The schema is the most stable surface; build it carefully.

What is NOT in the export

This is the part nobody tells you upfront.

What's missing	Why it matters
Database rows	You have to export data separately, per entity, via base44's data export or SDK pagination
Password hashes	You cannot migrate user sessions; every user must reset their password on the new platform
@base44/sdk source	The SDK is closed-source. You cannot self-host it. You replace it.
Platform-managed auth flows	OAuth client IDs, magic-link templates, session cookies — all live on base44 servers
Scheduled task definitions	Whatever crons or scheduled prompts you set up are not in the export
Webhook endpoint configs	The URLs are documented in the export but the routing is platform-managed
Storage buckets	Your uploaded files live on base44's storage. You re-upload to your new storage
Logs and analytics	Your historical logs do not export
Custom domain config	Re-configure on the new host

A common mistake is to clone the repo, run npm install, get partial life signs, and assume the rest is fifteen minutes of work. The rest is two to three months of work. If you would rather buy that work than schedule it, our fixed-price base44 migrations are scoped by table count — $6,000 for up to 5 tables and 10 routes, $12,000 for up to 20 tables with multi-role auth and Stripe, $25,000+ for multi-tenant.

How to export your data

The code export does not include data. You need a separate step.

Option A: base44's data export (per entity)

Dashboard → Data → open the table → More Actions (⋯) → Export. One CSV per table. CSV flattens references, so relationships arrive as bare ids you re-link on the other side. Note too that base44 has capped data requests at 5,000 items since 27 November 2025 — which is why the script below pages in chunks.

Option B: SDK-based pagination script

For large datasets, write a Node script that paginates through every entity using the SDK and dumps to JSON.

// scripts/dump-base44.ts
import { createClient } from "@base44/sdk";

const b44 = createClient({ appId: process.env.BASE44_APP_ID! });

async function dumpEntity(name: string) {
  const all: any[] = [];
  let cursor: string | undefined = undefined;
  while (true) {
    const page = await b44.entities[name].find({ limit: 500, cursor });
    all.push(...page.items);
    if (!page.nextCursor) break;
    cursor = page.nextCursor;
  }
  await Bun.write(`export/${name}.json`, JSON.stringify(all, null, 2));
  console.log(`${name}: ${all.length} rows`);
}

await Promise.all(["users", "projects", "tasks"].map(dumpEntity));

Run from a machine that is authenticated to base44 (use your API token). This is the safest way to export large or relational datasets.

How long the export remains useful

The export is a snapshot. The moment you take it, it starts going stale.

If you plan to migrate, the right pattern is:

1. Day 0: Take the export. Note the snapshot time.
2. Days 1–N: Migration work happens. Do not edit the base44 app during this period unless you are doing critical bug fixes.
3. Cutover day: Take a final data export. Diff against the snapshot to find new rows. Backfill those into the new system.
4. Cutover hour: Lock base44 read-only. Final data sync. DNS swap.

If you keep editing both sides during the migration, you create a merge problem you cannot solve cleanly. Pick one source of truth at any given moment.

Common pitfalls with the export

1. Re-running export and overwriting your migration work. Once you have started rewriting the exported code, do not re-export from base44 — it overwrites your repo, and on the GitHub route the sync runs both ways. Branch and merge if you need a fresh export, or disconnect the integration the day you start rewriting.

2. Trusting npm install success. It will succeed. The app will still not work. Verify by clicking actual data-loading routes, not just landing pages.

3. Forgetting schema.json. It is the most useful file in the export. Read it carefully and use it as the spec for your new schema.

4. Budgeting for the wrong tier. Export is gated at Builder, not Starter — a month of Starter does not get you the button. Buy one month of Builder, export, downgrade.

5. Backend functions missing. Common silent failure. Re-run export. If still missing, contact base44 support. They are slow but eventually fix the export.

6. Treating the export as a complete escape. It is not. It is the first ten percent of a migration. Plan for the other ninety.

What to do with the export, in order

1. Clone it. Verify you have backend functions. Re-export if not.
2. Read schema.json. Understand your data model.
3. Pick a migration target (Next.js + Supabase, Vercel, self-hosted, Replit, Lovable, Bubble, or Firebase).
4. Stand up the new backend. Translate the schema. Backfill data. If you are weighing a managed backend against staying put, Base44 vs Supabase directly compares the two on cost, control and what you actually have to operate.
5. Rewrite SDK calls in the exported frontend, or rebuild from scratch in the new framework.
6. Cut over.

The export is a tool. The migration is the work.

Want help with the export?

We will run the export for you, audit what came through, identify the rebuild scope, and quote the migration. Free thirty-minute call.

Book a free migration assessment

Related migrations

• Base44 to Next.js + Supabase — most common destination after the export.
• Base44 to Vercel — frontend-first migration with your choice of backend.
• When to leave base44 — decision framework if you are still evaluating.