Skip to content
Heartscale

base44Published on · Heartscale team

How to export your Base44 code and host the app elsewhere

Base44 lets you export your code on the Builder plan and up, either as a ZIP file or through GitHub sync. What you get is a React project built with Vite, with the front end, the backend functions and the table structure. The database, logins and integrations keep running on Base44, so hosting everything elsewhere means replacing that backend.

Heartscale’s recommendation: before you export, list the Base44 SDK calls in the code and decide whether moving the front end is enough or the whole backend has to leave. If the app has logins and personal data, plan the password reset and get the permissions reviewed before you switch.

Which plan unlocks export

According to Base44’s developer tools page:

  • Free: you can view your app’s code, but not edit it.
  • Paid plans: unlock code editing.
  • Builder or higher: unlock ZIP export and the GitHub connection.

On the pricing page, in October 2026, Builder costs US$ 40 per month billed annually. It is the cheapest plan that includes the GitHub integration.

What comes with the code and what stays on Base44

The docs describe the ZIP as a standard React project built with Vite. Here is what leaves and what does not:

Item In the ZIP or on GitHub? Where it lives afterwards
Front end (React + Vite) Yes Wherever you host it
Backend functions The code, yes Still run on Base44
Table structure (fields and permissions) Yes The data stays on Base44
Table data No Export as CSV from Data
App users No Export as CSV from App Users
Secrets No Stay on Base44
Version history No (the ZIP holds only the saved version) Stays on Base44

The key point is on the same page: the exported code uses the Base44 SDK. Data, logins, functions and integrations therefore stay on Base44 and use your live app’s data. The docs say self-hosting is not supported. Running fully outside Base44 means replacing the database, login system and integrations, and rewriting the code that calls each one.

It helps to know what that backend does, per Base44’s backend overview:

  • Entities: a MongoDB-compatible NoSQL database with no enforced schema.
  • Login: email and password, Google, Microsoft, Facebook, Apple and SSO.
  • Functions: TypeScript running on Deno, with no server for you to maintain.
  • Built-in integrations: SendEmail, UploadFile, invokeLLM, GenerateImage and others. They run on Base44’s infrastructure and use integration credits (Built-in integrations).
  • Hosting: single-page apps only, with custom domains and HTTPS. Server-side rendering is not supported.

Step 1: export the code as a ZIP

From the docs:

  1. Open the app in the Base44 editor on a computer. Export is not available in the phone editor.
  2. Click the More actions icon in the top right.
  3. Select Export project as ZIP.
  4. Click Download ZIP.

You need edit access to the app. The ZIP is a snapshot of the code at that moment.

Step 2: or connect GitHub

GitHub is the better choice if the app will keep changing. The GitHub integration works like this:

  1. In the editor, click Dashboard.
  2. Click the GitHub icon in the top right, then Connect to GitHub.
  3. Click Connect GitHub and authorize Base44 Builder.
  4. Pick the account or organization and the allowed repositories. Click Install.
  5. Name the repository and click Create Repository.

Rules that trip people up:

  • Only the app owner can connect, reconnect or link a repository.
  • Sync is automatic in both directions. There is no manual push.
  • The default branch must be named main. Other names, such as master, are not supported.
  • Changes on main reach Base44, but they only go live after you click Publish.
  • Sync cannot be paused: it is either connected or disconnected.
  • After disconnecting, reconnecting requires a different repository name.
  • Version History cannot restore versions from before the integration. It only restores what is in the repository.

Do not confuse this with the GitHub API connector, which lets your app read issues and pull requests. It does not sync code (Connecting GitHub to your app).

Step 3: export the data and the users

The code carries no records. From the app data page:

  1. In the editor, click Dashboard, then Data.
  2. Select the table.
  3. Click More actions, then Export. With a filter on, the option reads Export filtered records and downloads only the matching rows.
  4. Repeat for each table.

The dashboard shows up to 5,000 items per table. The CSV includes all of them.

For the user list, the user data page points to Dashboard → App Users → More actions → Export to CSV. Both files include every row, with personal data for all users. Store them somewhere safe.

The docs do not say which columns the user CSV contains, and they do not mention passwords. If you are replacing the login system, plan a password reset for everyone.

Step 4: choose where to host

There are two paths, and the amount of work is very different.

Path A: front end elsewhere, backend on Base44

This is the path the docs support. You host the front end wherever you like, and it keeps calling the Base44 backend. In practice:

  1. Get the code from GitHub or the ZIP.
  2. Check the build script in package.json and generate the static files.
  3. Deploy to a static host or a VPS. Configure the server to send every route to index.html, as with any single-page app.
  4. Point your domain at it.

What changes: the address and the server for the front end. What does not change: the database, logins, functions, integration credits and the Base44 subscription. The reverse also works: build elsewhere and deploy the files to Base44 hosting, with a custom domain and automatic HTTPS.

This path suits you if you want control of the front end, your own domain or your own deploy pipeline. It does not help if you want to stop paying Base44 or move your data out.

Path B: leave Base44 completely

Here you replace every piece of the backend with your own. The minimum list:

  1. Database. Entities are NoSQL with no enforced schema. In a relational database, such as Supabase’s PostgreSQL, you define tables, types and keys, then import the CSVs.
  2. Permissions. Base44’s row-level and field-level rules do not come along. Recreate each one. In Supabase, that means RLS: see how to configure Supabase RLS.
  3. Login. Set up the providers again (Google, Microsoft, Apple) with your own credentials and import the users. Without passwords, ask everyone to reset.
  4. Functions. Rewrite the backend functions for the new environment. Replace the Base44 SDK calls.
  5. Integrations. Every SendEmail, UploadFile or invokeLLM call needs a service of your own, with your own API key.
  6. Connectors. OAuth connections managed by Base44 need your own OAuth app on each service.

Search the code for every Base44 SDK call. That list is the real size of the migration. In our reviews, we build that list file by file and note, next to each call, the piece of the new backend that will replace it.

Step 5: test and switch without losing data

  1. Run the new app at a test address with a copy of the data.
  2. Test login, sign-up, reads, writes, file uploads and each integration.
  3. At cutover, pause app usage, export the CSVs again and import the final version.
  4. Point the domain at the new server.
  5. Only deactivate the app on Base44 after you have checked the data at the destination.

Before sharing any CSV with your team, the docs themselves recommend removing other people’s data.

If your app is on Lovable rather than Base44, the path is different: see how to leave Lovable.

Do it yourself or hire help?

This guide is enough for Path A; the table shows when it pays to have a team alongside you.

Situation Path
Front end elsewhere, backend on Base44, and someone on the team who can run the build Do it yourself with this guide (Path A)
Leaving Base44 completely, with real users’ data Bring in a team to model the relational database and recreate the permissions
Google, Microsoft or Apple login, or personal data in the app Request a Heartscale diagnostic: it lists every SDK call and what changes in the login
A tight deadline, or no one technical on the team Hire the migration at a fixed price

Request a Heartscale diagnostic

Our team maps every Base44 SDK call in your code, measures your data volume and tells you whether Path A or Path B makes sense. You receive a platform migration plan covering what changes in the database, logins and integrations, with a fixed price.

The launch-price diagnostic costs US$ 19 (was US$ 79) and is credited toward the migration if you go ahead. We only work on apps whose owners can prove they own them.

Request the diagnostic

Frequently asked questions

Frequently asked questions

Which Base44 plan lets me export my app's code?

ZIP export and GitHub sync require the Builder plan or higher. On the Free plan you can view the code, but you cannot edit or export it.

Does exported Base44 code run on its own on another server?

Not fully. The code uses the Base44 SDK, and the docs say data, logins, backend functions and integrations keep running on Base44. To leave for good, you need to replace that backend with your own.

Does the Base44 ZIP include my app's data and users?

No. The ZIP includes the front end, the backend functions and the table structure. Data is exported as CSV from the Data area, and the user list is exported as CSV from App Users.

Can I host just the Base44 front end on Vercel, Netlify or a VPS?

Yes. Base44's docs let you host the front end elsewhere and keep the backend on Base44, which still stores the data and handles logins.

Is Base44's GitHub sync two-way?

Yes. Changes sync in both directions, with no manual push button. What lands on the main branch on GitHub reaches Base44, and you still click Publish to make it live.

Will my Base44 users keep their passwords if I migrate the app?

Base44's docs do not say the user export includes passwords. Plan a password reset flow on the new system.

Is it worth hiring someone to export my Base44 code and host it elsewhere?

It is when you are leaving Base44 completely and the app has real users, logins or personal data, or when no one on the team reads code. Hosting only the front end is often something you can do yourself. Heartscale runs a launch-price diagnostic for US$ 19 (was US$ 79), credited toward the migration if you hire it within 15 days.

Start with the diagnostic.

The diagnostic costs US$ 19, paid by payment link. We deliver the report in 2 business days and walk you through the findings in a meeting. The fee is credited if you hire the service within 15 days. Everything we set up stays in your name.

Reduces the risk, does not eliminate it. We only work with the app’s owner, with proof of ownership.