AI AI Tools Guidebook
AI Tool Tutorials

Use AI for Firebase Deploy Checks

Pre-flight checks via AI — firebase.json correctness, rewrites, function regions.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

The painful Firebase deploys are the ones that succeed silently — the CLI prints a green URL, but a rewrite is wrong, a function region drifted, or a static asset is now 404. AI is great at catching these before you push, because firebase.json is small, structured, and the failure modes are well known. This is a 10-minute checklist you can run via Claude/ChatGPT before any non-trivial deploy.

What this covers

A pre-flight audit you can run against your firebase.json, function configuration, and public directory before pushing. The checks focus on the issues that ship green but break in production: rewrite rule ordering, function region mismatches, missing public paths, environment-variable drift between local and the deployed runtime, and stale CDN cache headers.

Key tools and concepts:

  • Firebase: Google’s backend-and-hosting platform, commonly used for site deploys, Cloud Functions, Firestore, and auth.
  • firebase.json: The single declarative config that controls hosting, rewrites, headers, redirects, and function bindings. Most deploy regressions trace back to one of these blocks.
  • Function regions: Cloud Functions execute in a specific region (us-central1, asia-northeast1, etc.). Mixed regions inside one rewrite chain produce latency spikes that look like “the function is slow.”

Who this is for

Firebase Hosting users who deploy more than once a week, especially Astro/Next.js teams using firebase.json rewrites to route to Cloud Functions or Cloud Run. Solo devs without a separate staging environment benefit most — the AI audit is the staging environment.

When to reach for it

Run the audit before any deploy that touches firebase.json, adds a new function, changes a domain, or modifies cache headers. Skip for pure content-only deploys where nothing in the routing layer changed. Run it again immediately after a deploy that “succeeded but feels wrong” — symptoms like 404 on one route, slow response on one region, or a Firestore rule that suddenly blocks reads.

Before you start

  • Have your full firebase.json, package.json, and the functions/ source directory ready to paste or attach. Partial context produces partial audits.
  • Note your target region(s) explicitly. The AI cannot guess “we always deploy to asia-east1.”
  • List recent changes since the last successful deploy — new functions, new rewrites, new domains. This is the highest-yield context.
  • Decide if you want a strict audit (every minor issue) or a “block deploy?” audit (only ship-stoppers). Tell the AI which.

Step by step

  1. Paste firebase.json into the AI with a one-line description of the project (“Astro static site with two Cloud Functions for OG image generation and a contact form”).
  2. Ask the structured audit prompt:
Audit this firebase.json for deploy-time risks. Check:
- Rewrite rule order (specific paths before catch-all)
- Function region consistency (all functions in the same region unless intentional)
- Missing or wrong public directory path
- Headers: caching for static assets, no-cache for HTML
- Redirects: any loops, any conflicting with rewrites
- Function-to-rewrite binding: function name matches a real export

Return: blocker | warning | nit, with the exact line and fix.
  1. For every finding, ask “Show me the exact diff that fixes this.” Don’t accept prose — accept a code block you can paste.
  2. Apply fixes. Re-run the audit on the patched file. The AI should now return zero blockers.
  3. Run firebase deploy --only hosting:preview to a preview channel first. Smoke-test the routes the audit called out.
  4. Promote to production. Watch logs for 5 minutes for cold-start latency on any flagged function.

Common failure modes the AI catches

  • Catch-all rewrite before specific routes: ** matches first, so /api/* never reaches its function. Reordering fixes it.
  • Function name typo in rewrite: functions/index.js exports ogImage but rewrite points to og-image. Silent 404.
  • Mixed regions: half your functions in us-central1, half in asia-east1, and the rewrite chain hops across regions adding 200ms per call.
  • Public dir mismatch: built output is in dist/ but public is set to out/. CLI uploads the wrong folder; site shows the previous build.
  • Cache header on HTML: index.html cached for a year by a wildcard max-age=31536000 rule meant for assets.

First-run exercise

Run the audit on your current firebase.json even if nothing is broken. The AI will surface 2-4 issues you’ve been carrying — usually cache headers or region drift. Fix the highest-leverage one and re-deploy. The point of the first run is to calibrate: does the audit produce signal on your specific stack? If it returns only generic advice, your context paste was incomplete.

Quality check

  • Did the AI cite specific line numbers or block names, or was it generic? Generic = you didn’t paste enough.
  • Did fixes come as drop-in code, or as prose (“you should consider”)? Prose fixes are signal that the AI is guessing.
  • Did the post-fix audit return clean? If new issues appeared, the AI is hallucinating problems — push back: “Why is this a problem? Cite the Firebase docs section.”
  • Did the preview deploy behave as predicted? If a function still 404s after fix, the AI missed something — gather the new evidence and re-prompt.

How to reuse this workflow

  • Save the audit prompt with your project name and region baked in. Each repo gets its own version.
  • Keep a “previously caught” log per project — patterns repeat, and the AI doesn’t remember session-to-session.
  • Re-run quarterly even without code changes. Firebase deprecates flags; your config may be stale.
  • For teams, paste the audit findings into the PR description so the reviewer sees what changed and why.

Config + recent-changes summary + region declaration → AI audit with structured prompt → fix list as diffs → apply → preview deploy → smoke test → promote. Total time: 10-15 minutes pre-deploy, vs an hour of rollback after a bad ship.

Common mistakes

  • Skipping the audit on “small” deploys — the small deploys are exactly when a rewrite typo slips through.
  • Pasting only firebase.json without function code — the AI can’t verify the binding.
  • Asking “is this OK?” instead of running the structured checklist — open prompts produce vague answers.
  • Accepting prose fixes instead of demanding diffs.
  • Deploying straight to production without a preview channel — preview channels are free and catch 90% of remaining issues.
  • Ignoring “nit” findings forever — they compound into the next month’s outage.

FAQ

  • Does the AI know about my Firebase project settings?: No, only what you paste. Region, project ID, and recent changes must be stated explicitly.
  • Can it audit Firestore rules too?: Yes; paste firestore.rules and ask for a separate audit with the same structured-finding format.
  • What about App Check / billing config?: Not from firebase.json alone. Include screenshots of the console pages if you want those audited.
  • How is this different from firebase deploy --dry-run?: Dry-run validates syntax; the AI catches semantic errors (wrong order, wrong region, wrong target).
  • Can I automate this?: Yes — wire the prompt into a pre-deploy script that pipes firebase.json and git diff to the model and exits non-zero on blockers.

Tags: #AI coding #Tutorial

Related Articles