BRYME TECH
SEPTEMBER 2026 · THE TOOL DESKPractical technology. No theatre.
THE BRYME

Practical guide · verified against the real thing

Why does Firebase deployment fail? Rules, indexes, quota

In one line: The CLI's four honest error families — auth, project, rules and indexes — and the exact order to read them in.

The symptom: firebase deploy ends in red, or deploys fine while the app itself throws errors the moment it runs. Firebase splits failures into two very different worlds — the deploy and the runtime — and mixing them up wastes evenings. This guide is built from the official documentation and public issue patterns, with sources dated below; it is deliberately not dressed up as a personal war story.

Deploy failures: three families

1. Authentication and project selection (the most common): expired CLI login or CI token (firebase login again, or rotate the CI token), and — the quiet one — the CLI deploying to a different project than you think. Read the deploy output's project line against your intent, and check .firebaserc aliases: "deployed" to the staging project is the classic silent failure.

2. Rules and config rejections (common): security-rules files with syntax errors, invalid match patterns, or a ruleset that fails validation stop the whole deploy. The CLI prints the file and line — read the first error, not the last.

3. Function deployment problems (common on Node projects): a Node runtime version your functions declare but the region/plan does not support, a build step failing inside the functions folder, or IAM permission gaps on the deploying account. The fix order: local npm run build inside functions/ must pass first — if it fails locally, no amount of redeploying helps.

Runtime failures after a "successful" deploy

1. The missing composite index (theFirestore classic): a query with two range/orderBy fields needs a composite index. Firestore's error message contains a direct link that creates the index with one click — and index building takes minutes. This is not an error to "fix" in code; it is an error to click.

2. Permission-denied from security rules (very common): rules validate every read and write. A ruleset that worked in the emulator may reject the deployed app's auth pattern (or the app may not be sending the token at all). The rule of rules: change them deliberately, test in the emulator, and never debug by making rules public — that is how Firebase projects leak.

3. Quota and plan walls (occasional, and confusing): the no-cost Spark plan limits functions, outbound networking and some features; hitting a wall produces errors that look like bugs. The usage dashboard settles it.

The honest escalation order

CLI error verbatim → project/alias confirmation → local builds pass → rules emulator → indexes created and waited out → usage dashboard. If all six are clean and the failure persists, you have a genuine support case — and the repro steps to make it a good one.

Official documentation (checked 11 September 2026): Firebase CLI reference and hosting deploy docs (firebase.google.com/docs/cli), Firestore index and security-rules guides (firebase.google.com/docs/firestore), and the pricing/plan limits page (firebase.google.com/pricing).

Next

Related on this desk.