Overview
Choose how to run Localess — Docker to try it, local emulators to develop against it, or Firebase to run it in production.
Localess runs the same way everywhere: a web app, Firestore for content, Cloud Functions for the API, and Cloud Storage for assets. What changes between these three is where that stack runs and how much of it you have to set up yourself.
Pick by what you're trying to do.
Docker
Trying it out. One compose.yaml, no cloud account, no repository clone. The fastest path to a running instance you can click around in.
Local Run
Developing against it. Clone the repo and run the Firebase emulators, so you can change Localess itself or build an integration against a instance you control.
Firebase
Running it for real. The recommended production deployment, on Google Cloud, deployed through Cloud Build.
Which one do I want?
| Docker | Local Run | Firebase | |
|---|---|---|---|
| Best for | Previewing features | Developing and contributing | Production |
| Google Cloud account | Not needed | Not needed | Required |
| Repository clone | Not needed | Required | Required |
| Data persistence | Local volume | Emulator state | Firestore |
| Survives a restart | Yes, via the volume | Emulator-dependent | Yes |
| Public URL | No | No | Yes, on Firebase Hosting |
Notes before you start
Docker and Local Run are not production setups. Both are designed for a single machine and a single user — there is no scaling story, no managed backups, and no CDN in front of your assets. Use Firebase for anything real.
Content does not transfer between them automatically. Each setup has its own storage, so a space you build under Docker is not the space you get on Firebase. Use the CLI to move schemas and translations between instances, and the import/export tools for content.
You need a running instance before the SDKs are useful. Once one is up, Getting Started walks through creating your first space and pulling content into an app, and the framework guides cover the integration itself.