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 (for supported products) before deploying to production. Thorough testing can help prevent costly mistakes.
-
Start enforcing Firebase App Check for every service that supports it. App Check helps to ensure only your actual apps can access your backend services and resources.
Use Firebase Remote Config rollouts to safely and gradually release new features and updates to your app.
If you haven't already, consider setting up Firebase Crashlytics. 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.
Set up budget alerts 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, like functions that will disable billing in response to alerts.
Monitor your usage in the product-specific dashboards or in the central Usage and billing dashboard 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.
Protect your important projects, most especially the project associated with your production app.
Use project liens to protect against accidental project deletion.
Apply a "Prod" tag 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 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 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.
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.
Restrict your Firebase API keys to only the APIs that need to be on the key's API allowlist. Also, check out the information about API keys in Firebase's security checklist.
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.
Google Analytics
Define audience conditions for Google Analytics to start collecting analytics data starting at the launch of your app.
Consider enabling export of Google Analytics data to BigQuery 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, and they cannot be archived.
Review the settings for Google Analytics roles 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 of the Firebase console.
App Check
Make sure your Team ID is correct in the Project settings of the Firebase console.
If you haven't already, start enforcing Firebase App Check 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 that you aren't using (especially anonymous authentication).
If your app uses Sign in with Google, personalize your OAuth consent screen.
Customize your domain and sender for the Authentication email sending service.
If you're using Identity Platform SMS verification services, start enforcing Firebase App Check and configure an SMS region policy to protect your app from SMS abuse.
Implement error handling on Apple platforms for common Authentication errors.
Add a release SHA-1 hash for your app's signing certificate in the 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 of the Firebase console (especially important if you use products that rely on Firebase Security Rules).
Cloud Firestore
Configure your Cloud Firestore Security Rules to prevent unintentional data access.
Use ProGuard for code shrinking 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 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. If using APNS certificates, ensure that your production APNS certificate is uploaded.
Cloud Storage
- Configure your Cloud Storage Security Rules 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.
Consider enabling export of Crashlytics data to BigQuery 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 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.
Upload ProGuard mapping for release builds for use in Crashlytics. Uploading is possible using the Firebase CLI.
Link Firebase to Google Play 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 to better focus your dashboard on specific builds.
For builds targeting Android and using IL2CPP, make sure that you're uploading native symbols 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.
Firebase ML
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.
Consider enabling export of Performance Monitoring data to BigQuery 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 to prevent unintentional data access.
Make sure that you're ready to scale. Realtime Database has a default quota large enough for most applications, but some apps may need extra capacity.
Configure your proguard rules to work with the Realtime Database.
Remote Config
- Make sure that any experimental Remote Config rules don't affect your release users, and that appropriate server and in-app defaults are distributed in your app.