Prácticas recomendadas generales para configurar proyectos de Firebase
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se proporcionan prácticas recomendadas generales de nivel global para configurar proyectos
de Firebase y registrar tus apps en un proyecto, de modo que tengas un
flujo de trabajo de desarrollo
claro con entornos distintos. Una vez que te familiarices con las prácticas recomendadas de esta página, consulta nuestros
lineamientos generales de seguridad.
Comprende la jerarquía de los proyectos de Firebase
En este diagrama, se muestra la jerarquía básica de un proyecto de Firebase. Las siguientes son las relaciones
clave:
Un proyecto de Firebase es como el contenedor de todas tus apps y todos los recursos
y servicios aprovisionados para el proyecto.
Un proyecto de Firebase puede tener una o más apps de Firebase registradas
(por ejemplo, las versiones de iOS y Android de una app, o las versiones gratuita
y pagada).
Todas las apps de Firebase registradas en el mismo proyecto de Firebase comparten y tienen
acceso a los mismos recursos y servicios aprovisionados para el proyecto.
Estos son algunos ejemplos:
Todas las apps de Firebase registradas en el mismo proyecto de Firebase comparten los mismos
backends, como Firebase Hosting, Authentication, Realtime Database, Cloud Firestore,
Cloud Storage y Cloud Functions.
Todas las apps de Firebase registradas en un mismo proyecto de Firebase se asocian
con la misma propiedad de Google Analytics, en la que cada app de Firebase es un
flujo de datos independiente en esa propiedad.
¿Dónde se ubica un proyecto de Google Cloud en esta jerarquía?
Un aspecto de la jerarquía de proyectos de Firebase que no se muestra en el diagrama
anterior es la relación con un proyecto de Google Cloud. Un proyecto de Firebase es,
en realidad, un proyecto de Google Cloud que tiene habilitados parámetros de configuración y servicios
adicionales específicos de Firebase.
Ten en cuenta que todas las apps registradas en el mismo proyecto de Firebase también comparten
los mismos recursos y servicios de Google Cloud y tienen acceso a ellos.
Registra variantes de apps con proyectos de Firebase
Estas son algunas sugerencias importantes para registrar las variantes de tu app en un proyecto de
Firebase:
Asegúrate de que todas las apps registradas en un proyecto de Firebase sean variantes de plataforma
de la misma aplicación desde la perspectiva del usuario final. Registra las versiones de iOS,
Android y web de la misma app o juego con el mismo proyecto de
Firebase.
Si tienes múltiples variantes de compilación que podrían compartir los mismos recursos de
Firebase, registra las variantes con el mismo proyecto de Firebase. Algunos
ejemplos son un blog y una aplicación web en el mismo proyecto o las versiones gratuitas y
pagadas de la misma app en el mismo proyecto.
Si tienes múltiples variantes de compilación basadas en el estado de la versión
(en lugar de la actividad o el acceso comunes del usuario final, como se muestra más arriba), registra cada
variante en un proyecto de Firebase independiente. Un ejemplo es la compilación de depuración frente
a la de lanzamiento. Registra cada una de ellas en su propio proyecto de Firebase.
Las compilaciones basadas en estados de actualización no deben compartir los mismos recursos de Firebase,
ya que eso podría contaminar los datos de depuración o incluso anular tus
datos de producción.
Las variantes de platform de cada una de estas variantes de compilación deben estar en el
mismo proyecto de Firebase. Por ejemplo, registra las compilaciones de depuración de iOS y Android
en un proyecto de Firebase “dev”, ya que ambos pueden interactuar con
los mismos datos y recursos que no son de producción.
Evita la arquitectura multiusuario
Esta modalidad puede generar problemas graves de configuración y privacidad de los datos,
incluidos algunos no intencionales relacionados con agregación de estadísticas, autenticación compartida,
estructuras de bases de datos demasiado complejas y dificultades con las reglas de seguridad.
Por lo general, si un conjunto de apps no comparte los mismos datos y parámetros de configuración,
te recomendamos que registres cada app en un proyecto de Firebase diferente.
Por ejemplo, si desarrollas una aplicación sin marca, cada app etiquetada de forma independiente
debe tener su propio proyecto de Firebase, y las versiones de iOS y Android
de esa etiqueta deben estar en el mismo proyecto de Firebase. Por motivos de privacidad,
las apps etiquetadas de forma independiente no deben compartir datos con las
demás.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-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)."]]
En este diagrama, se muestra la jerarquía básica de un proyecto de Firebase. Las siguientes son las relaciones
clave: