- How do I install kreait/laravel-firebase in a Laravel application?
- Run composer require kreait/laravel-firebase and publish the package config file with the standard vendor:publish command. Add your FIREBASE_ environment variables and a service account so server-to-server requests can authenticate. Laravel package auto-discovery registers the service provider, so no manual binding is required. After that you resolve Firebase services from the container rather than instantiating the SDK yourself.
- Which Laravel and PHP versions does kreait/laravel-firebase support?
- Version 7.x requires PHP 8.3 or newer and supports Laravel 11, 12, and 13 on top of firebase-php 8.x. Version 6.x targets PHP 8.2 with Laravel 11 and 12, while the 5.x line covers Laravel 9 and 10 on PHP 8.1. Because each major drops older frameworks, pin the package major explicitly in composer.json instead of floating it. Plan for a version bump roughly every 12 to 18 months.
- How do I configure Firebase credentials with a JSON file or an array?
- Credentials can arrive three ways: auto-discovery on Google infrastructure, a JSON file path via FIREBASE_CREDENTIALS or GOOGLE_APPLICATION_CREDENTIALS, or a fully transposed config array. The array option is the operationally interesting one because it lets you inject secrets from a secret manager and keep the JSON off disk. The trade-off is that the service-account private key then lives inside your configuration, which needs care around config caching and image builds.
- Can I use multiple Firebase projects with kreait/laravel-firebase?
- Yes, the package supports multiple projects through its configuration and per-project resolvers, plus a single Firebase facade that routes to them. This changes the config shape and the facade usage pattern from day one, so decide early whether you need multi-project routing. Teams using it for multi-tenant or staging-versus-production separation should model the project map before writing call sites.
- Which Firebase services does kreait/laravel-firebase expose?
- The package surfaces Auth including custom tokens, Firestore with a default-database override, Realtime Database with auth variable overrides, Cloud Messaging, Storage, Remote Config, AppCheck, and the legacy Dynamic Links API. That is a broad surface area, so scope which services you actually need before adopting it. Auth-only usage carries a very different risk profile from treating Firestore as a system of record.
- How do I test or fake Firebase calls in a Laravel app using this package?
- The package binds the Firebase Admin SDK components into Laravel's container as singletons and deliberately suppresses the SDK Factory pattern in favour of constructor injection. That gives you a clean seam: you can swap or fake the resolved service in tests without touching call sites. Inject the client you need rather than resolving it statically inside methods, and your test suite stays fast and offline.
- Does the package support Firebase Auth custom tokens and multi-tenant authentication?
- Yes, Firebase Auth is supported including minting custom tokens for your own user store. Tenant awareness is available through the FIREBASE_AUTH_TENANT_ID setting, so requests can be scoped to a specific tenant. If multi-tenancy is on your roadmap, verify the tenant configuration early because it affects how you resolve the Auth component per request.
- Does php artisan config:cache break Firebase credentials stored in config?
- It can if you are careless: the array credential option puts the service-account private key into configuration, and config caching freezes whatever was resolved at cache time. Make sure the credentials are present at the moment the cache is built, or resolve them from environment values that survive the build. Also check whether long-lived queue workers hold cached OAuth tokens past a key rotation.
- Is kreait/laravel-firebase actively maintained and what is its release cadence?
- It is actively maintained by a single author and funded through sponsorship, with fast adoption of upstream releases such as Laravel 13 and PHP 8.5 readiness. The project moved from the kreait GitHub organisation to beste in January 2026, but the namespace Kreait\Laravel\Firebase and the Composer package name stayed the same, so consumers are unaffected. The bus factor of one is real, mitigated by the MIT licence and a public changelog. Its 1M+ monthly downloads are credible, but a zero dependents count on some dashboards is a telemetry gap rather than a signal of low adoption.
- What are the alternatives to kreait/laravel-firebase?
- The main alternative is using beste/firebase-php directly, which is what this package wraps. In a pure Laravel codebase the wrapper is worth it because it adds container bindings, config publishing, and multi-project resolution for almost no extra weight. In a non-Laravel PHP service or a polyglot stack that calls Firebase from several runtimes, skip it and use the SDK yourself to avoid a dependency you gain nothing from.