Understanding the hierarchy of Firebase projects

This diagram shows the basic hierarchy of a Firebase project. Here are the keyrelationships:

• AFirebase project is like a container for all your apps and any resourcesand services provisioned for the project.

• A Firebase project can have one or moreFirebase Apps registered to it(for example, both the iOS and Android versions of an app, or both the freeand paid versions of an app).

• All Firebase Apps registered to the same Firebase projectshare and haveaccess to all the same resources and services provisioned for the project.Here are some examples:

  • All the Firebase Apps registered to the same Firebase project share the samebackends, likeFirebase Hosting,Authentication,Realtime Database,Cloud Firestore,Cloud Storage, andCloud Functions.

  • All Firebase Apps registered to the same Firebase project are associatedwith the same Google Analytics property, where each Firebase App is aseparate data stream in that property.

Where does aGoogle Cloud project fit into this hierarchy?

One aspect of the Firebase project hierarchy that's not shown in the diagramabove is the relationship with aGoogle Cloud project.A Firebase project isactually just aGoogle Cloud project that has additionalFirebase-specificconfigurations and services enabled for it.Note that all the apps registered to the same Firebase project also share andhave access to all the sameGoogle Cloud resources and services, too.

Here are some important tips for registering your app variants with a Firebaseproject:

• Ensure that all apps registered to a Firebase project areplatform variantsof the same application from an end-user perspective. Register the iOS,Android, and web versions of the same app or game with thesame Firebaseproject.

• If you havemultiple build variants that couldshare the same Firebaseresources, register the variants with thesame Firebase project. Someexamples are a blog and a web app in the same project, or both the free andpaid versions of the same app in the same project.

• If you havemultiple build variants that arebased on release status(rather than on common end-user activity or access, like above), register eachvariant with aseparate Firebase project. An example is your debug vsrelease build – register each of these builds in its own Firebase project.

  • Builds based on release status should not share the same Firebase resourcesbecause that risks your debug data polluting or even overriding your proddata.

  • Theplatform-variants of each of these build variants should be in thesame Firebase project. For example, register both the iOS and the Androiddebug builds in a "dev" Firebase project because they can both interact withthe same non-prod data and resources.

Avoiding multi-tenancy

Multi-tenancy can lead to serious configuration and data privacy concerns,including unintended issues with analytics aggregation, shared authentication,overly-complex database structures, and difficulties with security rules.

Generally,if a set of apps don't share the same data and configurations,strongly consider registering each app with a different Firebase project.

For example, if you develop a white-label application, each independentlylabeled app should have its own Firebase project, and the iOS and Androidversions of that label should be in the same Firebase project. Eachindependently labeled app shouldn't (for privacy reasons) share data with theothers.

Next steps