Laravel Firebase Laravel Package

Product Decisions This Supports

Build vs. buy on the "Firebase server side" seam. This package is a thin, opinionated Laravel service provider around the Firebase PHP Admin SDK. It exists so your team never writes credential discovery, service-container wiring, or multi-project config from scratch. The buy decision is close to a no-brainer: MIT license, ~1M+ monthly downloads, and a wrapper surface small enough to read in an afternoon. Writing an in-house equivalent buys you nothing but maintenance.

Feature decisions it unblocks (server-initiated, no client work):

• Push notifications — server-triggered FCM sends for order updates, chat, alerts, re-engagement. Decouples notification roadmap from mobile release cycles.
• Trusted identity — phone/email verification, custom claims/role minting, session revocation, and account deletion for GDPR/DSR requests. This is the cheapest credible path to "real accounts" if you're currently session-only.
• Multi-tenant readiness — FIREBASE_AUTH_TENANT_ID per project lets you scope auth per customer/workspace without building tenancy yourself. A roadmap-relevant lever if B2B/multi-workspace is on the table.
• Firestore as a fast read/write store — good for prototypes, feature flags-ish config, activity feeds, and read-heavy denormalized views where you'd otherwise spin up a new Postgres schema. Also the per-project Firestore default-database override for non-default named databases.
• App Check verification — server-side attestation checks; relevant if abuse/fraud on your APIs becomes a real cost line.
• Multi-project / multi-tenant-by-project — one app serving several Firebase projects (e.g., regional or white-label deployments) via Firebase::project('app')->auth(). Decide now whether you need this, because it shapes config and secrets management.

Architecture and platform decisions. Because it's wired through the service container, you get DI, facades, and app() — meaning no new Factory() scattered through your codebase, and Firebase calls become mockable in tests. That is a maintainability argument you can put in an ADR. Credentials-as-array support and configurable HTTP client options mean secrets can come from your secret manager rather than checked-in JSON files; token caching reduces per-request auth latency and API quota burn.

Roadmap hygiene signal. The changelog tracks Laravel and PHP majors closely (Laravel 11 → 12, PHP 8.4) and drops EOL support aggressively. Every Laravel upgrade therefore carries a small, scheduled dependency chore — budget it in the framework-upgrade epic rather than treating it as surprise work.

Metric caveat worth resolving before you cite it. The dataset shows Dependents: 0 against a README claim of 1M+ monthly downloads. Those can't both be true in spirit — treat the dependents field as a graph artifact, not as evidence of no adoption, and sanity-check via Packagist stats before quoting adoption numbers to anyone.

When to Consider This Package

Adopt when:

• Your backend is Laravel 11/12 on PHP 8.2+ (version 6.x aligns with Laravel 12; 5.x for Laravel 10/11). Confirm your pinned Laravel version maps to a supported package major before committing.
• You already use Firebase on the client (Auth, FCM, Firestore) and need the server to speak the same project — one identity model, one data store, no dual-write reconciliation.
• You need server-triggered push, verified identity, or custom claims and want it this sprint, not next quarter.
• You run multiple Firebase projects or per-tenant auth and want that as configuration, not code.
• You want Firebase access mockable and injected in tests, and secrets managed via env/secret store.

Look elsewhere when:

• You're not on Laravel (or are on Lumen — support was deliberately dropped in 5.0). Use kreait/firebase-php / beste/firebase-php directly.
• You need Firebase surfaces the Admin SDK doesn't cover — Analytics, Crashlytics, A/B Testing, Remote Config authoring workflows, or Extensions management. Those are console/REST/other-tooling problems; this package won't help and you shouldn't let it appear in scope.
• You need client-side SDK behavior in a web frontend — that's the JS SDK, different concern entirely.
• Your team doesn't have (or won't get) a Firebase project, service account, and a secrets-management story. Auto-discovery of credentials is convenient locally and a footgun in production if you don't pin FIREBASE_CREDENTIALS / GOOGLE_APPLICATION_CREDENTIALS explicitly.
• Firestore would become a second source of truth for data your Postgres schema already owns. The package makes it easy to add; that's precisely the adoption risk to guard against with an explicit data-ownership rule.

Risk notes to carry into adoption: single-maintainer concentration (sponsorship-funded, with active requests to fund it — treat as a bus-factor item), a GitHub org migration from kreait to beste in Jan 2026 with namespaces deliberately unchanged (safe for you, but pin and verify your remote references), and a history of breaking majors (4.0, 5.0, 6.0) that drop EOL framework versions. Pin the major, read the changelog on upgrade, re-publish config when the config schema changes.

How to Pitch It (Stakeholders)

For executives, in one line: A free, MIT-licensed Laravel integration for Firebase's server SDK that lets us ship push notifications, verified sign-in, and multi-tenant identity in weeks instead of quarters, with no vendor lock-in and no bespoke code to maintain.

The business case: Firebase is already in our client apps; this package is the server-side half, so we stop building glue. It's used across thousands of applications at ~1M+ monthly downloads, actively maintained through Laravel 12 and PHP 8.4, and licensed MIT — the cost of trying it is hours, not budget. The cost of not using it is a homegrown wrapper we'd own forever.

For engineering: It's a service provider plus config, not a framework. You get DI, facades, and app() access to Auth, Firestore, Messaging, Storage, Remote Config, Dynamic Links, and App Check across one or many projects; credentials from JSON or a config array; configurable HTTP client options and middleware; request/response logging to existing channels; and auth-token caching. No new Factory(). Everything is mockable in tests. Two constraints to accept: Laravel 11/12 + PHP 8.2+ only, and we pin the major because upgrades drop EOL framework versions.

What I'm asking for: Approval to spike it in one service for a single use case (recommend server-triggered push or custom-claims auth), plus agreement on two guardrails — explicit secrets handling for the service account, and a written rule that Firestore does not become a second source of truth for owned domain data. Success = the spike ships without new infrastructure and without an in-house wrapper.