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: it runs, locally or on another host, but only against base44's backend, 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)
• Entity schema files, one JSON schema per entity (a GitHub-synced repo leaves these in Base44)
• A package.json that includes @base44/sdk, and a vite.config.js with Base44's build plugin

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 entity schemas.

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 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

Base44's docs show this structure (project structure):

your-base44-app/
├── package.json        ← includes @base44/sdk
├── vite.config.js      ← build config with Base44's plugin
├── tailwind.config.js
├── index.html
├── src/
│   ├── pages/          ← one file per route (Home.jsx → /)
│   ├── components/
│   │   └── ui/
│   ├── api/            ← Base44 SDK client configuration
│   ├── hooks/
│   ├── lib/            ← Base44 integration and app configuration
│   └── utils/
├── entities/           ← one JSON schema per entity (not in a GitHub-synced repo)
└── functions/          ← one TypeScript file per backend function (sometimes missing)

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

5. Run it locally, against Base44

Base44's docs give the route for a GitHub-synced repo (GitHub integration):

npm install
npm install -g base44@latest
base44 login
base44 link   # the link file is gitignored, so every fresh clone needs this
base44 dev

base44 dev starts a local Base44 backend and your frontend dev server together. Functions run on your machine and entity data lives in a local in-memory database that is cleared when you stop the server, while OAuth sign-in and built-in integrations are forwarded to your deployed app. base44 dev --remote runs only the frontend, against your live app, and in that mode writes go to your production data.

So the export does run, with Base44 behind it. Every data call still goes through @base44/sdk to a Base44 backend, local or hosted, which is why 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 entity schemas. 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, one file per route: per Base44's docs, Home.jsx becomes / and Settings.jsx becomes /settings. 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/api/ and src/lib/

The SDK layer. Base44's docs describe src/api as the "Base44 SDK client configuration for communicating with your backend" and src/lib as "Base44 integration and app configuration code"; the rest of the app imports the client as import { base44 } from "@/api/base44Client". In a real migration this layer is what you replace, with a Supabase client, a Postgres client, or whatever your new backend uses.

functions/

Your backend function source, one TypeScript file per function. They run on Deno on base44's servers, each built around Deno.serve and createClientFromRequest. 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.

entities/

The most useful part of the export for a migration. Per Base44's docs, "Each entity has a JSON schema file that defines its fields", and you use those files as the source of truth when generating your new SQL DDL or Prisma schema. One catch from the same page: "When using GitHub 2-way integration, entities are managed in Base44 and are not included in your local repository." If your repo has no entity files, base44 eject copies the schemas (its docs: "Your entity schemas are copied, but not your data"), or read each table's Schema view in the data dashboard.

Base44's docs give this example entity file:

{
  "name": "Task",
  "type": "object",
  "properties": {
    "title": {
      "type": "string"
    },
    "completed": {
      "type": "boolean",
      "default": false
    }
  },
  "required": ["title"]
}

Every record also carries built-in fields the file does not list: id, created_date, updated_date, created_by (the creator's email) and created_by_id. Translating the entity to Postgres DDL, with a creator-only access rule turned into row-level security:

create table tasks (
  id text primary key,                       -- keep Base44's string ids so references survive the import
  title text not null,                       -- "required": ["title"]
  completed boolean not null default false,  -- "default": false
  created_date timestamptz not null default now(),
  updated_date timestamptz,
  owner_id uuid references auth.users(id)    -- filled from created_by_id through your user-id mapping
);

alter table tasks enable row level security;
create policy "owner_can_read" on tasks for select using (auth.uid() = owner_id);
create policy "owner_can_write" on tasks 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
Automations	Scheduled, entity-event and connector automations run on Base44; on the new platform you rebuild them on its own scheduler and triggers
Webhook endpoints	Each Base44 function has its own HTTP endpoint on Base44; every provider that calls one must be repointed to the new URL
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";
import { writeFile } from "node:fs/promises";

const base44 = createClient({ appId: process.env.BASE44_APP_ID! });
await base44.auth.loginViaEmailPassword(process.env.BASE44_EMAIL!, process.env.BASE44_PASSWORD!);

async function dumpEntity(name: string) {
  const all: unknown[] = [];
  let page = await base44.entities[name].list({ limit: 1000 });
  all.push(...page.items);
  while (page.has_more) {
    page = await base44.entities[name].list({ cursor: page.next_cursor, limit: 1000 });
    all.push(...page.items);
  }
  await writeFile(`export/${name}.json`, JSON.stringify(all, null, 2));
  console.log(`${name}: ${all.length} rows`);
}

for (const name of ["Project", "Task"]) await dumpEntity(name);

The cursor form of list() returns one page as { items, next_cursor, has_more } (see our Base44 SDK reference), and the entities run one after another rather than in parallel because Base44's rate limits apply per person. The script reads only what the signed-in user is allowed to read. If access rules hide rows from that user, use each table's CSV export (Option A) or run the dump inside a Base44 backend function with the service role, which Base44's docs say bypasses entity access rules entirely.

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 a local run. npm install will succeed and base44 dev will run the app, but against a Base44 backend: a local in-memory database, or your production data with --remote. A working local run proves nothing about life after Base44. Once the new backend is wired in, verify by clicking actual data-loading routes, not just landing pages.

3. Forgetting the entity schemas. They are the most useful part of the export. If your GitHub repo has none (two-way sync leaves them in Base44), get them with base44 eject or from each table's Schema view before you start, and use them 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 the entity schemas. 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.