Code export · Base44
Base44 code export, and what is still missing once you have the repo
Export policy checked on September 2026
What comes out
What Base44 actually exports.
Base44 (a Wix company) does let you take code out, and it's real React — but it's worth being precise about which layer comes with you and which stays behind. The front end travels; the backend does not.
React front end
Standard .jsx pages and components, CSS and package.json, plus config and declaration files.
Three ways out
A ZIP button, push-to-GitHub, and the `base44` CLI's `eject` — all on the Builder plan or higher (not free).
Entity schemas, not data
`eject` clones your app into a NEW Base44-hosted project (a new app ID) and copies the entity schemas — your data does not come with it.
SDK calls to Base44
The exported front end still calls Base44's backend through its SDK — the code references services that live on Base44's infrastructure.
How the export works: Use the ZIP download, connect a GitHub repo (one-way, Base44 → GitHub), or run `base44 eject` from the CLI. Note what `eject` really does: it doesn't detach you, it spins up a fresh Base44-hosted copy from your schemas — so it's a duplication step, not a way off the platform.
The gap
What the export does not include.
This is where the "partial" verdict earns its name. The front end is portable; everything that makes the app *work* stays on Base44, so the export is a head start on a rebuild rather than a finished, movable product.
The entire backend stays locked to Base44
Backend runtime, database queries, business logic, auth and integrations all live behind Base44's SDK on its infrastructure. None of it exports as runnable code, so a hired engineer has to rebuild the backend — commonly onto Supabase and Vercel — before the app is truly yours.
BlockerSources: [1]Your data doesn't export
The schema shape is copied by `eject`; the rows are not. Any real move means a separate data extraction and import, reconciled against the source — a step the export doesn't do for you.
MajorSources: [1]The front end alone does nothing useful
Run the exported code without Base44's backend and pages render, but live actions — reads, writes, auth — return nothing, because they're calling a backend that isn't yours. It looks like an app and behaves like a shell.
MajorSources: [2]GitHub sync is one-way
The GitHub integration pushes Base44 → GitHub, not back. So you can't treat the repo as your working source and expect Base44 to follow — another sign the export is an exit path, not a two-way workflow.
Minor
The real question
Is the exported code maintainable?
Base44 export:Mixed
The part you can take is fine: it's ordinary React an engineer can read and build on. The problem is what's coupled to it. Because every data operation goes through Base44's SDK, the exported front end isn't a maintainable standalone app until someone replaces that backend — schema, queries, auth and integrations — with something you host. In practice teams keep the UI and re-platform the backend onto Supabase/Vercel. So it's maintainable as a front-end starting point, and a rebuild everywhere behind it.
Your options
What to do with the export.
Three honest routes. The right one depends on how far the app has to go and who is going to own the code once it gets there.
- 01
Keep building on Base44
Stay on the platform and keep shipping. The export is your insurance policy, not something you have to act on today.
- Right when the app is early and Base44's hosted backend is doing the job.
- Wrong when you need to own the data layer or host the backend yourself.
- 02
Keep the UI, rebuild the backend
Take the exported React front end and have an engineer stand up a real backend (Supabase/Postgres + auth) it can talk to, migrating your data across.
- Right when the interface is roughly right and the backend lock-in is the thing you're actually trying to escape.
- 03
Rebuild as one owned app
Use the export and your schemas as a reference and rebuild front and back end as a single codebase you own and host.
- Right when the app has to scale and you want one coherent, reviewed stack rather than a stitched-together front end.
What actually happens when you run the Base44 export by itself
The most useful thing to know about a Base44 export is what it feels like to run it unplugged. The build succeeds, the app loads, the layout is all there — and then nothing works. Buttons that should read or write data come back empty, because every one of those calls is aimed at Base44's SDK and its hosted backend, not at anything in the ZIP you downloaded. That's the honest shape of a "partial" export: you own the shell and the styling, and the app's actual behaviour is still a rebuild. The `eject` CLI doesn't change this — it clones you into another Base44-hosted project rather than cutting the cord.
- Front end
- Exports
- Backend
- Locked
- Data
- Not exported
- Runs standalone
- No
FAQ
Questions people actually ask.
- Can you export your code from Base44?
- You can export the React front end — via a ZIP, push-to-GitHub, or the `base44 eject` CLI, on the Builder plan or higher. What you can't export is the backend: database, business logic, auth and integrations stay on Base44's infrastructure behind its SDK. So the answer is "the front end, yes; the whole app, no."
- Does the Base44 export include the backend and database?
- No. `eject` copies your entity schemas into a new Base44-hosted project but not your data, and the backend runtime never comes out as code. Any real move requires rebuilding the backend and doing a separate data migration — the export gives you the UI, not the engine.
- What does `base44 eject` actually do?
- Despite the name, it doesn't detach you from Base44. It clones your app into a fresh Base44-hosted project with a new app ID, copying the entity schemas (not the data). It's a duplication and starting-point step, not a way to get a self-hosted, independent application.
- Will a downloaded Base44 app run without Base44's servers?
- Not meaningfully. The front end renders, but every data read, write and auth call is routed through Base44's SDK to its backend — so on its own the app is a static-looking shell. To make it independent you have to replace that backend with one you host.
Every builder, one table
Code export across the hub, at a glance.
The same status table on every export page. “Exports” means real, usable source comes out; “partial” means a major layer is missing; “none” means no source export at all. The nuance is on each page.
| Platform | Code export | What you get |
|---|---|---|
| Lovable | Exports code | React repo via GitHub |
| Base44This page | Partial export | Front end; backend locked |
| Webflow | Partial export | Front end only, no CMS |
| FlutterFlow | Exports code | Dart / Flutter source |
| Framer | No code export | Host-only, no export |
| Bolt.new | Exports code | Project files / GitHub |
| Bubble | No code export | No source export |
| Replit | Exports code | Full code, you own it |
| Softr | No code export | No code (data only) |
| Glide | No code export | No code (data only) |
| Adalo | No code export | No source export |
| Retool | Partial export | Self-host, not source |
| Xano | Partial export | API portable, no export |
Sources
Every claim, traced to a primary source.
The numbered references in the body link here. We cite vendor docs, pricing pages, changelogs and named reporting — dated where the document is dated, so the page can be re-audited each quarter.
- [01]Start from an existing Base44 app — eject behaviour
Base44 Support Docsdocs.base44.com
- [02]base44/cli — deploys to Base44's hosting platform
GitHubgithub.com
- [03]Wix acquires Base44
Wix Press Room · 2025-06-18wix.com
Own the Base44 app outright?
We’ll map the route to code you actually own.
Book a call with Jackson, our Growth Partner — he’ll walk your export or app, the gaps that matter, and a fixed-price plan to get it production-ready, live on your screen. Or get an instant estimate first.
Or see fixed-price migration packages and how we work.