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, despite write-ups that send you there. 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 (base44.com/pricing, checked 2026-09-23; billed monthly, then the annual-billing rate):

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

Note the tier: Builder, not Starter. A single month bought purely to get the code out is $50 on monthly billing (the $40 rate needs a year's commitment), 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.

What base44 eject does (and why it is not an exit)

Base44 now markets a fourth route, from the command line. Its developer page answers "Can I own and export my code?" with: "Eject to a local project any time, sync two ways with GitHub, and reach your backend through the real API, SDK and CLI. It's managed, not locked." (base44.com/developers, read 23 Sep 2026). The pricing page goes further: "Nothing is locked to the platform."

The CLI documentation is more exact about what base44 eject does. It "creates a new Base44 backend project with a unique app ID and downloads your app's frontend code and backend resources locally", and "Your original app remains in Base44 unchanged" (Start from an existing Base44 app). The command reference adds the line that matters for a migration: "The ejected project has an empty database. Your entity schemas are copied, but not your data."

Read together, eject gives you three things:

1. A second Base44 app, not a standalone one. The copy gets its own app ID, and the docs tell you to compile it with base44 build rather than your own build tool so that the new ID is injected into the bundle. Every @base44/sdk call in the ejected code still goes to Base44, to the new backend.
2. Schemas as files, data left behind. Entity schemas, functions and configuration land in a local base44/ directory. The rows stay in the original app; the copy starts empty.
3. Two independent projects. The original keeps running where it was, and per the docs "the 2 projects are independent after ejection". Edits to one never reach the other.

The GitHub route is the other half of the "managed, not locked" claim, and it keeps the app on Base44 by design. Base44's docs list it as "Two-way auto-sync with a GitHub repo, requires Builder plan", the option for developing the existing app locally without creating a separate copy. The repo mirrors the app; it does not replace the platform underneath it.

Pick the route by what you are trying to do:

Your goal	Route	What you end up with
A copy of the source to keep or hand to an engineer	ZIP (Builder or higher)	Files with no history and no sync
Keep building on Base44 in your own editor	GitHub connection (Builder or higher)	A repo that syncs both ways with the live app
A separate copy you develop locally	base44 eject (CLI, Node.js 20.19.0 or higher)	A new Base44 app ID, an empty database, code and schemas on disk
Run the app without Base44	Migration	Every SDK call and the backend replaced

If the appeal of eject is working with an AI coding agent in your own editor (Base44 says its CLI "is optimized for leading AI agents like Claude Code and Cursor"), Base44 vs Claude Code compares the two ways of building. Leaving the backend no longer means leaving Base44's AI editor, either: Base Code works on "an existing GitHub codebase" through branches and pull requests and leaves production hosting to you, so a migrated app in GitHub can still be edited from Base44's AI chat (Base44 docs, read 17 October 2026). None of the first three routes removes the @base44/sdk dependency, and none of them moves a single row. Leaving the platform still means replacing the SDK calls and the backend: the 80–200 engineer-hour job this guide sizes in its FAQ, and the scope a Base44 migration quote is built on.

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. This one fails silently: the export completes but backend/functions/ is empty. Re-run the export before assuming the functions are gone.

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 and 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.filter() or .list() call, and every base44.functions.invoke() 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);

The schema is the most stable surface and the foundation the rest of the migration is rebuilt on; 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. Before committing either way, run the migration payback math against what staying costs you each month.

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 step of a migration, not the migration. Plan for the rest.

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). Still choosing? The Base44 comparison hub puts every head-to-head we publish on one page.
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. This is the step where it pays to bring in a Base44 developer.
6. Cut over.

The export is a tool. The migration is the work. Whether to do that work at all is a stay-or-migrate call worth making first; the $1,500 written recommendation puts that one decision in writing, with a 36-month cost comparison, in 3–5 business days.

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 15-minute call with the engineer who would lead the work. Written fixed-price proposal within one business day.

Prefer the findings in writing first? A one-day Base44 code audit puts the app's architecture, security and SDK call patterns in a written report with a prioritised remediation plan, and its $497 fee is credited in full against any fix, build, migration or written-recommendation engagement booked within 30 days.

Book a free migration assessment

Related migrations

• Base44 to Next.js + Supabase — the full-stack destination for the exported code.
• Base44 to Vercel — frontend-first migration with your choice of backend.
• When to leave base44 — decision framework if you are still evaluating.