Hi all! At my company we develop a white-label app, so we have 60+ Firebase projects. Keeping Remote Config in sync across all of them through the console is painful: changing one parameter can mean opening dozens of projects and clicking through each one.

So I built fbrcm, a terminal manager for Remote Config. It has an interactive TUI, a full CLI, and an MCP server. It’s free, open source (MIT), not monetized, and not affiliated with or endorsed by Google or Firebase.

It can

• Discover all the projects your account can access and work with them together
• Get, update, add, delete and duplicate parameters, conditions and groups across many projects at once, with filters to pick the projects (fuzzy, prefix, exact, or expressions on the actual values)
• Compare and promote configuration between projects
• Browse version history, roll back, restore, import and export templates
• Client and server templates are both supported
• --dry-run to preview a change, and --json output for scripts and CI

A few things I want to be upfront about:

• Credentials: since this is a third-party tool, it’s reasonable to be careful about handing it cloud access. It requests the cloud-platform Google OAuth scope, which is very broad. I know that’s a big ask, but it’s the only scope that lets all the features work (project discovery plus reading and publishing templates). Everything runs locally, with no backend and no telemetry, and the code is open so you can judge the risk yourself. If you’d like tighter limits, you can use a dedicated service account and grant it IAM access only to the projects you want to manage.
• AI-assisted: the project is largely vibe-coded, as noted in the README, so bug reports on edge cases are very welcome.

Docs: https://fbrcm.yumaa.dev · Code: https://github.com/yumauri/fbrcm

I’d love feedback, especially from anyone else managing Remote Config across many projects. What does your workflow look like, and what’s missing?

Hi everyone,

I'm facing an issue with unexpected SMS charges in my Firebase project, and I'm looking for advice from anyone who has experienced something similar.

I suspect my Firebase Phone Authentication flow may be experiencing SMS pumping or automated OTP abuse, but I'm not sure how it's happening despite having several security measures in place.

Security measures already enabled:

• Firebase App Check is enabled.
• SMS region restrictions are configured for India only.
• Firebase reCAPTCHA is activated.
• Play Integrity is enabled for app verification.

Despite these protections, I'm concerned about unusual SMS activity and unexpected billing.

My questions:

1. How can automated bots abuse Firebase Phone Authentication when App Check, reCAPTCHA, and Play Integrity are already enabled?
2. Can attackers still trigger OTP requests using emulators, modified apps, or automated devices?
3. What additional rate-limiting mechanisms should I implement to restrict OTP requests per device, IP address, or phone number?
4. Are there any Firebase Authentication settings that can further limit SMS abuse or prevent excessive OTP requests?
5. Has anyone successfully received a billing adjustment from Firebase or Google Cloud after experiencing suspected SMS pumping?

I'd appreciate any practical advice, especially from developers who have dealt with this issue in production.

Thanks in advance for your help!

Hello everyone and thank you for reading this post. I am screwed and cannot figure out how to find a solution myself. So, here I am.

I have basic and free Android app. I am using Firestore as my backend. I have users and usersPrivate documents and everything is separated nicely. Only those whom are authenticated to perform a particular action is allowed. For the past few weeks bots somehow found my app and attacking me with DOW (Denial of Wallet). I have banned these bots' UIDs but the problem is their auth token remains valid for an hour. I have AppCheck and they are somehow bypassing it.

They are unable to read any documents, so the bill is not coming from that but the cost of 1 read per rejection in security rules (checking banned accounts). I could deny all auth tokens but that hurts the honest users as they cannot perform any actions within the app. The bots definitely know about the 1-hour period of an already issued auth token expiry and coordinating their attacks with 50 mins apart.

Cumulatively, they are hitting me with about 30k requests denials a minute, so I closed the app for now. How the hell do I stop them? Rate limiting also does not help because that is more expensive to handle than Firestore's one read cost.

Help me please!

Anyone experiencing 500 error? Cloud function v2 it seems. US Central 1

UPDATE 22:25 UTC: Google appears to have fixed it. Cold starts are working again (seen i n us-central1) even for functions still on automatic updates. The on-deploy redeploy below is still a valid fallback if it comes back. Outage window seen: about 21:15 to 22:25 UTC.

FIX (works immediately, confirmed by several people): redeploy each function with the runtime pinned instead of auto-updated.

gcloud functions deploy FUNCTION_NAME --gen2 --region REGION \ --runtime-update-policy=on-deploy --source PATH_TO_BUILT_FUNCTIONS

• It keeps the function's triggers, secrets and settings.
• For --source, use your functions folder after building it: package.json, package-lock.json and the compiled output, no node_modules.
• A normal firebase deploy does not fix it: it keeps automatic updates on, so the function lands on the same broken runtime.
• One deploy per function, so script it if you have a lot. I'm running 6 at a time.

Write-up with checks, a curl probe and a one-liner listing the functions still on automatic updates: https://gist.github.com/mrbenji/5da8f50a875b8e0bbb7141bd24caa726

What's happening

Since about 21:15 UTC (2:15 PM Pacific) on Oct 22, 2nd gen functions on Node 22 can't start new instances. It's been reported in us-central1, us-east1 and northamerica-northeast1, across manyunrelated projects. Google's status page shows nothing yet.

• Warm instances keep working, so it looks intermittent.
• Callables show up in the browser as CORS errors, because the OPTIONS preflight returns 500.
• Firestore triggers and scheduled functions fail too.
• Cloud Run reports "container failed to start and listen on the port ... within the allocated timeout," and the container writes no logs at all.

It's Google's side, not your code: a five-line hello-world Node app fails the same way on the auto-updated Node 22 runtime and works with automatic updates off. New Node 22 base images (22.23.4) were published that day.

Check whether you're affected

gcloud functions describe FUNCTION_NAME --gen2 --region REGION --format='yaml(buildConfig)'

automaticUpdatePolicy means it's on automatic updates; onDeployUpdatePolicy means it's pinned.

Afterwards: Firestore-triggered functions without retries drop failed events, so plan a backfill for anything that happened during the outage. If you're affected, please reply with your region and open a support case so Google can see how widespread this is.

Please help me out. I made a website, and I heard that Firebase will shut down in 2027. How can I export my files?

Hi everyone,

I'm investigating a sudden increase in crashes in my Android app and would appreciate some help identifying the possible cause.

What I'm seeing:

• App version: 1.0.2 (22)
• Firebase Crashlytics reports 86 crash events affecting 71 users.
• Device distribution: OnePlus 8 Pro — 76%, Huawei — 15%, Huawei HRY-LX1T — 9%.
• Most of the reported crashes appeared within a short period around October 18–19, 2026.
• The crash-free user rate for the selected 90-day period is 99.71%.

Main crash types:

1. PrivacyWebViewActivity.onCreate — NullPointerException
2. IntroLoadingScreen.onCreate — JSONException
3. ProxyBillingActivity.onCreate — NullPointerException
4. MainActivity.loadCategoryData — ArrayIndexOutOfBoundsException
5. BinderProxy.transactNative — TimeoutException

I'm trying to determine whether this could be related to a OnePlus 8 Pro/OxygenOS issue, Android System WebView or Chrome compatibility, a problem introduced by the app release, or unusual automated activity.

I haven't confirmed the root cause, and I don't want to assume it's a bot attack without evidence.

Questions:

• Has anyone experienced a similar device-specific crash pattern with Firebase Crashlytics?
• Are there known OnePlus 8 Pro, OxygenOS, or WebView issues that could explain these crashes?
• What would you check first to distinguish a device compatibility issue from an application bug or automated activity?

I can share relevant stack traces and additional device details if needed.

Thanks!

If you’re a rtd heavy user like me, with frequent json update and delete, you can checkout this open source platform. This will help you to frequent update the json on your firebase rtd within the firebase. And deletion won’t give you nil. Best part, you can publish your edited json with one click using the extension.
Any feedback will help. Thanks in advance.

An open task can match your status filter and still disappear when you add orderBy("priority"). Firestore excludes documents that do not contain the ordered field; a larger limit will not bring them back.

Try a tiny fixture: triage has status "open" and priority 1; review has status "open" but no priority. The status query returns both. Adding orderBy("priority") returns triage. review has not been deleted.

Before backfilling data, remove the ordering on a bounded test query, inspect the actual stored key, and decide whether priority should be required. Keep permission and index errors visible instead of turning every failure into an empty array. Reset pagination when changing the query.

Disclosure: I work on Cengal, a Firestore workspace for Mac. We documented this example with synthetic emulator data and AI assistance; it is not a production Rules, index, billing or UI test. You do not need our app to use the check.

Firebase reference: https://firebase.google.com/docs/firestore/query-data/order-limit-data

Full three-document example: https://cengal.app/guides/firestore-orderby-missing-documents/

Just found out that Firebase Extensions are going to be shutdown, however my project is actively using storage-resize-images extension. Are there any plans to provide function kit replacement? Or they only way is forking?

I tried using 2 different cards, but same message saying unable to send code...

Is anyone else experiencing delays with Firebase Analytics? 🤔

My Firebase data is heavily delayed, and I’m still not seeing yesterday’s user data.

Is anyone else facing the same issue, or is it just me? 👀

#Firebase #GoogleAnalytics #DevCommunity

Hey guys, I’m using Firebase for my Flutter app and currently on the Blaze plan. My dashboard shows $300 in free trial credits expiring on Oct 20, 2026.

The app has around 500 potential users, and about 400 might listen to audio recordings (around 5 uploads per week, mostly 5 mins each, plus a 30-min Jummah Bayan).

After the credits expire, will I automatically start getting charged? Any idea how much this setup could cost monthly? Also, is there anything I should change to avoid unexpected bills?

Appreciate any advice!

Hi everyone! I'm an indie developer using Firebase Analytics and Crashlytics in my Unity mobile game, Potionmancy.I'd like to know: What Firebase features do you recommend for mobile games?

Thanks!

I’m in the creative phase of building my dating app, but Firebase requires me to upgrade and potentially pay €25 just to enable profile photo uploads. My app isn’t even launched yet, and I’m already facing costs before I can fully explore my idea. Why should creators have to pay before they can even see what their product could become?

Post Body:

Hey everyone,

We are running into a perplexing issue with Firebase Analytics / GA4 mobile event tracking when routing app events through a Server-Side Google Tag Manager (sGTM) endpoint. We need some fresh eyes on this after i tried all AI suggestions etc!

The Problem:

When we enable the sGTM endpoint toggle in our app/data stream, events stop reflecting on the GA4 Realtime dashboard in Release builds.

Here is the exact behavior:

1. Debug build on Android/Firebase DebugView / sGTM Preview mode: Everything flows perfectly! The GA4 - App client claims the payloads, tags fire, and events land in GA4 Realtime as expected.
2. Release builds: The initial journey (e.g., Biometric Enablement / App Launch) lands on sGTM and GA4 fine. However, all subsequent journeys/events after that first journey fail to land on sGTM entirely.
3. When sGTM toggle is DISABLED: All events across every journey flow normally to GA4 directly via standard SDK endpoints in both Debug and Release builds.

Network & Infrastructure Context:

• Initial Blocker: We initially discovered that our F5 WAF had payload size limits blocking traffic, which we increased.
• Front Door Behavior: Azure Front Door logs show 204 No Content status codes for requests hitting the endpoint, indicating the edge layer receives and accepts the traffic.
• The Missing Link: Despite Front Door returning 204, subsequent events after the first journey never actually land on the sGTM container at all.

What We Have Verified:

• sGTM Client: Active GA4 - App Client installed.

What We Suspect:

Since initial events hit sGTM but all subsequent app events vanish before reaching sGTM in Release builds:

• Is the Firebase SDK / GTM SDK failing or halting batching/dispatching after the first request when sending to a custom sGTM URL in Release mode?
• Could R8 / ProGuard code minification / stripping be breaking the internal queuing/serialization mechanism of the Firebase event dispatch thread in Release builds?
• Is there an issue where session state, SSL connection reuse, or custom endpoint URL persistence breaks inside the mobile client after the first HTTP call?

Has anyone encountered a scenario where the first mobile journey events reach sGTM cleanly, but all subsequent journey events are completely dropped on the client side before hitting sGTM in Release builds?

Any insights, SDK dispatch debugging tips would be immensely appreciated!

Thanks!

Hello everyone, I'm running a beta testing campaign by distributing and installing the Android mobile app through the Firebase App Distribution .

On a Lenovo tablet running Android 10, after being able to install different versions, from a certain version the Firebase App Distribution app no longer allows me to install, it tells me that it is impossible to install the app after clicking the "Install" button.

However, on other devices this installation is possible, I do not understand what it might be due to.

Since firebase-tools 15 the Firestore emulator needs Java 21. It also has a few long-standing pains: 0.74 s to start (2.5 s through the CLI), 95 MiB idle, and batch writes that get slower and slower while a listener is attached (firebase-tools#3477; 121 s for 100k documents in my runs).

I've released hidane 0.1.0, a replacement that is a single binary. You keep your firebase-tools setup and put hidane exec -- in front:

curl -fsSL https://hidane.dev/install.sh | sh     # or brew / npm / cargo / docker
hidane exec -- firebase emulators:start --only firestore

No JDK needed. On my machine it opens its port in 5.5 ms, idles at 7.4 MiB and writes the same 100k documents with a listener in 4.9 s. These weren't measured side by side with the official numbers, so take the comparison as rough.

Checked against the official emulator:

• documents, queries, aggregations, vector search (findNearest), transactions, listeners;
• the Admin SDK, the Web SDK in Node, the Lite SDK, and the Web SDK in the browser;
• @firebase/rules-unit-testing contexts and clearFirestore(), without rules;
• the Emulator UI (browse, edit, clear), and --import / --export-on-exit in the official format, both ways.

How it stays compatible: every behaviour is first recorded from the official emulator and then replayed against hidane in its test suite, so error messages and snapshot events match. Where the official emulator is buggy, for example listeners going silent after a reset, the difference is documented instead of copied.

Not there yet: Security Rules (coming in v0.2; every request is allowed for now), and verification with the Go / Python / Java / mobile SDKs. If your tests don't depend on rules, it can replace the official emulator today.

If you run your test suite against it and find an answer that differs from the official emulator, that's the most useful feedback right now.

https://github.com/hidane-dev/hidane

(Not affiliated with Google.)

Basically to serve text and images only for a native android app.

Hi Guys! I am facing this problem while trying to authenticate using a new phone number. I am using firebase phone number authentication. The following suggested things are already done.

1. Sha1 and Sha256 of debug, release and playstore are already in firebase settings under this project.

2. Play integrity api is enabled and added in permitted apis.

3. Firebase -> App checks -> Play integrity API advanced settings ->"
   Require app integrity label PLAY_RECOGNIZED is disabled
   "

4. Google Clou console credentials - android and Browser api keys have been added with Play integrity api too.

5. Google-services.json file has been newly added (I am not sure if this changes with all these change - I try to open everytime and its the same)

I need you help in understanding why still this is causing issue. Does anyone have any solution? Am I doing something wrong entirely? Kindly help.

my app uses rtdb with a lot of small reads. budget alerts are set up, but if a reddit post blows up overnight i'm asleep anyway. what do you actually do about that? limits in functions, a kill switch, just hoping? any bill that surprised you ?

Have started to get

400 - INVALID_ARGUMENT, "Request contains an invalid argument."
responses from FCM on requests that used to work . They all have in common that they use the ! operator as a condition.

Like

"condition": "'a' in topics && !('b' in topics)",

Anyone else noticed a change?

Hi, Firebase PM here.

We are actively investigating an issue where some Firebase Hosting projects on the Blaze plan are intermittently encountering "Bandwidth Quota Exceeded" serving errors.

If your site is currently serving quota errors or failing to deploy, you can resolve the issue immediately by ensuring the Firebase Hosting API is enabled for your Google Cloud project:

1. Open the Firebase Hosting API page in the Google Cloud console
2. Select your affected project from the dropdown selector
3. If the button displays Enable, click it to activate the API (if it says Manage, the API is already active)

Once enabled, your project's Blaze plan limits will apply immediately, restoring normal site traffic and deployments.

Sincere apologies for the inconvenience. Our engineering team is actively investigating the root cause and working on a permanent backend fix. We will continue to report updates on the Firebase Status Dashboard.

Has anyone run into this issue? It happened last night and resolved itself, but now it's happening again.

Hello everyone, I'm exhasusted , Despite already importing the .env to vercel (which I'm using to deploy) This keeps happening.