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.

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

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.)

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?

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

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.

I’m looking for an easier way to test Firebase Analytics. Manually simulating the user journey every single time to debug events is exhausting. On top of that, my team shares the same Firebase project, so the device dropdown menu is flooded with over 100 devices—90 of which are named "Apple arm64." It takes forever just to locate my own simulator.

Has anyone built an open-source GitHub tool or Model Context Protocol (MCP) that can simulate the journey and automatically log/document the events that hit DebugView?

What's the deal with Scoreholio tonight? It went completely down right in the middle of tournaments!

If you've ever needed a valid ID token for some user just to curl your own API, this is for you.

Firebase Token Toolkit loads your service-account key, lists your project's users, and gives you a real ID token for any of them in one click - decoded claims underneath, copy button next to it. It passes verifyIdToken like a token from a normally signed-in user.

It also does:

• Custom claims: load, edit and save a user's claims as JSON, with the 1,000-byte limit checked as you type
• App Check: exchange a registered debug token for an App Check token
• Web, Android and iOS apps: "Load apps" imports your project's apps; keys restricted to an Android or iOS app work, because it sends the package/SHA-1 or bundle-ID headers Google checks for
• Profiles for dev/staging/prod projects

Linux, Windows and macOS. MIT licensed, no telemetry.

GitHub: https://github.com/smaranjit/firebase-token-toolkit Guide (with screenshots): https://smaranjit.github.io/firebase-token-toolkit/

Please use it with a dev project - a service-account key can sign in as any user. Feedback and issues welcome.

Hi r/Firebase, I'm Jerry. In July 2024 I built Firexport, a Chrome extension that adds an Export button to the Firebase console. Turns out a lot of you wanted that button too.

Then I left it alone for over a year. Work got busy, changes felt risky, and it worked. Meanwhile it kept growing: monthly installs went up about 7x, and it's at about 3,000 users now. That felt great for a minute, then like a responsibility I'd been ignoring.

When I came back in August, "it works" wasn't quite true. Exports could quietly stop early, and CSV values could slide into the wrong columns, all without an error. If that ever bit you, I'm sorry. It's fixed, and Firexport now warns you when an export doesn't match Firestore.

Building is a lot lighter now (AI tools helped), so I've shipped 12 releases in six weeks, and it's the most fun I've had with it since the start. It's also growing past export: a read meter for the reads the console itself costs you, recent queries, a query builder for Enterprise databases, and export for Auth users, rules and indexes. All free, with a paid tier for exact-value exports.

If you tried it before, give it another look. And what's the one thing you wish the console did? I'm picking what to build next from the replies.

https://firexport.dev

I’m currently working on the backend/database side of a project where I’m planning to use both Firebase and MongoDB. I’ll be using Firebase for authentication and media storage, while MongoDB will handle everything else, including storing the paths/references to the media in Firebase Storage.

I’m almost a beginner in backend development and database design, so I’m trying to learn more about the best way to structure and integrate these two technologies. Does anyone recommend any articles, tutorials, courses, or other resources? Or know some tips and best practices using Firebase and MongoDB together.

When I checked my domain's IP history, I found IPs that appear to belong to Google (App Hosting). My concern: if someone sends requests directly to these IPs with my domain in the Host header, will App Hosting serve my site and bypass Cloudflare?

As far as I know, App Hosting doesn't support IP allowlisting. My plan is to have Cloudflare add a secret header via a Transform Rule and reject requests without it in middleware. Is this the recommended approach, or is there a native way to make App Hosting accept only Cloudflare traffic?

Also, does anyone run App Hosting with the Cloudflare proxy (orange cloud) enabled without SSL or cert renewal issues?

I’m currently developing a web app that runs on Firebase Cloud. Based on the status shown here, all the previous data appears to be properly synchronized. However, newly entered data is not being uploaded or synced to the cloud.
I’ve checked everything multiple times and also tried pulling the data and uploading it again, but the result is still the same. The existing data can still be synchronized, but the newly entered data is not being uploaded to Firebase.
Does anyone have an idea where the issue might be? Could it be related to the Firebase configuration, authentication, database rules, or the write/sync process between the web app and Firebase?
I’d really appreciate any advice or insights from anyone who has more experience with Firebase or has encountered a similar issue. Thank you! 🙏

Hola a todos. Sigo documentando la evolución técnica de mi proyecto Supervisor Global. En el devlog anterior les conté cómo un desastre de infraestructura me obligó a migrar a Firebase para conectar mi bot en Python con una futura página web. Hoy quiero contarles cómo esa web pasó de ser una idea a una herramienta funcional, y cómo gamificamos su crecimiento.

El Muro de la Autenticación (OAuth2**)

Teníamos los datos del bot subiendo a la nube, pero el Dashboard web necesitaba saber quién estaba detrás de la pantalla para mostrar información sensible. No podía hacer un login con contraseñas; la única opción profesional era integrar el inicio de sesión oficial de Discord (OAuth2).

Lograr que el flujo de redirecciones funcionara rápido fue un caos de tokens y validaciones. Pero cuando encajó, el puente se completó: el usuario inicia sesión, Discord valida su identidad y mi frontend consulta a Firebase usando ese ID único. Así logré que el panel cargara instantáneamente el perfil privado del usuario, mostrando su avatar, su ID y su saldo exacto en la economía del bot.

El "Simulador" de Ajustes y Estadísticas

De nada servía una web si los administradores no podían controlar al bot desde ahí. Me enfoqué en construir un Panel de Control en tiempo real.

Implementé interruptores y campos de texto donde los dueños pueden activar el Auto-Role, personalizar mensajes de bienvenida o configurar el "Multi-Rol Temporal" (útil para vigilar roles de castigo como "Huérfanos" por un tiempo definido). Además, programé un apartado de "Estadísticas Avanzadas" que genera gráficos de actividad semanal y tablas de clasificación en vivo con los usuarios con más horas en voz y más mensajes. Fue como armar un panel de mando de un avión para los administradores, todo conectado al bot de Python a través de Firebase.

Simplificando la entrada: El video explicativo

Con tantas funciones complejas, me di cuenta de un problema: la gente nueva entraba a la página y no entendía rápido qué hacía el bot. La solución fue limpiar la interfaz de inicio y añadir un botón directo de "▶ ¿Qué hace?". Integrar este video explicativo directamente en la web fue clave para que los usuarios pudieran ver al bot en acción antes de invitarlo.

La Gamificación: La Meta de los 100 Servidores

Para cerrar esta etapa, decidí conectar el crecimiento real del bot con una mecánica visible en la propia web.

Añadí una barra de progreso pública en el inicio: la META GLOBAL: /NUKE. El objetivo es llegar a 100 servidores activos de forma colaborativa. Actualmente estamos en 64 servidores, y la promesa está bloqueada en el código: al llegar a los 100, se desbloqueará el comando definitivo para todas las comunidades y se entregará la insignia exclusiva de "Pionero" a los que ayudaron al principio.

Si quieren ver cómo interactúa este panel de control con Discord, pueden darse una vuelta por supervisorglobal.com

En el próximo Devlog me alejaré de la lógica pura y me meteré en el diseño frontend: les contaré el dolor de cabeza de armar el sistema visual de rangos y medallas en el Dashboard usando animaciones CSS puras para mantener la web rápida. ¡Leo sus experiencias con OAuth2 en los comentarios!

Thanks for your patience while we finished the migration path for the Firebase Extensions deprecation. We've closed the major feature gaps between Extensions and Functions, and released Function Kits.

A Function Kit is an npm library that the CLI installs into your Functions codebase. firebase functions:kits:install downloads the public npm package and adds a small amount of boilerplate to export its functions. As with Extensions, you can install multiple instances of a kit (for example, backing up several Firestore collections to BigQuery).

Kits are 2nd gen functions, so you will continue to get runtime updates and can use features like custom CPU and concurrency to tune cost and performance. Because the publisher's code and yours deploy together, we'll later be able to replace some patterns, such as HTTP transform callbacks, with direct in-process calls.

We've also updated the Extensions commands:

• ext:list shows whether the publisher has released an official successor kit for each extension.
• ext:export can write params in the format Functions uses
• ext:migrate walks you through migrating an extension instance to a kit. You can keep the extension during the migration and delete it later.

See the migration guide for exactly what ext:migrate does, so you can check things before deleting the extension.

Firebase is officially live in the Codex Plugin Registry! 🚀 Empower Codex with agent skills, a local MCP server and the Firebase CLI -- all into one seamless tool. Now you can use simple prompts to have Codex:

🔥 Setup projects and databases

🔐 Build complete auth flow (like Google Sign-in)

🛡️ Write and audit your security rules for production

🚀 Deploy and ship apps faster

⬇️ Install the plugin here

After talking to a few founders, I realized most of them were building an internal tool by stitching together what we were trying to build

So, we open-sourced our product and have 6 stars so far - I know it's very few, but it feels great

Please find the repo link: https://github.com/preburn/preburn

What it does

Preburn is a real-time margin control plane for AI products. Two things nothing else does together:

1. Joins per-customer revenue (Stripe) with per-call cost across all your AI providers (OpenAI, Anthropic, Kling, Veo, ElevenLabs, whatever) to show actual margin per customer.
2. Sits in the request path and can allow/deny/route BEFORE the expensive call fires. Auto-route heavy users to cheaper models, cap runaway accounts, cancel voice/video sessions mid-stream if credits blow out.

Not observability (that's Langfuse/Helicone). Not a gateway (that's LiteLLM/Portkey). Different job - cost visibility tied to revenue, with enforcement.

We're about to ship a Flutter (iOS-first) app and I'd like some inputs on our subscription and auth setup from people who've done this in production.

Current setup

• Auth: Firebase Anonymous Auth by default, so the core features work with no sign-up. Sign in with Apple is optional and never required for a trial or entitlement.
• Purchases: RevenueCat handles the paywall and purchase flow. The 7-day trial is Apple's intro offer.
• Source of truth: our own backend (Firebase Functions, Node/Express). Every AI request is gated server-side, and the client never decides access on its own. The backend reads the entitlement from Firestore.
• Ownership: a subscription belongs to Apple's originalTransactionId, not to a Firebase UID. Each one has a subscription_owners/{originalTransactionId} doc pointing at the current UID.

How we keep things in sync (this is the part I'd like opinions on)

1. The RevenueCat webhook updates Firestore. It's idempotent by event ID and ignores stale events by timestamp.
2. App Store Server Notifications V2 is a fallback for owners that RevenueCat doesn't manage.
3. The client caches the entitlement in the Keychain with a 6h TTL and force-refreshes on app resume if the cache is stale.
4. The backend also polls the App Store Server API on the request path. It checks every 6h normally, every 15 minutes in the last day of a period, and every couple of minutes right after expiry. There's a timeout and a circuit-breaker pause on failures.
5. Restores under a different UID transfer ownership. We ignore RevenueCat's TRANSFER events on purpose, because the public SDK key lets anyone post a receipt under any app user ID.
6. When a guest signs in with Apple, we merge the guest into the Apple account server-side: subscription owners, progress and history. Then we call syncPurchases() under the new UID.

What feels painful

• We have three sources (RevenueCat, Apple notifications, Apple polling) plus a client cache, and they can disagree for a few seconds or minutes. Most of our bugs have been races between them, like a webhook arriving before a restore, or a merge happening mid-purchase.
• Guest to Apple-account merging and UID changes are where most of the complexity comes from.
• Entitlement logic is split between RevenueCat's CustomerInfo on the client and our own Firestore record on the server. We chose this so a modified client can't unlock anything.

Questions

1. Is the client-cache + webhook + server-poll setup normal, or is it overkill? Do most people just trust CustomerInfo on the client, or use RevenueCat's REST API as the server-side check instead of polling Apple?
2. Has anyone used the official RevenueCat Firebase extension and found it good enough? Does it handle UID changes and restores cleanly?
3. For anonymous to real account upgrades, do you use Firebase linkWithCredential, or merge server-side like we do? We avoided linking because of invalid-credential issues with Apple and nonces.
4. Is there a library or pattern that keeps Firebase Auth UID and subscription ownership aligned without hand-written merge logic?
5. What are we likely missing?

Happy to share more detail on any piece. Thanks!

Hello, site is hosted on Google AI Studio: can't it be published on Firebase without using CLI? If yess, how?

i try to create a website with google AI studio and i also integrate Firebase Authentication but for some reason the firebase client is offline even if my firebase work just fine. It work just fine before do anyone know how to fix this? please help me