Join us in person and online for Firebase Summit on October 18, 2022. Learn how Firebase can help you accelerate app development, release your app with confidence, and scale with ease. Register now

Connect your app to the Cloud Storage Emulator

Stay organized with collections Save and categorize content based on your preferences.

Before connecting your app to the Cloud Storage emulator, make sure that you understand the overall Firebase Local Emulator Suite workflow, and that you install and configure the Local Emulator Suite and review its CLI commands.

Choose a Firebase project

The Firebase Local Emulator Suite emulates products for a single Firebase project.

To select the project to use, before you start the emulators, in the CLI run firebase use in your working directory. Or, you can pass the --project flag to each emulator command.

Local Emulator Suite supports emulation of real Firebase projects and demo projects.

Project type Features Use with emulators

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.).


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.

We recommend you use demo projects wherever possible. Benefits include:

  • Easier setup, since you can run the emulators without ever creating a Firebase project
  • Stronger safety, since if your code accidentally invokes non-emulated (production) resources, there is no chance of data change, usage and billing
  • Better offline support, since there is no need to access the internet to download your SDK configuration.

Instrument your app to talk to the emulators

Android, Apple platforms, and Web SDKs

Set up your in-app configuration or test classes to interact with the Cloud Storage emulator as follows.

FirebaseStorage.getInstance().useEmulator("", 9199);
Swift"localhost", port:9199)
Web v8
var storage =;
storage.useEmulator("localhost", 9199);
Web v9
import { getStorage, connectStorageEmulator } from "firebase/storage";

const storage = getStorage();
connectStorageEmulator(storage, "localhost", 9199);

No additional setup is needed to test Cloud functions triggered by Cloud Storage events using the emulator. When the Cloud Storage and Cloud Functions emulators are both running, they automatically work together.

Admin SDKs

The Firebase Admin SDKs automatically connect to the Cloud Storage emulator when the FIREBASE_STORAGE_EMULATOR_HOST environment variable is set:

export FIREBASE_STORAGE_EMULATOR_HOST="localhost:9199"

Note that the Cloud Functions emulator is automatically aware of the Cloud Storage emulator so you can skip this step when testing integrations between Cloud Functions and Cloud Storage emulators. The environment variable will be automatically set for the Admin SDK in Cloud Storage.

If you want your Admin SDK code to connect to a shared emulator running in another environment, you will need to specify the the same project ID you set using the Firebase CLI. You can pass a project ID to initializeApp directly or set the GCLOUD_PROJECT environment variable.

Node.js Admin SDK
admin.initializeApp({ projectId: "your-project-id" });
Environment Variable
export GCLOUD_PROJECT="your-project-id"

Import and export data

The database and Cloud Storage emulators allow you to export data from a running emulator instance. Define a baseline set of data to use in your unit tests or continuous integration workflows, then export it to be shared among the team.

firebase emulators:export ./dir

In tests, on emulator startup, import the baseline data.

firebase emulators:start --import=./dir

You can instruct the emulator to export data on shutdown, either specifying an export path or simply using the path passed to the --import flag.

firebase emulators:start --import=./dir --export-on-exit

These data import and export options work with the firebase emulators:exec command as well. For more, refer to the emulator command reference.

How the Cloud Storage emulator differs from production

For testing of client apps, the Cloud Storage emulator aligns to production almost perfectly in regards to the Firebase API surface area. All Firebase commands are expected to work between the regular Firebase SDKs (Web, Android, and Apple platforms).

For testing of server-side apps, limitations exist. The Firebase Admin SDKs make use the Google Cloud API surface, and not all endpoints of this API are emulated. As a rule of thumb, anything which can be done from the client SDKs (uploading or deleting files, getting and setting metadata) is also implemented for use from the Admin SDKs, but anything beyond that is not. Notable exclusions are listed below.

Cloud IAM

The Firebase Emulator Suite does not attempt to replicate or respect any IAM-related behavior for running. Emulators adhere to the Firebase Security Rules provided, but in situations where IAM would normally be used, for example to set Cloud Functions invoking service account and thus permissions, the emulator is not configurable and will use the globally-available account on your developer machine, similar to running a local script directly.

Pub/Sub notifications

The Cloud Storage emulator does not integrate with the Cloud Pub/Sub emulator and thus does not support creating channels/notifications for storage object changes. We recommend using Cloud Functions Storage triggers directly.

Bucket-level metadata

The Cloud Storage emulator does not support any bucket-level configuration including storage class, bucket-level CORS configuration, labels, or retention policies. Firebase intends to improve this support over time.

What next?