Host a Base44 app elsewhere: GitHub, frontend and backend

Want to host an app built with Base44 outside its hosting? You can export code to a repository and deploy a compatible frontend from Git, but that does not automatically move its database, users or server functions. First decide whether you only want to change where the interface is served or replace the entire platform.

Base44 documents GitHub export and two-way sync. Its SDK also lets an external application use Base44 as a backend. One possible route is to publish the frontend on Hostbrid Projects while keeping Base44 services for now. We have not migrated a real customer app or certified general compatibility; check the repository and plan before ordering.

1. Export the project and check what is included

From the editor, connect GitHub or download the project as a ZIP. Base44’s official GitHub guide describes export and sync; its developer documentation also offers a CLI and an eject-to-local workflow. Check the plan requirement and available options in your account, as these can change.

If you use a ZIP, extract it and create or push a Git repository; Projects connects repositories and does not accept a ZIP as a direct deployment. Before the first push, check .gitignore and remove secrets, user data, database dumps and .env files. Confirm which branch has the latest changes and keep an independent copy of the original project.

2. Separate the frontend, backend and data

Inspect package.json, scripts, dependencies and project files. A React/Vite frontend may need a static build; a project with routes or server processes needs a compatible runtime. The React label alone does not tell you which one applies.

Look for @base44/sdk imports, base44.entities calls, authentication, backend functions, connectors and API calls. The official SDK documentation supports creating a client in an external app and using Base44 as its backend. That keeps an operational dependency on Base44: deploying the frontend elsewhere does not migrate its tables, users, permissions, files, automations or connectors.

The SDK also limits service-role access to backend functions hosted by Base44; an external backend does not receive that elevated permission. Do not put an admin key in the browser to work around this. If you want to leave Base44 completely, plan separate replacements and migrations for authentication, data, access rules, uploads, functions, email, payments and integrations. Exporting code does not prove those services are portable.

3. Test the repository on Projects

Connect the repository to Hostbrid Projects, select the right branch and review the commands and output directory the project actually uses. Projects can deploy from Git; service options, resources and limits depend on the current plan. Do not copy generic commands or assume every Base44 function will run as a Node process.

Start with a temporary domain. Test direct navigation to routes, sign-in and sign-out, permitted reads and writes, file uploads and each integration. Check browser console and network errors, CORS, allowed URLs, OAuth and callbacks. If Base44 remains your backend, verify that requests from the new domain still work and data policies remain in force.

4. Change the domain only after testing

Do not change the final domain until functional tests pass and you have reviewed secrets, permissions, quotas and external costs. Keep a rollback path: leave the old hosting and Base44 available until you verify the new version. A successful build only shows that code compiled; it does not prove that users, payments or data have migrated.

For a Git-deployed frontend, compare the current Projects plans and resources. If you also need to replace Base44’s backend, estimate the migration first and test with a copy of the data. The right choice depends on how much of the managed backend you want to keep.

Sources: Base44 developer docs · Base44 SDK client · Base44 GitHub integration · Hostbrid Projects