The Firebase Production Checklist: What to Verify Before Launch

Firebase is production ready as a platform; your Firebase app is production ready only when the team can deploy it safely, detect a failure, control scaling costs, and recover data or service after something goes wrong.

That is the useful distinction behind “Is Firebase good for production?” Google operates the managed services; your release process decides whether the specific app is ready for customers. A passing demo, a paid Blaze plan, or a successful firebase deploy proves none of the operational controls below.

This checklist is six gates: environment isolation, a deploy gate, cost controls, monitoring, backups and recovery, and one release rehearsal. Two of those are the reason this page exists. Google’s own Firebase launch checklist is thorough, current, and organized product by product, and it does not cover backups, restore drills, or what can actually be rolled back. Gate 5 here is that missing half.

The Firebase production-readiness gate

A launch is ready when each row has an owner and evidence. “We will add it after traffic” is not evidence, because several of these controls are hardest to introduce during an incident.

The same six gates, broken into things you can tick off:

1. Create separate Firebase projects for development, staging, and production.
2. Confirm production rules are out of test mode and actually check the signed-in user.
3. Keep rules, indexes, and project aliases in version control.
4. Run rules and function tests in the Local Emulator Suite before anything deploys.
5. Add a predeploy hook so a failed check cancels the deployment.
6. Require a human approval and an explicit project target on the production job.
7. Estimate reads, writes, deletes, and egress for the real user journey.
8. Set budget and usage alerts, and decide whether a hard billing kill switch is acceptable.
9. Set and test maxInstances on functions that can run away.
10. Send a test error and confirm it reaches a named person.
11. Turn on Firestore scheduled backups or point-in-time recovery.
12. Run one restore into a new database and time it.
13. Rehearse the whole release on staging before customers see it.

Firebase being production-ready and your Firebase app being production-ready are two different sentences.

Detailed authorization design belongs to the safety owner and is a topic in its own right: the Firebase security checklist and the safety verdict hold that ground, a companion post on Firebase security covers the rules themselves, and Google’s security checklist is the platform reference. This article asks the operational question instead: can the app change, be watched, and be recovered once real traffic arrives?

If Firebase Studio or an AI builder set this up for you

An app already generated in Firebase Studio, or by any AI builder wired to Firestore, genuinely runs on Google’s infrastructure. That is not the same as the app being ready for customers.

In an existing workspace, Firebase Studio’s App Prototyping agent sets up Cloud Firestore and Firebase Authentication for you when the app needs a database or sign-in. It provisions products. It does not set a budget alert, does not enable scheduled backups, does not create a second project for staging, does not choose a maxInstances ceiling, and does not decide who gets paged at 2am. Every one of those is a decision with an owner, and a generator has no owner to assign.

Google disabled new Firebase Studio workspace creation and new-user signup on 22 June 2026 and will shut the development environment on 22 March 2027. Existing apps and core Firebase services continue outside Studio. An existing generated project can also start in test mode, the most permissive rules state Firebase offers, because that is the setting that makes a prototype work on the first try.

None of this is an argument against building that way. It is the reason the checklist below applies to a generated Firebase project exactly as it applies to hand-written code. The generated app is a starting point that happens to already be deployed.

1. Environment isolation: separate development, staging, and production

Firebase’s environment guidance recommends a separate Firebase project for each environment. Separate projects isolate Authentication users, Firestore data, Storage files, functions, quotas, billing signals, and Security Rules.

Use Firebase CLI project aliases so a deployment target is explicit. Keep the mapping in the repository, and require the release workflow to select production deliberately. Do not use the production project as a shared test environment or copy real customer data into development by default. A single shared project is the Firebase shape of the one-database, no-staging setup that is set to break on deploy: every experimental rule, index, and agent-run migration lands on the instance customers are using, because there is no second one to point at.

Check which rules state each project is in before anything else. Firebase’s own Firestore quickstart describes a database created in test mode as one that “allows anyone to read and overwrite your data”, while production mode “denies all reads and writes from mobile and web clients” until you write rules that allow them. Test mode is a development convenience. Neither wide open nor fully denied is a launch state, and Google’s security checklist puts initializing rules in production or locked mode near the top for that reason.

A useful staging check uses the same build and deployment path as production, with environment-specific credentials and data. It should exercise sign-in, the main write path, background functions, file uploads, error reporting, and the rules that protect those operations. The local emulator is not a substitute for that project: it does not exercise real quotas, real IAM, or real third-party callbacks.

2. Add a deploy gate: make a failed check stop the deploy

The Firebase CLI can deploy all configured resources or a targeted subset with --only. It also supports predeploy hooks; if a predeploy command fails, Firebase cancels that deployment.

The exact commands depend on the repository, but the gate should cover the checks the app actually relies on:

{
  "functions": {
    "predeploy": [
      "npm --prefix \"$RESOURCE_DIR\" run lint",
      "npm --prefix \"$RESOURCE_DIR\" test"
    ]
  }
}

That hook covers only the deployment command. Run build, type, unit, integration, and Security Rules tests in CI before a human-approved production job. Pin the project alias or project ID in the job. Prefer a targeted deploy when only one resource should change, and inspect the deploy plan instead of assuming every local file belongs in the release.

Run those checks locally first. The Local Emulator Suite emulates Cloud Firestore, Realtime Database, Cloud Storage, Authentication, Cloud Functions, Pub/Sub, and Extensions on your own machine, and Firebase describes it as a way to test an app “without risking production data or configuring a test project”. That is where Security Rules unit tests belong, and it is how you exercise a fan-out write without billing yourself for the experiment. Firebase’s launch checklist asks you to test every change in the emulator before deploying to production.

The configuration step is the whole gate. Across the AxonBuild June and July 2026 audit corpus, at least 17 of 21 third-party apps had no deploy gate at all: every push went to production with nothing standing in front of it. The Firebase shape of that failure is a single project with a Git integration deploying on merge and no predeploy hook configured, so rules, indexes, functions, and hosting all reach customers on the same push. Nobody had to defeat a gate. There was no gate.

Record the deployed commit, production project, operator, and result. Those four details shorten the first minutes of an incident.

3. Cost controls: what Firebase budget alerts can and cannot do

Moving from Spark to Blaze enables paid usage; it does not create a maximum bill. Firebase’s current launch checklist explicitly says Google Cloud budget alerts do not cap usage or charges.

Before launch:

• estimate Firestore reads, writes, deletes, stored data, and network egress for the expected user journey;
• inspect whether listeners, retries, fan-out writes, or unbounded queries multiply those operations;
• set budget alerts at thresholds that leave time to investigate;
• configure product usage alerts and review dashboards during launch;
• set and test function maxInstances where runaway scaling or a protected dependency would be dangerous.

The only real ceiling, and what it costs you

Budget alerts notify. They do not stop anything. The one hard ceiling Google documents is to wire the budget to a Pub/Sub topic and a Cloud Function that disables billing on the project. Read the warnings on that page before reaching for it. Google states that disabling billing on a project terminates all Google Cloud services in that project including Free Tier services, that resources “might be irretrievably deleted”, and that you can re-enable billing but it requires manual configuration with no guarantee of service recovery. There is also a delay between incurring cost and the notification arriving, so spend continues past the trigger point.

So it is a kill switch, not a throttle. It stops the bill by taking the app offline. Whether that tradeoff is acceptable is a founder decision, not an engineering one, and it should be made before launch rather than at 3am during an incident. For a customer-facing product the answer is usually no, and the real control is the read pattern below. For an internal tool, a demo, or a pre-revenue beta, a hard ceiling can be exactly right.

Why the estimate matters more than the alert

Firestore has no server-side join and bills every document read individually. A screen showing twenty orders with a customer name on each needs at least forty reads, and the read count grows with the data, not the code. Firebase’s own billing walkthrough works through that shape: a chat app’s home screen reloading the 25 most recent chats every time it opens, rewritten to ask only for what changed since the last check.

// Unoptimized: reloads the 25 most recent chats every time
// the screen opens.
db.collection('groups')
  .where('participants', 'array-contains', 'user123')
  .orderBy('lastUpdated', 'desc')
  .limit(25);

// Same screen, filtered to what actually changed since the
// last visit.
db.collection('groups')
  .where('participants', 'array-contains', 'user123')
  .where('lastUpdated', '>', lastFetchTimestamp)
  .orderBy('lastUpdated', 'desc')
  .limit(25);

The walkthrough assumes 10 updated chats per check, so the filter cuts 25 reads to 10 without changing anything the user sees. The same example totals a small app, 50,000 installs and 5,000 daily active users, at roughly $12.14 a month once reads, writes, deletes, storage, and egress are added up, as of August 2026. Nobody notices $12; the risk is the same pattern under ten times the users or ten times the reads per screen, because an AI builder scaffolding a list view has no reason to write the filtered version when the unoptimized one demos identically. It is the same wiring gap that stalls apps at 100 concurrent users on a SQL backend, appearing here in Firestore’s syntax instead of a missing join.

Choose maxInstances from tested traffic and failure behavior. Firebase warns that a limit that is too low can reject or defer traffic, while leaving it unbounded can let a faulty loop or abuse scale quickly.

For a new launch, assign one person to watch usage and billing signals during the first traffic window. An alert without an owner or response threshold is only a notification.

4. Monitoring and alerts: prove a failure reaches a person

The Firebase launch checklist recommends Crashlytics for supported mobile apps and calls for monitoring, alerts, and release visibility. The exact stack can also include Cloud Logging, Error Reporting, Cloud Monitoring, or an external service, depending on the products used.

Match the tool to the platform first. Crashlytics supports Apple, Android, Flutter, and Unity. It does not cover web. Most AI-built Firebase apps are web apps, so the equivalent there is Cloud Logging, Error Reporting, and Cloud Monitoring, plus an external uptime check. Google’s checklist lists Crashlytics without that caveat, and a web team that ticks the box gets no crash reporting at all.

Installation alone does not establish observability. Verify the operating path instead:

1. Can the team see a failed customer action with enough context to diagnose it?
2. Does an unexpected error-rate, latency, or usage change trigger an alert?
3. Does that alert reach a person who can act?
4. Can the team identify which release introduced the change?

Send a controlled test error or alert before launch and verify the complete path. Also monitor the customer journey from outside the application; the approach in our uptime monitoring guide helps cover failures that internal logs may miss.

5. Backups and recovery: what can actually be rolled back

“Firebase has backups” is too broad to be a recovery plan. Different resources have different recovery mechanisms, and this is the gate Google’s launch checklist leaves out entirely.

• Firebase Hosting release history supports rollback to a previous Hosting version. Preview channels can validate a web release before the live channel.
• Firestore scheduled backups can run daily or weekly and restore into a new database. Point-in-time recovery can protect a recent window with finer granularity. Both require configuration and incur product-specific cost.
• The Firebase CLI documentation says deployed Firestore, Realtime Database, and Storage rules cannot be rolled back through the normal rollback feature. Keep rules in version control and maintain a tested fix-forward path.
• Functions and application code depend on the deployment generation, source history, configuration, and downstream state. A code rollback does not undo database writes already performed.

Firestore’s disaster-recovery guidance describes scheduled backups, point-in-time recovery, cloning, and exports. Choose the mechanism from the amount of data the business can lose and the time it can remain unavailable. Then perform a restore drill. A scheduled job that has never been restored is an unverified backup, and the drill itself is an afternoon of work that turns a backup setting into a recovery capability.

Document the destination database, validation steps, application cutover, and who is authorized to perform them. Recovery often fails at the handoff rather than at the backup command.

6. Run one release rehearsal

Before accepting customer traffic, run the release as if it were real:

1. Deploy the release candidate to the staging project through CI.
2. Run critical-path tests with at least two user accounts and realistic permissions.
3. Verify background functions, scheduled work, Storage operations, and third-party callbacks.
4. Review App Check metrics and application errors to confirm that enforcement and rules are not silently blocking intended clients.
5. Trigger a controlled application error and confirm the alert reaches its owner.
6. Review usage and budget signals after the test traffic.
7. Deploy the same commit to production with an explicit project target and approval.
8. Run a short production smoke test, then record the release result.
9. Rehearse one applicable recovery action, such as a Hosting rollback or a Firestore restore into a non-production database.

The rehearsal should produce artifacts: test output, a release record, alert evidence, and recovery notes. Those artifacts turn readiness from an opinion into a repeatable gate.

The decision

A Firebase app is ready for production when environment isolation, release checks, cost controls, observability, and recovery have all been demonstrated against the actual deployment. Firebase removes much of the infrastructure work, but it does not own those application-level decisions.

How much work is this? For a small team on an app that already works, closing all six gates is a few focused days, most of it spent standing up the staging project and running the first restore drill. The cost is lopsided: a second Firebase project for staging is free at low volume, because Firestore’s free tier covers 50,000 document reads, 20,000 writes, and 20,000 deletes a day, plus 1 GiB of stored data and 10 GiB of outbound transfer a month, for one database per project. Scheduled backups and point-in-time recovery are billable, and they are usually the only new line item this checklist adds.

If the team cannot say which commit is live, who receives an alert, how spend is constrained operationally, or how data would be restored, the app is not ready yet. The next step is to close those specific gates, not to replace Firebase simply because the checklist exposed them. The same evidence standard decides whether any AI-built app is ready to launch, and for a different stack, Lovable’s version of the question covers the parts that do not change with the backend.

Common questions about Firebase in production

Is Firebase used for production apps?

Yes, widely, across mobile and web apps at every size. The open question is narrower: whether a specific app’s read patterns, deploy path, project setup, and recovery plan were actually built for production traffic. Firebase being ready is a settled question; your app being ready is the one this checklist answers.

Is Firebase a good option for large scale production apps?

Yes, with a caveat: scale on Firestore means read volume, not user count. A lean, denormalized read pattern runs at real scale on Blaze; a screen that reads more than it needs to feels the cost first, because every document read is billed on its own. Firestore has no server-side join, so your read count grows with the data, not with the code.

Is Firebase suitable for commercial app hosting?

Yes, for most commercial apps, with the same trade you make with any managed backend: you accept Google’s pricing model and product lifecycle in exchange for not running servers. The commercial risks worth pricing in are the metered bill that alerts report but do not cap, the per-product deprecation risk, and the migration cost if you outgrow Firestore’s query model. None of those are reasons not to launch, only reasons to close the six gates first.

How much does Firestore cost in production?

It depends on read volume, not headcount. As of August 2026, Blaze bills roughly $0.06 per 100,000 document reads, $0.18 per 100,000 writes, and $0.02 per 100,000 deletes, and the rate varies by region, so check Firestore’s current pricing for your own location. A lean screen runs a few dollars a month at real traffic; an unbounded one runs far higher. Budget alerts notify, they do not cap the bill.

Do I need a staging environment for Firebase?

If the only Firebase project that exists is the one customers are on, yes. Firebase’s own guidance treats a separate project per environment as standard practice, and a staging copy costs nothing extra at low volume because it sits inside the free daily quota. Its absence means every rule change and every agent-run migration lands on production first.

Does Firebase have a deploy gate built in?

Not by default. The CLI supports predeploy hooks that cancel a deployment when a check fails, but nothing runs unless you configure it, and a Git integration deploys on merge with whatever checks you wired around it. That gap let at least 17 of 21 third-party apps in the AxonBuild corpus ship straight to production with nothing checking first.

Are my Firebase API keys safe to expose?

Yes. Firebase states that API keys for Firebase services only identify your project and app to those services, that authorization is handled by Google Cloud IAM, Firebase Security Rules, and App Check, and that such keys do not need to be treated as secrets in client code. The catch is the other half of that sentence: because the key is public by design, your rules and App Check are the only things between an anonymous request and your data.

How do I know if my Firestore rules are still in test mode?

Open the Rules tab for that database and read the condition on allow read, write. If access is granted without checking the signed-in user, you are in test mode, which Firebase describes as a setting that “allows anyone to read and overwrite your data”. A condition time-boxed to a fixed date is test mode too, and it fails closed the moment that date passes. Production or locked mode denies all client reads and writes until you write rules that allow them, which is the state to launch from.

Do I need the Firebase Local Emulator Suite before launch?

Yes, if you have Security Rules worth testing or functions that write data. The emulator runs Firestore, Realtime Database, Storage, Authentication, Functions, Pub/Sub, and Extensions locally, so you can unit test rules and exercise write paths without touching production data or paying for the attempt. Firebase’s launch checklist asks for exactly this before you deploy.

Will Google discontinue Firebase products I depend on?

Firebase as a platform is not going anywhere, but individual products do get retired. Firebase Dynamic Links shut down on August 25, 2025, and Google’s launch checklist still carries a Dynamic Links section, now with a note recommending you migrate off the service. Treat product status as a gate item: for each Firebase product your app depends on, check its current status and deprecation notice before launch, and again at every review.

How this checklist was built

The gates come from Firebase and Google Cloud’s current product guidance, verified against the linked pages on August 6, 2026. Quotas, prices, and product-status facts are dated in line and linked to the source page that states them, because those are the parts that go stale first.

No Firebase app sits in the current AxonBuild audit cohort, so this article assigns Firebase no readiness or failure rate. The one corpus figure used above, at least 17 of 21 third-party apps with no deploy gate, is stack-independent: it counts apps with no automated check standing between a push and production, on any platform.