Allgemeine Best Practices für die Einrichtung von Firebase-Projekten
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite finden Sie allgemeine Best Practices für die Einrichtung von Firebase-Projekten und die Registrierung Ihrer Apps bei einem Projekt. So haben Sie einen klaren Entwicklungsablauf mit verschiedenen Umgebungen. Wenn Sie mit den Best Practices auf dieser Seite vertraut sind, lesen Sie unsere allgemeinen Sicherheitsrichtlinien.
Hierarchie von Firebase-Projekten
Dieses Diagramm zeigt die grundlegende Hierarchie eines Firebase-Projekts. Hier sind die wichtigsten Beziehungen:
Ein Firebase-Projekt ist wie ein Container für alle Ihre Apps und alle für das Projekt bereitgestellten Ressourcen und Dienste.
Bei einem Firebase-Projekt können eine oder mehrere Firebase-Apps registriert sein, z. B. sowohl die iOS- als auch die Android-Version einer App oder sowohl die kostenlose als auch die kostenpflichtige Version einer App.
Alle Firebase-Apps, die für dasselbe Firebase-Projekt registriert sind, teilen sich die für das Projekt bereitgestellten Ressourcen und Dienste und haben Zugriff darauf.
Hier sind einige Beispiele:
Alle Firebase-Apps, die für dasselbe Firebase-Projekt registriert sind, verwenden dieselben Backends, z. B. Firebase Hosting, Authentication, Realtime Database, Cloud Firestore, Cloud Storage und Cloud Functions.
Alle Firebase-Apps, die mit demselben Firebase-Projekt registriert sind, sind mit derselben Google Analytics-Property verknüpft. Dabei ist jede Firebase-App ein separater Datenstream in dieser Property.
Wo passt ein Google Cloud-Projekt in diese Hierarchie?
Ein Aspekt der Firebase-Projekthierarchie, der im Diagramm oben nicht dargestellt ist, ist die Beziehung zu einem Google Cloud-Projekt. Ein Firebase-Projekt ist im Grunde nur ein Google Cloud-Projekt, für das zusätzliche Firebase-spezifische Konfigurationen und Dienste aktiviert sind.
Alle Apps, die für dasselbe Firebase-Projekt registriert sind, teilen sich dieselben Google Cloud-Ressourcen und ‐Dienste und haben darauf Zugriff.
Hier sind einige wichtige Tipps zur Registrierung Ihrer App-Varianten in einem Firebase-Projekt:
Alle in einem Firebase-Projekt registrierten Apps müssen aus Sicht der Endnutzer Plattformvarianten derselben Anwendung sein. Registrieren Sie die iOS-, Android- und Webversionen derselben App oder desselben Spiels im selben Firebase-Projekt.
Wenn Sie mehrere Buildvarianten haben, die dieselben Firebase-Ressourcen verwenden könnten, registrieren Sie die Varianten im selben Firebase-Projekt. Beispiele hierfür sind ein Blog und eine Webanwendung im selben Projekt oder die kostenlose und die kostenpflichtige Version derselben App im selben Projekt.
Wenn Sie mehrere Buildvarianten haben, die auf dem Release-Status basieren (nicht auf allgemeinen Endnutzeraktivitäten oder Zugriffen wie oben), registrieren Sie jede Variante in einem separaten Firebase-Projekt. Ein Beispiel sind Debug- und Release-Builds. Registrieren Sie jeden dieser Builds in einem eigenen Firebase-Projekt.
Builds, die auf dem Release-Status basieren, sollten nicht dieselben Firebase-Ressourcen verwenden, da dies das Risiko birgt, dass Ihre Debug-Daten Ihre Produktionsdaten verunreinigen oder sogar überschreiben.
Die Plattform-Varianten jeder dieser Build-Varianten sollten sich im gleichen Firebase-Projekt befinden. Sie können beispielsweise sowohl die iOS- als auch die Android-Debug-Builds in einem Firebase-Entwicklerprojekt registrieren, da beide mit denselben nicht produktionsbezogenen Daten und Ressourcen interagieren können.
Mehrinstanzenfähigkeit vermeiden
Die Mehrfachnutzung kann zu ernsthaften Problemen bei der Konfiguration und dem Datenschutz führen, einschließlich unbeabsichtigter Probleme bei der Analyseaggregation, der gemeinsamen Authentifizierung, übermäßig komplexer Datenbankstrukturen und Schwierigkeiten mit Sicherheitsregeln.
Wenn mehrere Apps nicht dieselben Daten und Konfigurationen verwenden, sollten Sie jede App in einem separaten Firebase-Projekt registrieren.
Wenn Sie beispielsweise eine White-Label-Anwendung entwickeln, sollte jede unabhängig gekennzeichnete App ein eigenes Firebase-Projekt haben. Die iOS- und Android-Versionen dieses Labels sollten sich im selben Firebase-Projekt befinden. Jede unabhängig gekennzeichnete App darf aus Datenschutzgründen keine Daten mit anderen Apps teilen.
Nächste Schritte
Lesen Sie die allgemeinen Sicherheitsrichtlinien für verschiedene Umgebungen. Sie möchten dafür sorgen, dass jede Umgebung und ihre Daten sicher sind.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-07-25 (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)."]]
Dieses Diagramm zeigt die grundlegende Hierarchie eines Firebase-Projekts. Hier sind die wichtigsten Beziehungen: