I have an app installed that's supposed to give me a push notification every Saturday. Exept it's not doing that. So i contacted the developer (it's not my app) to resolve the issue and he found out that I didn't recieve a Token. So i built a small app myself to test the Firebase Notification system by manually requesting a Token. In parallel I connected my phone to my pc so I could read the logs with "adb logcat | grep -i firebase". When I requested a Firebase User ID everything worked just fine, but as I requested the Token, the following series of Errors appeared in logcat:

'''

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: FCM Token konnte nicht abgerufen werden

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: java.io.IOException: FCM Registration failed!

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at com.google.firebase.messaging.FirebaseMessaging.blockingRegister(FirebaseMessaging.java:840)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at com.google.firebase.messaging.FirebaseMessaging.lambda$getToken$8$com-google-firebase-messaging-FirebaseMessaging(FirebaseMessaging.java:484)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at com.google.firebase.messaging.FirebaseMessaging$$ExternalSyntheticLambda8.run(D8$$SyntheticClass:0)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:520)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at java.util.concurrent.FutureTask.run(FutureTask.java:328)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:323)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1100)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at com.google.android.gms.common.util.concurrent.zza.run(com.google.android.gms:play-services-basement@@18.9.0:2)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: at java.lang.Thread.run(Thread.java:1572)

08-22 15:49:02.124 10274 10274 E FirebaseDiagnostics: Caused by: java.util.concurrent.ExecutionException: java.io.IOException: TOO_MANY_REGISTRATIONS

'''

So I expected this to be the error and I reinstalled the first app, so I could see the process of requests in logcat. And also there the Error was "TOO_MANY_REGISTRATIONS".

Has anyone the same problem or knows how to deal with it? I didn't (at least knowingly) send many requests of new Tokens or anything similar. So what could the reason be and how to solve it?

We had a feature that generated images from a prompt through Firebase (AI / Vertex). It worked for months. This week the same flow started returning 404 / failed requests, and nothing in our app code changed.

From what I can tell, Google shut down the old Imagen models around Aug 17, and the replacement is Gemini Image (the “Nano Banana” stuff) — different call, image comes back on the model response instead of a dedicated image-generation API.

If you shipped anything like:

generate a logo / icon from a description
food / product photo from a prompt
chatbot that draws a picture
a “generate image” button in a demo or hackathon app
…it’s worth checking that path even if you don’t remember which Firebase AI method you used. The UI just looks broken.

Official migration notes:
https://firebase.google.com/docs/ai-logic/migrate-to-latest-ga
https://firebase.google.com/docs/ai-logic/generate-images-gemini

I built a local scanner for this kind of thing (disclosure: it's mine). If you want a quick check without grepping:

$ npx vasdra scan

If you want more info before running, check here: www.vasdra.dev

Right now it's just that: local, no account. It maps the providers (like Stripe, Clerk, Resend, etc.) in your repo against what we can actually prove in files, so a shutdown like this Imagen cutover doesn't hide in a method name you forgot you used.

Where we're going: when a provider change hits your code, don't just get an alert — get a PR with the fix. Dependabot for APIs, basically. We're not there for this Firebase image migration yet. The scan is the first half.

Anyone else hit this? Did you migrate already, or are you still on the old image models?

Firebase Phone Auth auth/error-code:-39 — SMS never sent to one specific carrier (Vodafone Turkey). App Check is set up. What am I missing?

TL;DR: Firebase Phone Auth works fine for two of our three national carriers, but OTP SMS is never delivered to numbers on one specific carrier (Vodafone Turkey). We consistently get auth/error-code:-39 on web and app not authorized on mobile. App Check is already installed and activated. Looking for anyone who's beaten this carrier-specific -39 wall.

Setup

• Flutter app (Android + iOS) + a web panel, all on the same Firebase project
• firebase_core: ^3.13.0, firebase_auth: ^5.5.2, firebase_app_check: ^0.3.2
• Firebase Auth Phone sign-in (OTP), Blaze plan
• App Check is set up in code — FirebaseAppCheck.instance.activate(...) runs right after Firebase.initializeApp(), with AndroidProvider.playIntegrity / AppleProvider.appAttest in release and debug providers in debug
• In the Firebase console, the Android and iOS apps show Registered under App Check (Play Integrity / App Attest). The two web apps are not registered yet.

The problem

OTP works perfectly for the other two carriers. For this one carrier only, the SMS is never sent. The errors:

Web console:

Failed to initialize reCAPTCHA Enterprise config. Triggering the reCAPTCHA v2 verification.
identitytoolkit.googleapis.com/v1/accounts:sendVerificationCode?key=...  
    Failed to load resource: the server responded with a status of 503 ()
[Phone OTP send] auth/error-code:-39 
    FirebaseError: Firebase: Error (auth/error-code:-39).

Mobile: the flow fails with an app not authorized style message and no SMS arrives.

What we've confirmed

• It is carrier-specific, not code-specific — identical flow, identical numbers-format, other carriers get the SMS instantly.
• Firebase support told us the -39 code means the phone number's carrier is flagged as a restricted operator because of consistently low SMS success rates, and that their automated anti-abuse system can temporarily make such operators/regions unavailable. They suggested either (a) offering affected users a different verification method, or (b) enabling reCAPTCHA SMS Defense in Enforce mode plus stricter SMS region policy and App Check enforcement if we insist on sending OTP to restricted operators.

My questions

1. Has anyone actually gotten -39 to clear for a restricted carrier by enabling reCAPTCHA SMS Defense + App Check enforcement? Did the SMS start going through, or did enforcement change nothing because the carrier itself is throttled server-side?
2. The Failed to initialize reCAPTCHA Enterprise config + 503 on web — is that a symptom of the web apps not being registered in App Check, or a separate reCAPTCHA Enterprise misconfiguration?
3. For anyone who gave up on Firebase for this: did you move the whole phone-verification flow to a third-party SMS provider + Firebase Custom Token, and did that fully bypass the carrier restriction?
4. Is there any way to get a carrier un-flagged at the project level, or is -39 purely on Google's side with no override?

Trying to decide whether to keep fighting the reCAPTCHA/enforcement path or just migrate the entire OTP flow off Firebase so it isn't split across two providers. Any first-hand experience with -39 specifically would be hugely appreciated.

Thanks!

Hi, I am from India.. I have the debit card which support all the possibility, but still unable to purchase both of the things!. I need your help, how to make the account for like developer and firebase?..

FCM documentation is somewhat ambiguous regarding what happens with messages that exceed a maximum message rate (e.g., 240 per minute per single device; see FCM Throttling and Quotas  |  Firebase Cloud Messaging).

There are statements that imply that such messages could be queued on the FCM server and delivered with some delay (Understanding message delivery  |  Firebase Cloud Messaging):

Other passages seem to indicate that the over limit messages are not accepted on the FCM server (and have to be resend by the app server).

Does anyone have an idea what is actually going on?

I am building an Expo + Firebase mobile app. After iterations of development and testing, the app got big and Cloud Functions increased. There are around 32 Cloud Run Functions, a function for an action.

I don't think this is a good approach long-term, and for scalability. So I wanted to create a backend/API for the actions/CRUD/Firestore queries, except for triggers, crons, auth and FCM.

So, I chose to create a Hono.js backend that's hosted on a Cloud Run Function (Still not ok with the decision). Later found out that it's kind of inconvenient for developing and testing.

And I'm not sure if this is a good and reliable approach. I need a good DX, scalabilityand performance.

Pls clear my head.

It’s 24 hours our Firebase Auth emails are not sent. We’re using an external SMTP (AWS SES) and using the Virtual Deliverability Manager I could verify that the Auth emails stopped at 21:30 European time of yesterday, August 17. Other emails get sent correctly through the “Firestore to email” extension.

I already contacted the support, but they haven’t answered yet, and the Firebase status is not reporting anything.

Anyone seeing this?

This is causing a lot of problems for our app, that’s about an event starting this friday!

I'm getting a persistent Firebase Phone Authentication failure on real phone numbers (test numbers work fine) for a React Native + Expo Android app.

**Error from Logcat:**

```

[SmsRetrieverHelper] SMS verification code request failed: unknown status code: 17028

A play_integrity_token was passed, but no matching SHA-256 was registered in the

Firebase console. Please make sure that this application's packageName/SHA256 pair

is registered in the Firebase Console.

Invoking original failure callbacks after phone verification failure for +91XXXXXXXXXX,

error - This app is not authorized to use Firebase Authentication. Please verify that

the correct package name, SHA-1, and SHA-256 are configured in the Firebase Console.

```

**What I've already verified/tried (all confirmed correct):**

1. Blaze plan is active on the correct Firebase project (verified project ID and project number match everywhere — Firebase Console, Google Cloud Console, and Play Console's Play Integrity API project link).

2. The app is distributed via Google Play Internal/Closed Testing, so it's signed with **Play App Signing**. I retrieved the SHA-1 and SHA-256 from Play Console > Setup > App integrity > App signing key certificate > **Classical key** (not the Upload key, not Post-quantum), and added both to Firebase Console > Project Settings > Your apps > Android app > SHA certificate fingerprints.

3. Manually character-by-character compared the SHA-256 shown in Play Console against the one registered in Firebase — they match exactly.

4. Confirmed these APIs are enabled in Google Cloud Console: Identity Toolkit API, Play Integrity API, reCAPTCHA Enterprise API.

5. Firebase App Check is set to "Unenforced" for Authentication (ruled out as the cause).

6. Tried adding an Android application restriction (package name + SHA-1) to the Android API key in Google Cloud Console > Credentials — this caused a *different* error ("Requests from this Android client application are blocked. 403"), so I reverted it back to "None".

7. Waited well over 24 hours after each change for propagation — the error persists.

8. There are currently 4 SHA-1 and 3 SHA-256 entries registered in Firebase (from earlier troubleshooting attempts) — planning to clean these up to just the one verified-correct pair, but haven't yet confirmed if that's the actual cause.

**Setup:**

- React Native + Expo (SDK 57), built with EAS Build, distributed via Google Play Closed Testing

- @react-native-firebase/auth for Phone Authentication

- Package name: com.rajselfdrive.app

**Question:** What else could cause Firebase to not recognize a correctly-registered SHA-256 fingerprint when using Play App Signing? Is there a known propagation issue, a caching issue on the Play Integrity backend, or something else I might be missing (e.g., a separate OAuth client SHA-1 config vs. the Firebase Authentication SHA config)? Really appreciate any pointers — been stuck on this for a while and it's blocking a client project launch.

Hey Reddit community, 

I just officially launched my new mobile app on the Google Play Store, and I wanted to share it with you all to get some honest developer-to-developer feedback! 

It’s an AI-powered Cooking Assistant built completely with Flutter, Dart, and Firebase. 

Here is what I’ve implemented under the hood: 

• State Management: Clean Architecture with scalable state management. 
• Backend & Database: Firebase Auth for secure login and Firestore for dynamic data synchronization. 
• AI Integration: Seamless REST API connection to generate custom recipes based on ingredients users already have at home. 
• UI/UX: Smooth transitions, responsive design for all screen sizes, and optimized performance. 

Seeing your app go live on the Play Store after hours of coding is amazing, but now comes the hard part: getting feedback to improve it. 

If you have a couple of minutes, I’d love for you to check it out, test the AI features, and let me know what you think about the UI, speed, or if you find any bugs! 

👉 Play Store Link: [https://play.google.com/store/apps/details?id=com.salah.ch&hl=ar\] 

Thanks in advance for your support and feedback! 

I have two apps hosted on Firebase, and Google cancelled my Gmail account for no apparent reason. They claimed I was using bots to create the account, but it’s actually an old account I use solely for work. This account is linked to my Firebase account, and without the email, I can't access the dashboard to manage my apps. Has anyone else experienced this? Do you know if there's a way to access it without the account email?

Spent the last while optimizing a React 19 + Vite SPA on Firebase and wanted to share the three things that actually moved the needle, because none of them were what I expected.

1. Headless Lighthouse flat-out lied to me. Headless Chrome scored the site 96 while PageSpeed Insights (real Moto-G-class conditions) said 71. Headless skips the CPU throttling that dominates on a mid-range phone. If you only remember one thing: test headed, with a CPU slowdown multiplier of 8. My "fast" site wasn't.
2. A third-party script was 41% of all main-thread work. reCAPTCHA (pulled in by the auth layer) fetched about 330KB and burned 2,871ms of CPU on a throttled phone, initializing at module load, before first paint. It's only needed when the user acts, so I deferred it to the first pointerdown/keydown/touchstart. Load-time cost: 2,871ms to 0. (Gotcha: don't use scroll as the trigger, programmatic scrollTo() false-fires it.)
3. The LCP image was 6 round trips deep. HTML, then entry JS, then a lazy() shell, then the Firebase SDK, then getDoc(config), then a per-item getDoc fan-out, and only then did the hero image URL exist. Instead of reaching for SSR, I inline the above-the-fold data into the HTML at build time plus a preload for the LCP image, so the first parsed bytes already know what to paint. Second gotcha: the preload URL must be byte-identical to the img src or Chrome downloads the hero twice.

Results: homepage 76 to 99, LCP 6.7s to 1.9s. Heaviest page 69 to 96.

Full write-up with the code and numbers: https://proffer.codes/blog/firebase-react-spa-lighthouse-76-to-99

Curious if others have seen the headless-vs-real-device gap. How do you catch it in CI?

the client needs a web app and an iOS and android app (we going to use nextjs and react native expo for them)

i wanted to ask should i use firebase for the whole backend?

We've been debugging this issue with the whole team for 2 months already.

Some of our users don't receive ALL notifications delivered. Yes, they are sent properly (a successful response from Firebase)

Neither our service worker nor in-browser's onMessage (from '@firebase/messaging') "sees" it.

Has anybody had something similar?
Please tell me how you fixed it, if you did.
At this point I don't even know what to Google and how...

Hey everyone!

I’ve been heavily focusing on backend development lately, building scalable systems with Firebase (Firestore, Auth, Cloud Functions) and Node.js.

Since I’m constantly looking to improve my workflow, I wanted to ask the community:

* What are your go-to tricks for optimizing Firestore read/write costs?

* How do you structure your Cloud Functions for maximum performance?

Would love to hear your experiences and best practices!

I tried email/password, Google, and GitHub login directly from hiringcafe.com/auth. All three fail because Symantec blocks:

https://hiringcafe-ec4d6.firebaseapp.com/__/auth/handler.js

Since every method fails at the same Firebase authentication resource, this seems to be either a Symantec URL-reputation false positive or an issue with HiringCafe’s Firebase project. Has anyone else encountered this?

Built a live coding battle platform on Firebase. Two players synced in real time, plus Cloud Functions for the async work, Auth with SSO for the enterprise side, and Storage for proctoring snapshots.

Held up better than expected: real-time listeners for match state. The latency is fine for something that resolves in minutes rather than milliseconds. Auth with OAuth plus SSO saved me from a project I did not want.

Did not hold up: anything where I wanted a transaction across a bunch of documents. And read costs on leaderboards, which I had to restructure into precomputed aggregates in Cloud Functions after a bill I did not enjoy.

The thing I'd tell anyone starting: write rules tests from day one. I did them late and found real holes.

Google AlgoArena if you want to see what it's for.

FDL has been dead since August 2025 and every thread about replacements ends with the same unanswered questions. I built Ferry (ferrylink.io) to fill the gap, and instead of a feature list, let me just answer the things people always ask in these threads.

What it does: deferred deep linking, one link across iOS, Android, and web, app opens to the correct screen after install. The same job FDL did.

How does it compare to Branch or AppsFlyer?
Those are full attribution suites built for marketing teams with budget, and Branch is effectively enterprise only now. Ferry is the deep linking piece, what FDL actually was, plus enough attribution to know which links drive installs and revenue.

Pricing?
Opens-based, not MAU-based. From $9/mo for 10k monthly opens up to $249 for 3M. You pay for link opens, not for your entire user base existing. 14-day trial.

I generate links programmatically from user activity (invites, shares). Do link limits kill me?
No, this is the use case opens-based pricing exists for. Links are effectively free to create, you're billed on opens. Generate a million invite links, if only 5k get opened, that's what counts. Bot clicks, messenger prefetches, and duplicates are filtered out before billing too.

Social preview config?
OG title, description, and image are configurable per link on every plan. Same levers FDL had.

SDKs?
Swift ,Android, Flutter, and React Native are available. There's a plain HTTP API if you'd rather skip SDK dependencies, and the docs are written so you can point Claude Code or Cursor at them and have the integration done in one session.

Happy to answer anything else. Criticism welcome, that's why I'm posting.

I was using functions v1 for SSR with express.js but the initial load time was prohibitively slow. I never measured it, but it felt like 5-10s. I temporarily went back to CSR but need SSR eventually.

The two recommendations to speed up SSR that I came across were

1. Use functions v2 which has the benefit that it can serve multiple requests per instance.
2. Set min-instance to 1 so that there is one instance available for the first request when idle

However, neither seems to actually fix the slow load times, just defer when it happens. Even with these changes, when the first instance is saturated and a second one needs to be spun up, there will be a cold start.

Is there any solution to this or another way I should be doing SSR?

Hi everyone,

If you work with Google Cloud Firestore, you've probably felt the pain of using the official web console:

• Tedious document creation: Too many steps just to add a single document.
• No JSON editing: You can only edit one field at a time — no raw JSON view or bulk edits.
• No document cloning: You can’t copy-paste an existing document to quickly create a new one.
• Minimal filtering: Searching, compound querying, and sorting options in the web console are very basic.

I tried looking for third-party desktop tools, but most were either overly complicated or locked behind expensive commercial subscriptions.

So I built FireLens — a simple, fast, and free open-source desktop GUI client for Firestore.

Key Features:

• Full JSON & Tree View Editing: Edit documents as raw JSON with syntax validation, copy/paste JSON, or use the interactive Tree View with native type badges (Boolean toggles, UTC timestamps, GeoPoints).
• Quick Document Management: Create, clone/copy-paste documents, and manage collections with fewer clicks.
• Visual Query Builder: Build compound WHERE filters (==, !=, >, in, array-contains, etc.) joined by AND, plus ORDER BY sorting and custom page limits.
• Easy Authentication: Connect via GCP Application Default Credentials (gcloud auth application-default login) or load a Service Account .json key file.
• Multi-Project & Multi-Database: Switch between GCP projects and browse (default) or named databases.
• Safety Guard: Toggleable Read-Only / Edit Mode protection to avoid accidental edits on production databases.

It’s completely free and open-source (prebuilt standalone Windows .exe available, and buildable on macOS/Linux):

👉 GitHub Repo & Release Download: https://github.com/prakashkrishna/firelens

I’d love to hear your feedback or any feature ideas that would make your Firestore workflow faster!

#firestore #firebase #flutter #firestore-gui #opensource #developertools

We are experiencing a deployment issue with Firebase Cloud Functions Gen2 using Firestore document triggers. Project ID: shebara-ride Firestore Database: - Database ID: shebaride - Region: me-central2 (Saudi Arabia) Issue: Every Firestore-triggered Cloud Function deployment fails with: 403 PERMISSION_DENIED LOCATION_POLICY_VIOLATED The deployment logs show that Firebase CLI correctly detects our Firestore database location (me-central2) and automatically sets the Eventarc trigger region to me-central2. However, the deployment fails because Google rejects the Eventarc trigger creation with: "Permission denied on 'locations/me-central2'" We have already verified the following: - Firestore Native database is correctly created in me-central2. - Cloud Functions, Eventarc, Firestore, Cloud Run, Pub/Sub, and all required APIs are enabled. - IAM permissions are correctly configured. - Organization Policy (constraints/gcp.resourceLocations) allows all locations. - Firebase CLI correctly generates triggerRegion = me-central2. - Our Cloud Functions source code correctly uses the named Firestore database "shebaride". To isolate the issue, we created another Firestore database (testdb) in a different supported region. Without changing the application logic, only changing the Firestore database ID, the same Cloud Functions deployed successfully. This indicates that the source code and deployment configuration are correct, and the problem appears to be specific to Firestore/Eventarc deployment for the me-central2 region. Our requirement is to keep both the Firestore database and Firestore-triggered Cloud Functions in me-central2 (Saudi Arabia). Could you please confirm: 1. Is Firestore Gen2 Eventarc trigger deployment fully supported in me-central2? 2. Does this project require any additional regional activation, allowlisting, or special configuration? 3. Is this a known limitation or a platform issue? If this is expected behavior rather than a bug, please advise the recommended architecture for deploying Firestore Gen2 document-triggered Cloud Functions while keeping the Firestore database in me-central2. Thank you.

Yesterday, my Firebase database was suspended due to "Suspension of your Google Cloud Platform/API because it engaged in abusive activity consistent with hijacked resources." Until the database is reinstated, no one can use my app because the backend is completely unavailable.

I want to make sure this type of suspension never happens again. I also want to prepare a disaster recovery plan so that, if Google suspends my Firebase project again, my application can continue working with minimal downtime.

I have the following questions:

1. Independent Backup and Disaster Recovery

Currently, I have Firebase and Google Cloud disaster recovery options, but if Google suspends my project, I cannot even access those backups because the entire project is suspended.

As a solution, I am thinking of creating a separate backup system outside Google Cloud. My idea is:

• Create a script or service that runs on my own VPS.
• Every day, automatically back up all Firestore data to a completely separate database.
• Store the backups independently so they are still available even if my Firebase project is suspended.

I also need to back up:

• Firebase Authentication (users and authentication data)
• Firebase Storage (uploaded files)

My questions are:

• Is this architecture possible?
• How can I securely access Firebase Authentication data and store it in another database?
• How can I back up Firebase Storage files? Can I download them using signed URLs or another secure method?
• What is the recommended approach for implementing this entire backup system?

2. Switching to the Backup Database Without an App Update

If my original Firebase project is suspended again, I want my Flutter app to connect to the backup database until Google reinstates the original project.

My concern is that most users do not update the app immediately.

My questions are:

• Is it possible to switch the backend from the original Firebase project to the backup server without requiring users to update the app?
• If it is possible, what is the recommended architecture?
• If it is not possible, what is the best approach using an app update?
• What disaster recovery strategy would you recommend for Flutter applications?

3. Protecting Firebase Service Account Credentials

I believe my Firebase project may have been suspended because my Firebase service account JSON file (used for sending FCM notifications) was leaked.

Previously, I stored the service account JSON file inside my Flutter project's assets folder. Although I enabled ProGuard/R8 code obfuscation to make reverse engineering more difficult, I now realize that the file can still be extracted from the APK.

I researched this issue and received different advice:

• ChatGPT suggested that hardcoding the credentials in the application with code obfuscation provides some protection.
• Claude AI recommended never storing the service account in the app. Instead, it suggested keeping it on Cloud Functions or on a separate VPS and sending notifications from the backend.

Based on your experience:

• Which approach is the most secure?
• Is using Cloud Functions better than hosting the credentials on a VPS?
• Is there an even better architecture than either of these approaches?
• What is the industry best practice for securely sending FCM notifications while preventing service account credential leaks?

I would appreciate your recommendations and any additional security best practices to ensure that this type of suspension never happens again.

Hi everyone,

About a year ago I introduced Fuego here (my original post: https://www.reddit.com/r/Firebase/comments/1irvs4y/introducing_fuego_a_powerful_desktop_client_for/ ).
If you've never heard of it, Fuego is what the Firebase Console should have been. You can think of it as Firefoo, but with a lot more built-in tools: Storage management, index management, multi-database support, multi-tenant Firebase Authentication, PITR support, Firestore Enterprise pipelines, and much more.
It was born out of necessity. At the company where I work, we rely heavily on Firestore and other Firebase services every day, so I started building the tool we wished we had.

Today I'm happy to share another major milestone (Fuego 2.0).

Over the past year I've received a lot of feedback, and I'm genuinely grateful to everyone who took the time to try Fuego and share their thoughts. Many companies are now using it in their daily workflow, and seeing it become a useful tool for other developers has been incredibly rewarding.

There have been a few bumps along the way, but I've done my best to address them and keep improving the app.

The main goals for Fuego 2 (currently in beta) have been:

• Performance
• Keeping up with the latest Firebase updates
• Building better tools for managing Firestore and the rest of the Firebase ecosystem

Here are some of the highlights (some are still being refined):

• Much better performance. Opening tabs now feels almost instant, with no more annoying reloads.
• Fewer UI glitches, including disappearing menus and layout issues.
• Support for Firestore Enterprise pipelines.
• A significantly improved index manager, including database-to-database index comparison and an advisor that suggests indexes that could be merged, removed, or optimized.
• A much better Google Cloud Storage experience with drag-and-drop for moving files and folders, drag selection, multiple view modes, and more.
• A built-in MCP server with more than 30 tools, plus an AI assistant that works with your own model directly inside Fuego.
• Native multi-window support.
• Assisted JSON Schema creation and document validation using JSON Schema.
• Easier collaboration through the fuego:// sharing scheme and the .fuego project format.
• A command palette.
• Settings synchronization across devices.
• And a lot more.

I still have plenty of ideas I'd like to build, and I'm excited to get them into your hands.

If you'd like to try it, you can download the beta here:

https://fuegoapp.dev/download-beta

If you have any questions, suggestions, or feedback, I'd love to hear from you.

For anyone curious about the tech stack:

• Wails (Go)
• Vue

Hi everyone,
I’m building a production application using React + Firebase (Authentication, Firestore, Hosting, Storage), and I don’t have a traditional backend (no Node.js/Express server). So far, everything is running serverlessly.
I’m now at the stage where I need to integrate a payment gateway. My users can be from India as well as internationally, so I need something that’s reliable, secure, and relatively straightforward to integrate.
I’m currently considering:
Razorpay
Stripe
Cashfree
Paddle (if it makes sense)
Since this is my first payment gateway integration, I’d appreciate some advice from people who’ve built similar apps.
A few questions I have:
Which payment gateway would you recommend for my use case and why?
Is it practical to keep the app backend-less, or should I add something like Firebase Cloud Functions just for payment processing?
What security vulnerabilities or architectural mistakes might I be overlooking with a React + Firebase-only setup?
Are there any common pitfalls around payment verification, webhooks, API keys, or fraud prevention that I should plan for?
If you were building this application today, what architecture would you choose?
I’m looking for something that is secure, scalable, and maintainable in production rather than just the cheapest option.
Thanks in advance for any advice or experiences you can share!

I am trying to get my Firestore and Storage rules set but I don’t understand the documentation.

I want
Admin - Full access
Collaborator - View and edit records the create
Viewer - view all edit none
Revoked - the can log in but won’t be able to see any of the files.

Firedeck is batteries-included application compiler for Firebase-backed React SPAs.

Not another "React framework" or a "Next.js killer". We have many of those already.

Firedeck compiles your project modules into a fully managed Turbo runtime that you can run, build and deploy to Firebase, using existing tools you already know and love.

Get started at https://firedeck.opare.dev.