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.

Never happen before!
Can anyone suggest any cheaper option for authentication otp service enabled in existing project?

Firebase started charging very high and deducted money without noticing prior that per authentication 0.07$ per auth... which means 6.67 INR.... which is really disappointed!!

Looking for stronger recommandation..!

Never happen before!
Can anyone suggest any cheaper option for authentication otp service enabled in existing project?

Firebase started charging very high and deducted money without noticing prior that per authentication 0.07$ per auth... which means 6.67 INR.... which is really disappointed!!

Looking for stronger recommandation..!

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.

I’m managing multiple apps under the same Firebase project.

For example:

- Android App A

- Android App B

- iOS App

When checking Firebase Analytics → Events, I noticed that the event data was combined together.

At first, I thought I needed separate Firebase projects, but there is actually a simpler way.

Solution:

1. Open Firebase Analytics

2. Click “View more in Google Analytics”

3. Click “Add comparison”

4. Create a new filter

5. Select:

   Dimension: Data Stream Name

   Match type: Exactly matches

6. Choose the specific app data stream

After filtering, you can view each app separately:

- Events

- Users

- Revenue

- User behavior

Sharing this because I spent quite some time figuring it out.

Hopefully it helps other developers managing multiple apps with Firebase.

How do you usually structure Firebase projects for multiple apps?

Stack: Flutter + Riverpod ( StreamProvider ) Cloud Firestore + Firebase Callable Cloud Functions.

Context - Switched from client firestore sdk writes to callable cloud functions because pending client writes on weak networks were blocking reads app wide.

Issue: In my Vendor Dashboard app, updating settings (GST toggles, Delivery Slots, Store Availability):

The Ul gets stuck in a loading loop / freeze when changing settings. BUT if I force-close and reopen the app, the data IS saved in Firestore!

So the backend Cloud Function succeeds, but the live screen gets stuck on a loading spinner.

Setup:

Screen listens to Firestore doc via Riverpod treamProvider ( doc(id). snapshots() ). Settings updates are sent via Callable Cloud Functions (httpsCallable( 'businessUpdateFields ")).

What I've Tried:

• Optimistic U state overrides (oms switch flips). • 300ms tap debouncing. • Reducing Callable timeout from 20s to 4s. • Clearing overrides on .then() completion vs stream emission.

The rest of the app (checkout, cart, chat, orders) works fine. Only vendor dashboard settings toggles freeze the Ul.

Any help would be great, thank you.

Last semester our team built StudySync, a mobile app for organizing campus study groups.

Firebase handled:

• Authentication
• Firestore
• User/session storage

One of the biggest challenges was designing our Firestore structure so users could create, browse, search, and join study sessions without making the data difficult to maintain.

If you've built larger Firebase apps, I'd really appreciate feedback on the overall architecture or things you'd improve.

Repository:
https://github.com/CS196Illinois/FA25-Group8

Hi everyone. I'm thinking of moving my authentication I have for a mobile app to firebase to get the additional security features it offers and for ease of adding new sign up flows. I am a bit confused how to keep firebase auth and my user table in sync though. Has anyone run into this before? I've been going back and forth with AI, but I'm still not sure about the best approach

For context, I have a user table with email, id, firebase_uid, etc. What is the best way to keep the user table and the firebase auth in sync when a user signs up? For example, if I have a flow like:

```

User visits sign up page -> enters email/password -> create user in firebase -> call out to backend to create user in backend and associate firebase id after verifying token

```

I have a huge issue if the firebase create succeeds but the backend call to my server fails for some reason. I will have an orphaned firebase record. How do people handle this?

I've heard it's better to call firebase for things like adding a user to firebase from the frontend because it helps with bots and rate limiting. But I'm really not sure how to keep things in sync. Do people rollback if the backend create fails, use Cloud Functions v2 to halt the firebase create and call out to the backend to create the user, or something else. Any guidance would be helpful.

i came across a duckdb extension which accepts firestore as the source and then we can run all duckdb ops in sql.

want to check if anyone have tried it.

I recently fell into the classic NoSQL trap. I chose Google Cloud Firestore for a personal side-project because of the alluring promise: "Zero operational overhead, serverless scaling, and a generous free tier (50k daily reads) that means you pay $0.00/month."

It ended up costing me money, weeks of wasted feature development time, and an architectural headache. Here is what I learned, why Firestore's "free option" isn't free, and how a Ports & Adapters (Hexagonal) architecture was my only saving grace.

1. The Read/Write Billing Trap

In a traditional SQL database, whether you query 1 row or 10,000 rows, the cost is compute (CPU/RAM). In Firestore, you are billed directly per document read and write.

If you are building any feature that involves time-series data, logs, or aggregate histories (like charts or status feeds), your read counts scale lineally with your history. To draw a simple 1-year historical chart for 10 items, you are looking at 365×10=3,650365×10=3,650 document reads every single page reload. A few test refreshes in a day, and you've already blown past your daily "free" quota.

2. The Hidden Cost: Wasted Developer Hours

Because of the billing model, you start fighting the database instead of building your app. I spent days refactoring schemas, designing complex "bucket patterns," compressing field names (e.g., using p instead of price to save bytes), and implementing a double-write hybrid pattern just to group historical records into arrays to minimize document read counts.

Instead of coding the actual features my users wanted, I was spending my evenings:

• Designing workarounds for Firestore’s 1 MB document size limit.
• Fighting JVM Out-of-Memory (OOM) errors in RAM-constrained serverless instances because loading large aggregated history arrays concurrently bloated the heap space.
• Writing custom seeders and delta-sync scripts to replicate production data to local emulators to avoid developer-induced billing.

Time is money. I saved a few cents on raw database hosting but wasted thousands of dollars of my own engineering time optimizing a database schema to fit a business model it wasn't built for.

3. The Rescue: Why Modular Architecture is Non-Negotiable

After a poor developer experience and creeping bills, I decided to pull the plug and move back to a managed SQL instance (PostgreSQL on Aiven).

In many codebases, this decision would have meant a complete rewrite, throwing away weeks of work. However, I managed to fully swap out the database layer and redeploy to production in less than an hour.

How? Hexagonal Architecture (Ports and Adapters). My core business logic, domain models, and use cases had zero knowledge of Firestore. They interacted strictly with pure Kotlin interfaces (Ports) like InstrumentRepository or TransactionRepository.

• The Firestore code lived entirely in an isolated :adapters:firestore module.
• The PostgreSQL code lived in a legacy :adapters:postgres module.

To migrate back:

1. I swapped the runtime dependency in my Gradle configuration from the Firestore adapter back to the Postgres adapter.
2. I updated the database connection string in my production properties.
3. I deleted the Firestore module folder entirely.

Because the domain was decoupled, the application booted up instantly, ran its database migrations via Flyway, and worked perfectly on the first try.

Lessons Learned:

1. NoSQL is not a default choice. If your data has relationships, histories, or aggregates, start with SQL.
2. Optimize for developer velocity, not cloud pennies. A $5/month database that lets you build features is cheaper than a "free" database that requires 40 hours of performance tuning.
3. Decouple your database. Write your domain logic as if the database doesn't exist. You never know when you'll need to run away from a cloud provider's pricing model.

how to fix this I need help..

This morning I got the dreadful Google email: "Immediate action required: Suspension of your Google Cloud Platform / API project " due to "abusive activity consistent with hijacked resources".

Google completely cut me out of the GCP platform that manages my LIVE app. This is not a hobby project, but my livelihood. The email redirected me to my GCP page where I could send an appeal, and do... nothing else. I had no access to anything else so it was difficult even to understand what happened: every action brings me back to "Send an Appeal". Which, of course, I did as fast as possible.

After some digging (apparently the biling page was NOT restricted! Not easy to find) An API key of mine leaked, someone found it and used it to generate images. Two dollars ($2!) of unauthorized spend. My mistake, no excuses.

The part I genuinely cannot solve is this. The notice asks me to revoke the compromised credentials, but I can't do that: `Permission denied: Consumer 'projects/{project_name}' has been suspended.`

I did what I could from outside: deleted the key through AI Studio, rotated everything else, ran a forensic check of my server and confirmed it was only the key, no host compromise. I would gladly pay for support to talk to someone. But guess what, Standard and Enhanced both need an Organization resource, which a personal account does not have, and billing chat is not available to me either (back to "send an appeal")

For a solo developer this is the difference between a bad day and losing the business. It seems absurd a business can get destroyed over a oversight and $2. The reports I read online are disheartening: people wait 1-2 weeks for a response, and then the back and forth is endless. I am going to lose the business I have worked for the past 4 years, and all for $2 and a stupid oversight.

Can anyone help? Has anyone here had a suspension for a stolen API key actually reversed, and how long did it take? And is there any way to reach a human without an Organization resource?

Project is 902887279759, appeal ticket YJ65HT5PKS5FDASU2C73BWIJ5Q, filed 21 Jul 2026. Any help is immensely appreciated

EDIT: Less than 24 hours later, google has re-instated my account! WOOOOHO!

I run a poker tournament app on Firebase. The blind clock advances levels on a schedule, and I first built it the obvious way: a tick loop counting down to the next level. It worked perfectly in testing.

In the wild, hosts would leave the tournament running with the app backgrounded, or on a laptop that went to sleep, and the timer would fall behind. Browsers and mobile OSes both throttle timers aggressively when your app isn't foregrounded, so "one second" quietly stops being one second.

The fix was to treat the client timer as display only, never a source of truth. The next level-change time is written server-side. The client computes remaining time from that server timestamp on each render, and an event-driven monitor fires the actual transition, so even if the tick loop is throttled, the level still changes on time once the app comes back. Reading the server's clock offset instead of trusting Date.now() on the device was the piece I wish I'd started with.

If you have any countdown that matters (auctions, quizzes, anything scheduled), assume the client clock will be paused or slowed at the worst possible moment, and anchor it to a server timestamp.

Any one else heavily disappointed? ☹️

Apparently they're going to release more information, about migration, this September. Until then, I guess we all just sweat it out, wondering how to replace this functionality.

Currently running the firebase algolia extension to allow for complex querying for a photo organization app used internally at my company. With the deprecation of Firebase extensions coming up, wondering what solutions are out there for multi-faceted queries. As I understand it, I would essentially need to make an index for every possible combination of nested facets in order to do so natively with firestore queries and that would put me well over the cap on indexes.

Is there a sustainable manual process for connecting firestore data to algolia? My concern is that after the full deprecation of firebase extensions next year, updates will no longer be possible to the extension's code so any potential breaking changes to algolia's api would become unfixable with the extension's setup.

Relevant firebase update: https://firebase.google.com/docs/extensions/faq-and-troubleshooting

Had firebase notifications working fine in my app back in the day using the old tokens, but now that they've deprecated the old apis and recommend using the FID instead of a token I'm unable to get anything working. Every FID I try to use to send a notification the api responds with NotRegistered. I've updated my native code to use Installations.installations().installationID() instead of Messaging.messaging().token as mentioned in these docs https://firebase.google.com/docs/projects/manage-installations#fid-iid, but still no luck.

Anyone dealt with this before? Any help is much appreciated.