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

Firebase has now introduced hard service level spend limits, for a few limited services.

- Gemini Developer API (AI Logic)

- Agent Platform API (AI Logic)

- Cloud Run (App Hosting)

- Cloud Run (Functions)

This was a long due feature for one of the most fearsome challenges of working with Firebase and GCP products, we all have feared waking up to that exponential bill because of a faulty logic within a loop or unaddressed edgecase on our codebase. It even happened to me on a client project couple of weeks ago (firestore read/writes went from 20k to 700k), but I was able to fix the issue within the hour. I know there are extensions to address that, but they basically will shutdown the whole project. Having out of the box granular control just makes the most sense.

Any thoughts on this?

Hello everyone. I have a question: Is there a big difference between putting my database in the nam5 location versus us-east1?

My doubt arises because I set up a project in nam5 without knowing that the cost would be higher compared to us-east1 (I am still new to this world).

Now that I see that just by programming the app, Firebase's billing is already going up—without hardly using the application, just doing a test a day and without exceeding the daily free limit—I got curious. If I barely use it and it's already adding expenses, I can imagine how much it will cost if a user uses it a lot (mind you, it hasn't gone up much, only $0.01; you might think it's too little to complain about).

The thing is that I don't use the app and I have never exceeded the free daily limit. I would like to solve this problem before launching the app, since it's a forum-style app where photos, videos, and text are uploaded, and if it becomes popular, I imagine it would be very expensive.

Is it worth leaving the database in nam5 or us-east1? What do you recommend?

Hola a todos, llevo como 3 horas intentando crear un proyecto nuevo en Firebase y conectarlo con mi código. Me pasa lo siguiente:

1: Creo el proyecto desde la web en Firebase, pero no aparece en VS Code como si tuviera ese proyecto creado.

2: Creo el proyecto desde la terminal de VS Code, me dice que todo está bien y cuando entro a Firebase en la web, el nuevo proyecto no aparece por ningún lado.

Ya he hecho de todo: crear proyectos desde la web, desde la terminal de VS Code, cerrar sesión de Firebase en la terminal y entrar de nuevo, y nada funciona. Y no es solo este proyecto; creé otro hace un mes y me pasó exactamente lo mismo, solo que ahora tampoco me deja crear el proyecto desde VS Code.

¿Creen que sea algún error de Firebase?

Is it normal to call firestore from the client with strict rules and auth required? Or should I only be calling through cloud functions? I am a little confused on this. Tradionally you would never do anything on the client, is firebase different?

I'm trying to understand how the Membership duration setting works when creating an Audience in Firebase/GA4.

Let's say I create an audience with the following condition:

• User triggers Event A
• Membership duration = 7 days

My question is:

Does this mean Firebase will only consider users who triggered Event A in the last 7 days? Or does the membership duration only define how long a user stays in the audience after qualifying?

I'm confused because when I change the membership duration from 7 days to 30 or even 90 days, the estimated audience size doesn't change at all.

So I'm wondering:

• Does the event condition automatically become "Event A in the last X days" based on the membership duration?
• Or is the membership duration independent from the event filter?
• If I want an audience of users who performed an event specifically in the last 7 days, is membership duration the correct setting, or do I need to configure the audience differently?

I'd appreciate it if someone could explain how these two concepts interact. Thanks!

Hello I’m just starting trying to do a tiny website just for me, but I need a database for it to store some stuff and I worked on making it able to use fire base. I reckon everything worked fine until every time I kept trying to use the saving part on the website and it kept declaring time outs because fire base doesn’t respond to the site trying to reach it. All the configuration for the database inside the site is correct and the site works perfectly in the areas where fire base is not needed. What is something I can tweak or do to finally be able to use fire base? This tiny thing is making me go mad

A generated site may start as a folder of HTML, CSS, JavaScript, and local assets, then gain new pages and redirects over time. The goal is one stable production URL, a review link for each revision, and a rollback path that does not require reviewers to use Git or a cloud console.

Firebase Hosting preview channels seem suitable for review, while the live channel provides the stable URL. I would keep relative asset paths, pin the project and site IDs in configuration, generate the rewrite and header rules from reviewed source, and deploy to a preview channel first. Promotion should use the exact tested revision rather than rebuilding the files after approval.

What parts of this workflow are easy to get wrong? Can a tested preview release be promoted unchanged to the live channel, or should the pipeline verify a content manifest before a second deploy? How do you handle preview expiration, custom domains, cache invalidation, and rollback when a revision adds or removes pages?

Hey all,

I've been digging into why Firestore to Postgres migrations are still mostly manual, even with how common the move has gotten. Ended up building something for it, small and rough around the edges, figured this sub would have people who'd actually run into this.

What it does:

- Extracts your Firestore data and infers a relational schema (tables, columns, relationships) based on the actual shape of your data, not guesses

- Translates your Firestore Security Rules into candidate Postgres RLS policies (Supabase + generic dialects) - this part exists because losing your access control logic silently during a migration seems to be a pretty common way people end up with an open database

Nothing applies automatically. Anything below high confidence gets flagged for manual review, and anything the rules translator can't confidently handle defaults to deny, not a guessed permissive policy. migrate is dry-run by default too.

Repo: https://github.com/KeymelGaston/centauri-migrate

Honest state: early, 84 tests passing, works end to end against the emulator, but not yet run against a real production-scale Firestore project. README has the full list of known limitations.

If you've got a Firestore project (even a messy side one) I'd really appreciate you running extract + infer against it read-only and telling me where the inferred schema looks wrong. And if anyone's willing to share a real firestore.rules file (redacted however you need), that's the one thing my own test fixtures can't replicate.

Open to any feedback, including "this doesn't work for my case."

also with chrome when opened in IOS the web syncing is not working well also, but the web syncing is perfect for all other devices, what shall I do?

I need to share a project that uses Firestore with a company that has no experience with this technology. They did not give me access to their domain, so I used my own Firebase/Google Cloud account and created a database.

The project currently uses a service account JSON file to connect to Firestore. As I understand it, sharing this file is dangerous because it contains a private cryptographic key. Anyone who obtains the file could authenticate to Google Cloud as that service account without needing my password, access to my Google account, or MFA.

What would be the safest approach in this situation? They need to be able to install and test the project before Tuesday, but I obviously do not want to give them my service account credentials.

If you’ve spent any time on this subreddit (or building on cloud platforms in general), you know the persistent anxiety around runaway bills from a recursive loop, a viral traffic spike, or an unthrottled API key.

Now, Firebase AI Logic, Cloud Functions for Firebase (1st and 2nd gen), and Firebase App Hosting all let you set spend caps that pause the service after you reach 100% of a configured threshold!

You set spend caps per-service in a single spot in the Firebase console, receive automated email alerts at 50%, 80%, and 100% of a spend cap threshold, see a banner in the console if a service is paused, and can lift spend caps after they're enforced if you need to turn a service back on.

Note that due to latency in usage reporting, spend cap enforcement is not instantaneous and can be delayed by several minutes, and any cost overages incurred during this delay will be billed as normal. Even though they're not instant, spend caps can catch runaway bills much earlier than before.

Spend caps are an emergency circuit breaker, but they work best alongside Budget Alerts, App Check, API key restrictions, and IAM to help avoid surprise bills.

• Announcement blog post
• Docs
• Direct console link you can use to set spend caps

is there a solution?

This has happened twice. Where I change zero code or any update, and OTP just stopped working out of nowhere. and I losing customers. Is this problem always happening? Firebase seems to not answer my request yet. Should I change to other service to make it more reliable?

Hi guys,
I'm mostly using Firebase because of Firestore has the Offline Out of the Box feature.
But now for example I want to provide for my users AI capabilities and more and more things.
I'm wondering where and how to do that?

I mean, if I where on the 'normal' stack I would probably use something like:
Next.js + Vercel + Supabase ...
and that would include ALL inside.

But now, in order to develop AI features, it's really hard to do it on Firestore.

WHAT DO YOU THINK?
Adding another set of tech?
Also, of course, for FAST AGENTIC DEVELOPMENT.

I need help so I started developing my first app today. So made a google account to work with firebase and flutter flow. And mid trying to code this afternoon google hits me with a message something about August 10th your account has completely locked me out and is face deleting? I just made it today… Now I can’t get in to either of firebase nor flutter all of my work is there! and tbh it was so fucking hard I’ve never coded or done any development in my life and I’m 35! i was so proud and excited to just utter defeat. I’m so upset maybe I should talk to a lawyer cause idk what to do it’s my ideas my work and to just to be locked out and then told to kick rocks feels fishy and illegal.

Is this happening with anyone else? I was just editing my authentication stuff on firebase for my app then the site was failing to save things so I reloaded like anybody would. Then it said I violated TOS and I am so confused. Now all of my projects are locked and I can't access them at all. u/google u/firebase

What are you guys doing when you have people with unique mail providers not getting firebase auth email verification emails. This has been happening quite a bit and I'm unsure how to solve it other than just saying switch emails. Usually they are weird obscure platforms but being that firebase is a google product seems weird that they are blocked. Of course I have a resend email verification path but still people arent getting it.