How to run a Base44 app locally, and what still runs on Base44

The short version

Yes, you can run a Base44 app on your own machine, in two ways that Base44 documents:

• Run the exported code with npm install and npm run dev. The interface runs on your machine, but every record, sign-in, function and integration call still goes to Base44’s servers, using your live data.
• Run the Base44 CLI’s dev server with base44 dev. Backend functions, records, uploads and email-and-password sign-in run on your machine, with records in a temporary in-memory database. Google and other social sign-ins, email sending and AI calls are forwarded to your app on Base44, and automations don’t run.

Both are tools for developing a Base44 app. Neither runs the app without Base44, and as of October 2026 Base44’s documentation doesn’t mention Docker at all. To run the whole app on your machine, including its server and its database, the app needs a backend of its own. An app moved with Unbase44 runs locally with one command, docker compose up.

Free tool: the Base44 export checker reads your export in the browser and lists everything that still runs on Base44’s servers. Nothing is uploaded.

What runs where

Option 1: run the exported code against Base44

This is what most people try first. Get the code out of Base44, either as a ZIP from the Code tab or through two-way GitHub sync (both need the Builder plan or higher, per Base44’s developer tools page). Then, in the project folder:

npm install
npm run dev

Base44’s project structure docs give exactly these two commands. The project is a standard React app built with Vite, and its src/api folder holds the Base44 SDK client that talks to your backend.

What you see is your app’s interface running on your machine and talking to Base44’s hosted backend. The data is your live data: anything you create, edit or delete is real, and any email or automation it triggers goes out for real. It’s useful for working on layout and pages. It isn’t a safe place to test changes to data, and it stops working if the app on Base44 does.

Our guide to exporting from Base44 explains what the ZIP and GitHub sync contain, and what they leave behind.

Option 2: the Base44 dev server

Base44’s CLI includes a local development server. It’s the closest Base44 gets to running an app on your own machine, and it’s built for developers testing changes.

What you need

• Node.js 20.19.0 or higher, which the CLI requires.
• Deno, if your app has backend functions. Base44 runs each function as a separate Deno process, and Deno is installed separately.
• A local copy of the app. Base44’s GitHub integration docs describe the setup for a GitHub-synced app, which needs the Builder plan or higher.

Steps for a GitHub-synced app

From Base44’s GitHub integration docs:

git clone <your repository URL>
cd <your project>
npm install
npm install -g base44@latest
base44 login
base44 link
base44 dev

base44 login signs you in with a device code, and base44 link connects the clone to its app on Base44 (every fresh clone needs this step). base44 dev starts a local backend at http://localhost:4400 and your frontend’s dev server alongside it, in one terminal. Ctrl-C stops both.

What runs locally, and what doesn’t

Base44’s local development overview is precise about this:

• Functions run on your machine and reload when you edit them; their output prints in your terminal.
• Records live in an in-memory database. It starts empty and is cleared when you stop the server, and changing a table’s schema clears that table’s local data.
• Uploads are saved to a temporary folder and deleted when the server stops, up to 50 MB per file.
• Email-and-password sign-in runs locally. A new user’s verification code prints in your terminal instead of being emailed, and your own developer account can sign in with any password.
• Forwarded to Base44: Google and other social sign-ins, built-in integrations such as sending email and AI generation, and custom integrations.
• Automations don’t run locally.

Two warnings from the same docs. Sign-in tokens from the local server only work locally, so sign out before you switch back to your live app. And base44 dev --remote, which serves your frontend against the live backend, writes to your production data.

Other Base44 options

• base44 scaffold sets up local files for an app’s backend (tables, functions, agents) while the frontend stays in Base44’s editor. Base44 suggests it if you don’t have the plan for GitHub sync.
• base44 eject copies an app into a new, separate Base44 project with its own app ID and an empty database. Your original app is untouched, and the two are independent from then on. The copy is still hosted by Base44.
• The cloud sandbox lets you or your own coding agent work on the app’s code where Base44 keeps it, with no local copy. It needs the Builder plan or higher.

Can you run a Base44 app in Docker?

Not as a whole app. Base44 doesn’t describe a Docker image or a Docker setup for its backend anywhere in its documentation, and it doesn’t document a self-hosted edition. You can put the exported frontend in a container like any other Vite app, but the container would still call Base44’s servers for everything behind the interface.

People search for “Base44 Docker Compose” because they want what Compose usually gives you: the app, its server and its database starting together with one command, anywhere. For a Base44 app, that needs a backend that answers the same calls Base44 does. Our guide to self-hosting a Base44 app explains why, and what the options are.

Staging: testing changes before your users see them

On Base44

Base44’s closest feature to a staging environment is Test Data (Testing your app with test data), on the Builder plan and higher:

• Turning it on creates a separate test database. It starts empty; your production data isn’t copied into it.
• In the dashboard and in preview, you switch between production and test data.
• A testing link lets teammates or clients try unpublished changes against test data.
• Your published app always uses production data. Test mode only affects the dashboard and preview.

For code changes, GitHub sync gives you branches and pull requests. Changes reach Base44 when they’re merged into main, and go live when you click Publish. The local dev server adds a private sandbox on your own machine.

After a migration

Before you switch over, the migrated copy is already a kind of staging copy. It starts in test mode: your Base44 app keeps serving users, and the copy runs no automations or workflows and holds anything it would send out (emails, texts, notifications, payments, changes to other services), logging each one instead. You click through it with your real data, and nothing reaches your customers.

After you switch, the repository is yours, so staging works however your host does it. On Railway, pushing to the repository’s main branch deploys the app. Railway’s environments let a project keep a separate staging environment, commonly deploying from a staging branch, and can create temporary environments for pull requests. On your own server, a second copy can run on a second machine.

Running a migrated app entirely on your machine

When Unbase44 moves an app, everything goes into a private repository in your GitHub account: your React frontend, a Base44-compatible backend written in Deno and TypeScript, the Docker files, and documentation for people and for coding agents, including a local development guide (docs/LOCAL_DEVELOPMENT.md), a README, AGENTS.md and CLAUDE.md.

To run it on your machine:

1. Install Docker. On a Mac or Windows PC, that’s usually Docker Desktop.
2. Clone your repository.
3. In its folder, run:

docker compose up

That starts the app and its database on your machine. The server answering your app’s calls is the one in your repository, not Base44’s, so you can change a function, a table or a page and see the result locally before you push. Email and AI go through the providers you set up: your own Resend account or SMTP server, and your own OpenRouter, OpenAI, Anthropic or Gemini key.

Because AGENTS.md and CLAUDE.md are written for coding agents, Claude Code, Cursor or another agent can read how to start the app and work on it. On Railway, pushing to main then deploys your change.

Which one do you need?

• You want to tweak pages and layout and you’re staying on Base44: export the code and run npm run dev, carefully, since it uses live data.
• You’re a developer changing backend functions or tables on Base44: use base44 dev, and Test Data for anything your client needs to try.
• You want the whole app, including server and database, on your machine or your own server: the app needs a backend of its own. Unbase44 moves it to one; the analysis is free and shows what’s in your app and the price before you connect anything or pay.