[null,null,["อัปเดตล่าสุด 2025-07-25 UTC"],[],[],null,["\u003cbr /\u003e\n\nBefore you start prototyping and testing your web app with the\nFirebase Hosting emulator, make sure that you [understand the overall Firebase Local Emulator Suite workflow](/docs/emulator-suite/connect_and_prototype?database=Firestore),\nand that you [install and configure](/docs/emulator-suite/install_and_configure)\nthe Local Emulator Suite and review its [CLI commands](/docs/emulator-suite/install_and_configure#startup).\n\nYou should also be familiar with the features and implementation workflow\nfor Firebase Hosting. Start with the\n[introduction to Firebase Hosting](/docs/hosting).\n\nWhat can I do with the Firebase Hosting emulator?\n\nThe Firebase Hosting emulator provides high-fidelity local emulation of\nHosting services, providing much of the functionality found in\n[production Hosting](/docs/hosting/quickstart). The Hosting emulator\nlets you:\n\n- Prototype your static sites and web apps without incurring storage or access charges\n- Prototype, test and debug HTTPS functions before deploying to your Hosting site\n- Test sites and web apps in containerized, continuous integration workflows.\n\nChoose a Firebase project\n\nThe Firebase Local Emulator Suite emulates products for a single Firebase project.\n\nTo select the project to use, before you start the emulators, in the CLI run\n`firebase use` in your working directory. Or, you can pass\nthe `--project` flag to each emulator\ncommand.\n| **Note:** It's generally a good practice to use one project ID for all emulator invocations, so the Emulator Suite UI, different product emulators, and all running instances of a particular emulator can communicate correctly in all cases. In fact, by default, the Local Emulator Suite will warn on detecting multiple project IDs in use, though you can override this behavior. For guidance on setting and managing project IDs, see the [Installation and configuration guide](/docs/emulator-suite/install_and_configure#project_id_configuration).\n\nLocal Emulator Suite supports emulation of *real* Firebase projects and\n*demo* projects.\n\n| Project type | Features | Use with emulators |\n|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Real | A real Firebase project is one you created and configured (most likely via the Firebase console). Real projects have live resources, like database instances, storage buckets, functions, or any other resource you set up for that Firebase project. | When working with real Firebase projects, you can run emulators for any or all of the supported products. For any products you are not emulating, your apps and code will interact with the *live* resource (database instance, storage bucket, function, etc.). |\n| Demo | A demo Firebase project has no *real* Firebase configuration and no live resources. These projects are usually accessed via codelabs or other tutorials. Project IDs for demo projects have the `demo-` prefix. | When working with demo Firebase projects, your apps and code interact with emulators *only*. If your app attempts to interact with a resource for which an emulator isn't running, that code will fail. |\n\nWe recommend you use demo projects wherever possible. Benefits include:\n\n- Easier setup, since you can run the emulators without ever creating a Firebase project\n- Stronger safety, since if your code accidentally invokes non-emulated (production) resources, there is no chance of data change, usage and billing\n- Better offline support, since there is no need to access the internet to download your SDK configuration.\n\n| **Note:** If you want to emulate cross-service interactions such as database-triggered Cloud Functions or Rules that rely on Authentication you must make sure that the project ID in your code (in `initializeApp()`, etc.) matches the project ID used by the Firebase CLI.\n\nCore prototyping workflow\n\nIf you're making quick iterations or you want your app to interact with\nemulated backend project resources, you can test your Hosting content and\nconfig locally. When testing locally, Firebase serves your web app at a locally\nhosted URL.\n\n1. *(Optional)* By default, your locally hosted app will interact with *real* ,\n not *emulated* , project resources (functions, database, rules, etc.).\n You can instead optionally connect your app to use any *emulated* project\n resources that you've configured. Learn more:\n [Realtime Database](/docs/emulator-suite/connect_and_prototype?database=RTDB) \\|\n [Cloud Firestore](/docs/emulator-suite/connect_and_prototype?database=Firestore) \\|\n [Cloud Functions](/docs/emulator-suite/connect_functions)\n\n2. From the root of your local project directory, run the following command:\n\n ```\n firebase emulators:start\n ```\n3. Open your web app at the local URL returned by the CLI (usually\n `http://localhost:5000`).\n\n4. To update the local URL with changes, refresh your browser.\n\nTest from other local devices\n\nBy default, the emulators only respond to requests from `localhost`. This\nmeans that you'll be able to access your hosted content from your computer's web\nbrowser but not from other devices on your network. If you'd like to test from\nother local devices, configure your `firebase.json` like so: \n\n \"emulators\": {\n // ...\n\n \"hosting\": {\n \"port\": 5000,\n \"host\": \"0.0.0.0\"\n }\n }\n\nGenerate auth tokens for continuous integration workflows\n\nIf your continuous integration workflows rely on Firebase Hosting, then you will\nneed to log in using a token in order to run `firebase emulators:exec`. The\nother emulators do not require login.\n| **Note:** If you have configured hosting in `firebase.json` but do not need it in CI test setups, use the `--only` flag to `emulators:start` or `emulators:exec` to include only the emulators that you need.\n\nTo generate a token, run `firebase login:ci` on your local environment; this\nshould not be performed from a CI system. Follow instructions to authenticate.\nYou should only need to perform this step once per project, since the token will\nbe valid across builds. The token should be treated like a password; make sure\nit is kept secret.\n\nIf your CI environment allows you to specify environment variables that can be\nused in the build scripts, simply create an environment variable called\n`FIREBASE_TOKEN`, with the value being the access token string. The\nFirebase CLI will automatically pick up the `FIREBASE_TOKEN` environment\nvariable and the emulators will start properly.\n\nAs a last resort, you can simply include the token in your build script, but\nmake sure that untrusted parties do not have access. For this hard-coded\napproach, you can add `--token \"YOUR_TOKEN_STRING_HERE\"` to the\n`firebase emulators:exec` command.\n\nWhat next?\n\n- Run a quickstart using the Hosting emulator by following the [Firebase web\n codelab](/codelabs/firebase-web).\n- Understand how to prototype HTTPS functions using the Hosting emulator as described in the [Hosting guides for functions](/docs/hosting/functions).\n- For a curated set of videos and detailed how-to examples, follow the [Firebase Emulators Training Playlist](/learn/pathways/firebase-emulators)."]]
