Can you self-host a Base44 app? The complete answer

What self-hosting a Base44 app has to include

“Self-hosting” gets used loosely, so it’s worth being precise. For a Base44 app to run without Base44, every one of these has to exist somewhere you control:

Hosting the frontend is the easy part. Everything else on that list is what Base44 provides, and it’s what makes a self-hosting plan real or not.

What you can run yourself with Base44’s own tools

Base44 doesn’t offer a self-hosted or on-premises edition, and doesn’t document one. It does give you three tools that are sometimes mistaken for one.

Hosting the frontend elsewhere. Base44 can be used as a backend service behind your own frontend. Its developer tools overview says that when you go live you can either keep hosting the frontend elsewhere or deploy its built files to Base44 hosting. Hosted elsewhere, your pages load from your server while data, sign-in, functions and integrations still run on Base44. It’s a legitimate setup, but it moves the least important piece.

The local development server. base44 dev runs a backend on your machine for development. Functions run locally on Deno, records live in an in-memory database that empties when you stop it, and uploads go to a temporary folder. OAuth sign-in and built-in integrations such as email and AI are forwarded to Base44, and automations don’t run locally (Local development). It’s built for testing changes safely, not for serving users.

Ejecting. base44 eject copies an app into a new, separate Base44 project with its own app ID and an empty database (eject). The copy is still hosted by Base44.

The missing piece: a backend that speaks Base44’s API

Your app’s code was written against the Base44 SDK. The frontend asks the SDK for records, and the SDK sends an HTTP request to a Base44 endpoint for that entity, with the query written in MongoDB’s operator syntax. Functions build a client from the incoming request and call back into the same API, sometimes with a service role that bypasses the security rules. Uploads return URLs on Base44’s storage. Live pages subscribe to changes over a realtime connection.

So there are two ways to self-host for real:

1. Rewrite the app for a different backend. Replace every SDK call with calls to Supabase, Firebase or your own API, translate the data model and security rules, and port the functions. It’s a project measured in weeks, and every user resets their password at the end. Our Supabase guide walks through it.
2. Run a backend that answers the same API. If something on your server responds to the SDK exactly as Base44 does, the app doesn’t need rewriting. The frontend is rebuilt pointing at your server, and the functions run unchanged.

The second is what Unbase44 migrates you to.

What a self-hosted app looks like with Unbase44

After a migration, your app is a repository in your GitHub account, laid out like this:

your-app/
├─ src/              your original React frontend
├─ base44/           entities, functions, agents, workflows, config
├─ server/           the Base44-compatible backend (Deno + TypeScript)
├─ docs/             architecture, local development, deployment
├─ Dockerfile
├─ docker-compose.yml
├─ README.md, AGENTS.md, CLAUDE.md

The backend is open and documented, and it runs on MongoDB, the same kind of document database Base44 uses, so records move without translation and keep their IDs. It serves the frontend, the API, the sign-in pages and realtime updates from one address.

You choose where it runs:

Pushing to main redeploys. For local development, the Docker setup starts the app and its database on your laptop with one command. Users keep their passwords: each person’s first sign-in is checked against Base44 once and then stored as your app’s own hash, which is why you keep the Base44 app published until your active users have signed in.

What it costs to run

The monthly Base44 plan goes away. Base44’s pricing runs from $16 a month (Starter) to $160 a month (Elite) billed yearly, or $20 to $200 monthly, and the plan also sets your monthly credits.

Instead, you pay providers for what you use:

• Hosting and database. Small apps typically run on a few dollars to a few tens of dollars a month; busier apps cost more, in proportion to their traffic and data. During setup you see what each option is expected to cost before you choose.
• AI. Calls go to the AI provider account you connect and are billed per use by that provider.
• Email. Sign-in codes and app emails go through your email provider, on its plan.

The migration itself is a one-time price per app, and free during the beta.

What you take on when you self-host

Self-hosting shifts some jobs from the platform to you. Be clear-eyed about them:

• Updates. On a managed platform like Railway, the operating system and database engine are handled for you. On your own server they’re yours to patch.
• Backups. Turn on automated database backups (Atlas and Railway both offer them) and test a restore once. On Base44, below the Elite plan, you had no automatic backups at all, so this is often an improvement.
• Monitoring. Set up uptime checks and look at logs when something feels slow.
• Security. Keep secrets in your host’s secret settings, restrict who has access to your accounts, and review your app’s access rules.
• Capacity. If traffic grows, resize the server or database. It’s a setting, not a support ticket.

For most owners the right balance is a managed host: you own the accounts and the code, and the provider handles the machines.