This document contains a checklist of best practices and considerations before launching a Firebase app to production. ## General best practices for releasing - Make sure that you've tested all your changes in the [Firebase Local Emulator Suite](https://firebase.google.com/docs/emulator-suite.md.txt) (for supported products) before deploying to production. Thorough testing can help prevent costly mistakes. - Start *enforcing* [Firebase App Check](https://firebase.google.com/docs/app-check.md.txt) for every service that supports it. App Check helps to ensure only your actual apps can access your backend services and resources. - Review [Firebase's general security checklist](https://firebase.google.com/support/guides/security-checklist.md.txt). - Use [Firebase Remote Config rollouts](https://firebase.google.com/docs/remote-config/rollouts.md.txt) to safely and gradually release new features and updates to your app. - If you haven't already, consider setting up [Firebase Crashlytics](https://firebase.google.com/docs/crashlytics.md.txt). This is a lightweight, realtime crash reporter that helps you track, prioritize, and fix stability issues that erode your app quality. ## Know your pricing plan limits and set budget alerts - Make sure you don't hit usage limits and quotas after going to production, especially if you're on the no-cost Spark plan. Consider upgrading to the [pay-as-you-go Blaze pricing plan](https://firebase.google.com/pricing.md.txt). - Set up [budget alerts](https://firebase.google.com/docs/projects/billing/budget-alerts.md.txt) for your project. - Note that budget alerts are *not* budget *caps*. An alert will send you communications when you're approaching or surpassed your configured threshold so that you can take action in your app or project. - Consider setting up [advanced alerts and actions](https://firebase.google.com/docs/projects/billing/advanced-billing-alerts-logic.md.txt), like functions that will disable billing in response to alerts. - If you use Firebase AI Logic, Firebase App Hosting, Cloud Functions for Firebase, and Firebase Extensions, we strongly recommend that you also **set up [spend caps](https://firebase.google.com/docs/projects/billing/spend-caps.md.txt)**, which will pause the applicable service if your project reaches the budget set for that service. - Monitor your usage in the product-specific dashboards or in the central [*Usage and billing* dashboard](https://console.firebase.google.com/project/_/usage) in the Firebase console. ## Make sure your Firebase projects and apps follow best practices Whether you're a single developer or an enterprise-sized team, it's important to make sure that your Firebase projects, apps, and resources are protected, secured, and can evolve with changes in your team. It's helpful to remember that a Firebase project is really just a Google Cloud project with Firebase services and configurations enabled for it. This means that many best practices that Google Cloud recommends are also applicable to Firebase. - Use different Firebase projects for development, testing, and production. Try to limit unexpected exposure to the project associated with your production app. Learn more about [setting up development workflows](https://firebase.google.com/docs/projects/dev-workflows/overview-environments.md.txt). - Protect your important projects, most especially the project associated with your production app. - Use [project liens](https://cloud.google.com/resource-manager/docs/project-liens) to protect against accidental project deletion. - Apply a ["Prod" tag](https://firebase.google.com/support/faq.md.txt#set-environment-type) within the Firebase console to make it easier to identify your production environment. - If you haven't already, consider setting up a [Google Cloud organization](https://firebase.google.com/support/faq.md.txt#what-is-a-cloud-org) and adding your Firebase projects to it. - Add more than one Owner to your Firebase projects, especially if your project is *not* in a Google Cloud organization. Learn more about [when and how to assign Owners](https://firebase.google.com/support/faq.md.txt#why-when-to-assign-project-owner) for a Firebase project. - Add project members (aka "principles") as Google groups instead of individually. Using groups makes it easier to assign roles to team members in bulk as well as manage who has access to your Firebase project, especially if team members rotate or leave. - Grant each project member (aka "principle") the appropriate level of access to your Firebase projects and resources. Learn more in [Manage project access with Firebase IAM](https://firebase.google.com/docs/projects/iam/overview.md.txt). - Make sure each applicable project member (aka "principle") sets up their preferences to receive alerts about specific products or project state (like billing plan changes or quota limits). Learn more in [Receive Firebase alerts](https://support.google.com/firebase/answer/7276542). You can also optionally [customize your project's "essential contacts"](https://cloud.google.com/resource-manager/docs/managing-notification-contacts) if you want specific or additional project members to receive notifications. This is particularly helpful to ensure that more than just the project Owner gets notifications about billing, legal, and product changes. - Restrict your Firebase API keys to only the APIs that need to be on the [key's API allowlist](https://firebase.google.com/docs/projects/api-keys.md.txt#faq-required-apis-for-restricted-firebase-api-key). Also, check out the information about API keys in [Firebase's security checklist](https://firebase.google.com/support/guides/security-checklist.md.txt). ## Prepare specific services used in your app Each product and service used in your app might have specific considerations when they're used in production. ### **Firebase AI Logic** - See the [Production checklist for using Firebase AI Logic](https://firebase.google.com/docs/ai-logic/production-checklist.md.txt). ### **Google Analytics** - Define audience conditions for [Google Analytics](https://firebase.google.com/docs/analytics.md.txt) to start collecting analytics data starting at the launch of your app. - Consider [enabling export of Google Analytics data to BigQuery](https://firebase.google.com/docs/projects/bigquery-export.md.txt) so that you can analyze your data with BigQuery SQL or export the data to use with your own tools. - Limit user properties to information that will be relevant for the lifecycle of your entire app. There's a [limit to the number you can create](https://support.google.com/analytics/answer/9267744), and they can't be archived. - Review the settings for [Google Analytics roles](https://support.google.com/analytics/answer/9305587) for your Google Analytics properties and accounts. These permissions are separately managed from the Firebase project IAM permissions and roles. - Make sure your App Store ID and Team ID (if necessary) are correct in the [*Project settings*](https://console.firebase.google.com/project/_/settings) of the Firebase console. ### **App Check** - Make sure your Team ID is correct in the [*Project settings*](https://console.firebase.google.com/project/_/settings) of the Firebase console. - If you haven't already, start *enforcing* [Firebase App Check](https://firebase.google.com/docs/app-check.md.txt) for every service that supports it. App Check helps to ensure only your actual apps can access your backend services and resources. ### **Authentication** - Disable any [providers](https://console.firebase.google.com/project/_/authentication/providers) that you aren't using (especially anonymous authentication). - If your app uses Sign in with Google, personalize your [OAuth consent screen](https://console.developers.google.com/project/_/apis/credentials/consent). - Customize your domain and sender for the [Authentication email sending service](https://console.firebase.google.com/project/_/authentication/emails). - If you're using Identity Platform SMS verification services, start *enforcing* [Firebase App Check](https://firebase.google.com/docs/app-check.md.txt) and configure an [SMS region policy](https://cloud.google.com/identity-platform/docs/admin/sms-regions) to protect your app from SMS abuse. - Implement error handling on Apple platforms for [common Authentication errors](https://firebase.google.com/docs/auth/ios/errors.md.txt). - Add a release SHA-1 hash for your app's signing certificate in the [*Project settings*](https://console.firebase.google.com/project/_/settings) of the Firebase console. The SHA-1 hash is required if your app uses phone number sign-in or Sign in with Google (which has an OAuth client requirement). - Add access control for your domains to prevent unauthorized usage. Specifically, allow access to your production domain in the [*Authentication* section](https://console.firebase.google.com/project/_/authentication/providers) of the Firebase console (especially important if you use products that rely on Firebase Security Rules). ### **Cloud Firestore** - Configure your [Cloud Firestore Security Rules](https://firebase.google.com/docs/firestore/security/get-started.md.txt) to prevent unintentional data access. - Use [ProGuard for code shrinking](https://developer.android.com/studio/build/shrink-code) in your release build. Without ProGuard, the Cloud Firestore SDK and its dependencies can increase your APK size. ### **Cloud Messaging** - Consider [enabling export of Cloud Messaging data to BigQuery](https://firebase.google.com/docs/projects/bigquery-export.md.txt) so that you can analyze your data with BigQuery SQL or export the data to use with your own tools. - Upload your APNS Auth Key for Cloud Messaging on Apple apps in the [Firebase console](https://console.firebase.google.com/). If using APNS certificates, ensure that your production APNS certificate is uploaded. - Consider enabling [cloud audit logging](https://firebase.google.com/docs/cloud-messaging/cloud-audit-logging) for Cloud Messaging so that you can generate audit logs that record administrative and access activities within your Google Cloud resources. - Make sure to periodically update to the newest version of the SDK to stay up to date with new features and security updates. - Follow [Cloud Messaging registration token management best practices](https://firebase.google.com/docs/cloud-messaging/manage-tokens) on your app server. Save registration tokens with a timestamp, update them on changes, and remove stale tokens (inactive for over a month) to ensure valid delivery reporting and efficient message targeting. - Follow [best practices when sending Cloud Messaging messages at scale](https://firebase.google.com/docs/cloud-messaging/scale-fcm). Use the HTTP v1 API or Firebase Admin SDK, implement exponential backoff with jitter for retries, and respect `Retry-After` headers to avoid traffic spikes and rate limits. ### **Cloud Storage** - Configure your [Cloud Storage Security Rules](https://firebase.google.com/docs/storage/security.md.txt) to prevent unintentional data access. ### **Crashlytics** - Make sure each applicable project member (aka "principle") sets up their preferences to receive alerts about Crashlytics or project state (like billing plan changes or quota limits). Learn more in [Receive Firebase alerts](https://support.google.com/firebase/answer/7276542). - Consider [enabling export of Crashlytics data to BigQuery](https://firebase.google.com/docs/projects/bigquery-export.md.txt) so that you can analyze your data with BigQuery SQL or export the data to use with your own tools. - *(native Android and iOS only)* Consider enabling [AI assistance in Crashlytics](https://firebase.google.com/docs/crashlytics/ai-assistance.md.txt) to help speed up the time it takes for you to understand why a crash happened and what to do about it. - Upload the dSYM file for release builds for use in Crashlytics. Make sure that Xcode can [automatically process dSYMs and upload the files](https://firebase.google.com/docs/crashlytics/ios/get-deobfuscated-reports.md.txt#check-input-files-setup). - Upload [ProGuard mapping](https://firebase.google.com/docs/crashlytics/android/get-deobfuscated-reports.md.txt) for release builds for use in Crashlytics. Uploading is possible using the [Firebase CLI](https://firebase.google.com/docs/cli.md.txt#crashlytics-commands). - [Link Firebase to Google Play](https://firebase.google.com/docs/crashlytics/integrate-with-google-play.md.txt) to get a richer view into your Android app's health. For example, you can filter your app's crash reports by Google Play track, which lets you better focus your dashboard on specific builds. - For builds targeting Android and using IL2CPP, make sure that you're [uploading native symbols](https://firebase.google.com/docs/crashlytics/unity/get-deobfuscated-reports.md.txt#android) for every individual build run you hope to have symbols for regardless of whether there were any code or configuration changes. ### **Dynamic Links** - Dynamic Links is deprecated, so we recommend migrating off the service. Learn more in the [deprecation FAQ](https://firebase.google.com/support/dynamic-links-faq.md.txt). ### **Firebase ML** - See [Prepare your Firebase ML Apple app for production](https://firebase.google.com/docs/ml/ios/secure-api-key). - See [Prepare your Firebase ML Android app for production](https://firebase.google.com/docs/ml/android/secure-api-key). ### **Performance Monitoring** - Make sure each applicable project member (aka "principle") sets up their preferences to receive alerts about Performance Monitoring or project state (like billing plan changes or quota limits). Learn more in [Receive Firebase alerts](https://support.google.com/firebase/answer/7276542). - Consider [enabling export of Performance Monitoring data to BigQuery](https://firebase.google.com/docs/projects/bigquery-export.md.txt) so that you can analyze your data with BigQuery SQL or export the data to use with your own tools. ### **Realtime Database** - Configure your [Realtime Database Security Rules](https://firebase.google.com/docs/database/security.md.txt) to prevent unintentional data access. - Make sure that you're ready to scale. Realtime Database has a [default quota](https://firebase.google.com/docs/database/faq-and-troubleshooting.md.txt#database-limits) large enough for most applications, but some apps might need extra capacity. - [Configure your proguard rules](https://firebase.google.com/docs/database/android/start.md.txt#proguard) to work with the Realtime Database. ### **Remote Config** - Make sure that any experimental [Remote Config](https://firebase.google.com/docs/remote-config.md.txt) rules don't affect your release users, and that appropriate server and in-app defaults are distributed in your app. - Consider [configuring a `minimum_version` parameter](https://firebase.google.com/docs/remote-config/use-cases/minimum-version.md.txt) in Remote Config so that you can prompt or require users to update their app if earlier versions become incompatible or deprecated.