Práticas recomendadas gerais para configurar projetos do Firebase
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Nesta página, apresentamos as práticas recomendadas gerais de alto nível para configurar
projetos do Firebase e registrar apps em um projeto para ter um
fluxo de desenvolvimento claro usando ambientes
diferentes. Quando você se familiarizar com as práticas recomendadas nesta página,
confira nossas
diretrizes gerais de segurança.
Noções básicas sobre a hierarquia dos projetos do Firebase
Nesse diagrama, nós mostramos a hierarquia básica de um projeto do Firebase. Estas são as principais
relações:
Um projeto do Firebase é como um contêiner para todos os apps, recursos
e serviços provisionados para o projeto.
Um projeto do Firebase pode ter um ou mais apps registrados nele.
Por exemplo, as versões para iOS e Android de um aplicativo, ou as versões sem custos financeiros
e pagas.
Todos os apps do Firebase registrados no mesmo projeto compartilham e têm
acesso aos mesmos recursos e serviços provisionados para o projeto.
Veja alguns exemplos:
Todos os apps do Firebase registrados no mesmo projeto do Firebase compartilham os mesmos
back-ends, como Firebase Hosting, Authentication, Realtime Database, Cloud Firestore,
Cloud Storage e Cloud Functions.
Todos os apps registrados em um projeto do Firebase são associados
à mesma propriedade do Google Analytics. Nessa propriedade, cada app do Firebase é um
fluxo de dados separado.
Onde um projeto Google Cloud se encaixa nessa hierarquia?
Um aspecto da hierarquia de projetos do Firebase que não é mostrado no diagrama
acima é a relação com um projeto do Google Cloud. Um projeto do Firebase é
apenas um projeto do Google Cloud que tem mais configurações
e serviços específicos do Firebase ativados para ele.
Observe que todos os apps registrados em um projeto do Firebase também compartilham e
têm acesso aos mesmos recursos e serviços do Google Cloud.
Como registrar variantes de apps com projetos do Firebase
Veja algumas dicas importantes para registrar as variantes do app em um projeto
do Firebase:
Verifique se todos os apps registrados em um projeto do Firebase são variantes de plataforma
do mesmo aplicativo, do ponto de vista do usuário final. Registre as versões para iOS,
Android e Web de um app ou jogo com o mesmo projeto do
Firebase.
Se você tiver muitas variantes de build que podem compartilhar os mesmos recursos
do Firebase, registre as variantes com o mesmo projeto do Firebase. Alguns
exemplos são um blog e um app da Web em um projeto ou as versões com e sem ônus financeiro
de um app no mesmo projeto.
Se você tiver muitas variantes de build baseadas no status de lançamento
e não em atividades comuns dos usuários finais ou no acesso, como visto acima, registre cada uma
com um projeto diferente do Firebase. Um exemplo é o build de depuração versus
de lançamento. Registre cada um no próprio projeto do Firebase.
Os builds com base no status de lançamento não devem compartilhar os mesmos recursos do Firebase
porque isso pode causar a poluição e até mesmo a substituição dos dados de produção pelos
dados de depuração.
As variantes de plataforma de cada variante de build precisam estar no
mesmo projeto do Firebase. Por exemplo, registre os builds de depuração do iOS e
do Android em um projeto de "dev" do Firebase, porque ambos podem interagir com
os mesmos dados e recursos não relacionados à produção.
Como evitar a multilocação
A multilocação pode levar a sérios problemas de configuração e privacidade de dados,
incluindo aqueles não intencionais com agregação de análise, autenticação compartilhada,
estruturas de banco de dados complexas demais e dificuldades com regras de segurança.
Geralmente, se um conjunto de apps não compartilhar os mesmos dados e configurações,
registre cada app a um projeto diferente do Firebase.
Por exemplo, quando você desenvolve um aplicativo de marca branca, cada app marcado
de maneira independente precisa ter o próprio projeto do Firebase. Também é necessário que as versões
para iOs e Android dessa marca estejam nesse mesmo projeto. Por motivos de privacidade,
um app marcado de maneira independente não pode compartilhar dados com
os outros.
Próximas etapas
Veja as
diretrizes gerais de segurança
para diferentes ambientes. Você quer garantir segurança a cada ambiente e aos
dados dele.
[null,null,["Última atualização 2025-08-04 UTC."],[],[],null,["This page provides general, high-level best practices for setting up Firebase\nprojects and registering your apps with a project so that you have a clear\n[development workflow](/docs/projects/dev-workflows/overview-environments) that\nuse distinct environments. Once you're familiar with the best practices on this\npage, check out our\n[general security guidelines](/docs/projects/dev-workflows/general-security-guidelines).\n| **Key Point:** We recommend reading our guides thoroughly, but here's the top takeaway about development workflows: \n| **Firebase recommends using a *separate* Firebase project for *each* environment\n| in your development workflow.**\n\nUnderstanding the hierarchy of Firebase projects\n\n\nThis diagram shows the basic hierarchy of a Firebase project. Here are the key\nrelationships:\n\n- A **Firebase project** is like a container for all your apps and any resources\n and services provisioned for the project.\n\n- A Firebase project can have one or more **Firebase Apps** registered to it\n (for example, both the iOS and Android versions of an app, or both the free\n and paid versions of an app).\n\n- All Firebase Apps registered to the same Firebase project **share and have\n access to all the same resources and services provisioned for the project**.\n Here are some examples:\n\n - All the Firebase Apps registered to the same Firebase project share the same\n backends, like Firebase Hosting, Authentication, Realtime Database, Cloud Firestore,\n Cloud Storage, and Cloud Functions.\n\n - All Firebase Apps registered to the same Firebase project are associated\n with the same Google Analytics property, where each Firebase App is a\n separate data stream in that property.\n\nWhere does a Google Cloud project fit into this hierarchy?\n\nOne aspect of the Firebase project hierarchy that's not shown in the diagram\nabove is the relationship with a Google Cloud project. **A Firebase project is\nactually just a Google Cloud project that has additional *Firebase-specific*\nconfigurations and services enabled for it.**\nNote that all the apps registered to the same Firebase project also share and\nhave access to all the same Google Cloud resources and services, too.\n\nLearn more about the Firebase and Google Cloud relationship in\n[Understand Firebase projects](/docs/projects/learn-more#firebase-cloud-relationship)\n\nRegistering app variants with Firebase projects **Key Point:** All the apps registered to a Firebase project share and can access the same data as well as the resources and services provisioned for the project, which includes database instances, storage buckets, functions, etc.\n\nHere are some important tips for registering your app variants with a Firebase\nproject:\n\n- Ensure that all apps registered to a Firebase project are **platform variants\n of the same application** from an end-user perspective. Register the iOS,\n Android, and web versions of the same app or game with the *same* Firebase\n project.\n\n- If you have **multiple build variants that could *share the same Firebase\n resources*** , register the variants with the *same* Firebase project. Some\n examples are a blog and a web app in the same project, or both the free and\n paid versions of the same app in the same project.\n\n- If you have **multiple build variants that are *based on release status***\n (rather than on common end-user activity or access, like above), register each\n variant with a *separate* Firebase project. An example is your debug vs\n release build -- register each of these builds in its own Firebase project.\n\n - Builds based on release status should not share the same Firebase resources\n because that risks your debug data polluting or even overriding your prod\n data.\n\n - The *platform* -variants of each of these build variants should be in the\n *same* Firebase project. For example, register both the iOS and the Android\n debug builds in a \"dev\" Firebase project because they can both interact with\n the same non-prod data and resources.\n\n| **Note:** For each Android app, if you provide a SHA-1 key for the app, you need to provide a package name and SHA-1 key combination that is globally unique across all of Google Cloud.\n\nAvoiding multi-tenancy **Key Point:** Connecting several different logically independent apps and/or web sites to a single Firebase project (often called \"multi-tenancy\") is not recommended.\n\nMulti-tenancy can lead to serious configuration and data privacy concerns,\nincluding unintended issues with analytics aggregation, shared authentication,\noverly-complex database structures, and difficulties with security rules.\n\nGenerally, **if a set of apps don't share the same data and configurations,\nstrongly consider registering each app with a different Firebase project.**\n\nFor example, if you develop a white-label application, each independently\nlabeled app should have its own Firebase project, and the iOS and Android\nversions of that label should be in the same Firebase project. Each\nindependently labeled app shouldn't (for privacy reasons) share data with the\nothers.\n\nNext steps\n\n- Review the\n [general security guidelines](/docs/projects/dev-workflows/general-security-guidelines)\n for different environments. You want to make sure each environment and its\n data are secure.\n\n- Review the [Firebase launch checklist](/support/guides/launch-checklist)."]]
Nesse diagrama, nós mostramos a hierarquia básica de um projeto do Firebase. Estas são as principais
relações: