Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.base44.com/llms.txt

Use this file to discover all available pages before exploring further.

Local development lets you run your backend project on your own machine so you can test changes instantly, inspect data without affecting production, and catch issues before deploying. See Setup for prerequisites and step-by-step instructions.

​
What runs locally

The dev server handles these features entirely on your machine:
  • Functions: Backend functions run locally with automatic reload on file changes.
  • Entities: Entity data is stored in a local in-memory database. Schema changes are picked up automatically.
  • Media: File uploads are saved locally.
  • Authentication: Email/password registration and login run locally.
Function automations don’t run locally.

​
What’s forwarded

Some features aren’t handled locally yet. When the dev server receives a request it can’t serve, it forwards it to your deployed app so the call still works. The server logs a warning each time this happens. Forwarded features include:
  • Authentication: OAuth and social login routes are redirected to Base44 so session cookies work correctly. Email/password auth runs locally.
  • Core integrations: Endpoints like SendEmail or AI generation are forwarded. File uploads are the exception and run locally.
  • Custom integrations: API calls configured through OpenAPI specifications.
This means your app continues to work end-to-end during development. Features that run locally use local data, and everything else uses production.

​
Functions

Backend functions run locally on your machine. You can call them from your frontend just like deployed functions.
  • Each function runs as a separate Deno process, which must be installed separately.
  • Functions reload automatically when you edit the source code.
  • Function output is printed directly to your terminal. You don’t need to use base44 logs during local development.
When a request reaches the dev server and is proxied to your local Deno function, the server may add or normalize headers so your function sees the same shape of context as in production:
  • Base44-App-Id: Set from the incoming X-App-Id header when it is present.
  • Base44-Service-Authorization: Set from the incoming Authorization header when it is present, so code that reads the service authorization header locally matches deployed behavior.
  • Base44-Api-Url: Set to your dev server base URL (scheme and host), so functions can build callbacks or absolute URLs against the local server.
The original Authorization header is still forwarded unchanged.
The first request to a function may be slower because the dev server starts the process on demand. Subsequent requests reuse the running process.

​
Entities

Entity operations go to a local in-memory database instead of the remote database. This lets you create, read, update, and delete records without affecting your production data.
  • All data is stored in memory and is cleared when you stop the dev server.
  • Schema changes are picked up automatically. Changing an entity schema clears all in-memory data for that entity.
  • Realtime subscriptions work locally. If your frontend uses entities.subscribe(), it receives events for local entity changes.
  • The User entity runs locally. On startup, the dev server seeds a single user record using your authenticated CLI credentials. Read and update operations on me work as they do in production. Requests to create or delete users are silently ignored, matching production behavior where direct user management is not permitted.

​
Media

File uploads are handled locally so you can test media features without uploading to production storage. Files are saved to a temporary directory and cleaned up when the dev server stops. The maximum file size is 50 MB.

​
Authentication

Email/password registration and login run locally when your app uses the built-in auth system. OAuth and social login routes are redirected to Base44. To register a new user during development using email/password auth:
  1. Call the register endpoint. The dev server prints a one-time verification code to your terminal instead of sending an email.
  2. Submit the code to the verify-OTP endpoint to confirm the address and create the user.
  3. Log in with the registered email and password.
Your developer account (the email you used for base44 login) can log in with any password, no registration required.
Tokens issued by the local dev server are only valid locally. They are signed with a different secret than production, so your deployed app will reject them. When you switch from local development to your deployed app, first sign out of your local session or delete your tokens from your local browser storage. Then, log back in through the deployed app to get a valid token.

​
See also