How to export your Base44 app without leaving half of it behind

What you get when you export a Base44 app

The ZIP and GitHub repo contain your React frontend and the source for your custom backend functions. The CLI export also includes entity schemas and some backend configuration. These are developer tools for continuing to build a Base44 app from your own computer, not an exit from Base44. You can run the frontend locally, but code from the ZIP or GitHub still calls your original Base44 backend. The CLI eject command creates a new backend on Base44 instead. Either way, Base44 is still running the app.

To leave Base44 and keep the app working, you still need two things:

1. Your app's live contents and configuration

• Every database record and relationship, plus users, roles, login settings and private user records, and the ability for existing users to log in with the passwords they already have.
• Uploaded files and assets, their access rules, and every Base44 URL that points to them.
• Entity schemas, permission rules, secrets, and the deployment settings for backend functions.
• Automation schedules, triggers, arguments and execution identity; agents, conversations and memories; connectors, custom integrations and their OAuth configuration.
• Routes, visibility, domains, SEO, analytics and the rest of the app settings that tie everything together.

Getting all of this out still does not make it usable. The data and configuration have to be rebuilt in the shape the app expects. Records need to keep their IDs, relationships and field types. Users and private login data need the right collections and indexes. Schemas and permission rules still need to be enforced. Function and automation settings must be attached to new deployments. File URLs must be rewritten. Secrets, integrations and app settings must be restored and connected to the new system. Until that work is done, the app cannot use the data and configuration you extracted.

2. A replacement for Base44's backend

This is the much harder part. Base44's backend is the system that:

• Logs users in, reads and writes data, and enforces schemas and permission rules.
• Stores and serves files, serves backend functions, and fires automations.
• Sends email, handles AI and image generation, runs agents, connectors and integrations, and delivers realtime updates.
• Applies the app's settings and connects these services to the frontend and to one another.

All of this functionality lives on Base44's servers. The code you exported just calls those servers; it does not contain a replacement for them. That is why the export is not very useful by itself when you want to leave Base44 and keep the same app working.

A backend function shows the problem clearly. You may get the source for a function called sendInvoice, but the source alone cannot run. It still needs its entry point, runtime, dependencies, secrets, URL, permissions and any automation that triggers it. Even if you recreate all of that, the function was written to call Base44's database, users, files, email and other backend services. Until you replace those calls too, it still cannot work without Base44.

This is the lock-in. Base44 builds every app around its SDK and managed infrastructure, not as a self-contained system you can lift onto another host. Leaving means rebuilding the Base44 behavior your app relies on, recovering the live data and hidden configuration, and stitching the whole thing back together outside Base44.

Choose the export based on what you need

Need the exact export steps?

Open the method you are using. ZIP, GitHub, eject, free downloads and CSV each solve a different job, so you only need the instructions for the one you chose above.

npm install -g base44@latest
base44 eject

Your exported app can run somewhere else and still depend on Base44

Say your app has a Save order button powered by a backend function. You put the exported code on a new host, open its URL and click the button:

1. The button runs from the frontend on your new host.
2. The Base44 SDK calls the saveOrder backend function on Base44's servers.
3. That function checks the logged-in user and permissions, then writes the order to Base44's database.

Your new host is serving the screen. Base44 is still running the app behind the screen. The same pattern applies when the app logs somebody in, reads a table, uploads a file, calls an agent, starts an integration or subscribes to realtime updates.

The new URL may load and every button may work precisely because Base44 is still doing the invisible work. Cancel your Base44 subscription, and Save order stops working.

What it takes to get the whole app out

If your project is a static landing page with no login, database, functions, files or integrations, the official export may be almost everything you need. Put the frontend on normal hosting, remove any unused Base44 setup, and you can be done. I would not pay someone to “migrate” that for you.

For an app with real users and data, this means rebuilding the parts of Base44 it relies on. You need to recover the app's data and configuration, recreate the backend behavior on infrastructure you control, reconnect every piece and change the frontend to use it.

You can do it yourself if you are technical enough and your app is simple enough. Claude Code or Cursor can help too. Ask for a full migration, not a visual rebuild. Then judge and fix what the AI misses, and test login, permissions, data writes, uploads, functions, automations and integrations with real accounts and real data.

You can hand the same checklist to a good developer. But if your app relies on more than a basic database, the pieces start depending on one another: authentication and permissions control who can see each record, functions rely on secrets and files, automations call integrations, and agents carry state.

At that point, you are rebuilding Base44 outside Base44. Every piece has to work exactly as it did before. That can mean weeks of chasing edge cases and retesting every flow. Get one detail wrong and the app can still look finished, right up until a customer sees someone else's data, an automation silently stops running or your existing users cannot log in. Then you are back in the code, trying to figure out which invisible part of Base44 you missed.

I know because I went through this myself. I migrated several Base44 apps by hand and spent months chasing Base44-specific edge cases. I ended up reverse-engineering Base44's entire backend, building a compatible replacement and automating every step of the migration. That became EscapeBase44.

You can migrate the whole app without rebuilding it

EscapeBase44 moves the existing app as is: frontend, backend, database, users, auth, functions, automations, integrations, agents, conversations and memories, AI and image generation, email, files and storage, permissions, SEO and the weird configuration holding it together. The whole app is deployed automatically onto normal provider accounts you own and choose.

Base44 gives you a GitHub "export" that depends on Base44 and is unusable outside of it. EscapeBase44 gives you the complete codebase of your app, including your own backend, in a private repository in your own GitHub. The repository is wired to your providers: push a change to main, and the app redeploys automatically. It is also very human-friendly & AI-friendly: the repository includes clear instructions for local running and for changing the app, and gives Claude Code, Cursor and any other AI tools everything they need to start working on it.

After the migration, the whole app runs on infrastructure you own instead of Base44, with everything intact and working exactly as before. You can keep building with AI, edit the repository yourself, move to another provider later or hand it to any developer. You own the app, its complete codebase and the infrastructure it runs on, with no Base44 or EscapeBase44 in the picture anymore.