# laravel-firebase moved to the beste organisation in January 2026 and kept its old name

> This package wires the Firebase PHP Admin SDK into Laravel through a service provider, facades and a published config file. The repository now lives under the beste organisation while the namespace and the Composer package name stayed Kreait, which is the detail that breaks automation if you miss it.

**beste/laravel-firebase** — A Laravel package for the Firebase PHP Admin SDK

- Repository: https://github.com/beste/laravel-firebase
- Website: https://github.com/kreait/firebase-php
- Stars: 1,304 · Forks: 186
- Language: PHP
- License: MIT
- Published: 2026-10-17 · Updated: 2026-10-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/beste-laravel-firebase

## A binding, not a client

What this package is, is thin. It is described as a Laravel package for the Firebase PHP Admin SDK, and everything it adds on top of that SDK is the wiring Laravel applications expect: a service provider, facades, a configuration file and a way to publish that configuration.

The README is explicit about the boundary, and the instruction is unusually blunt. It says you do not need and should not use the new Factory() pattern described in the SDK documentation, because that is already done for you with the Laravel Service Provider, and that you should use Dependency Injection, the facades or the app() helper instead.

That matters because the SDK documentation is what most developers arrive from, and the pattern it teaches is the one you are told not to copy. Anyone who arrives without reading the README will build a working application that constructs its own factory and gets none of the package's value.

The dependency target is the Firebase PHP Admin SDK, and the README points to that SDK's documentation for everything past component retrieval, on the grounds that once you have a component you are holding an SDK object and the SDK documentation is the right reference.

## Credentials: discovery first, override when you need to

Access to a Firebase project from a server SDK requires authentication, and for server to server communication that means a Service Account. The README links Google's own instructions for creating one, then describes how this package finds the credentials.

By default, the package uses auto discovery for the default project, inspecting certain environment variables and looking into Google's well known paths. Everything the configuration expects is prefixed FIREBASE_, and the minimum usually required is the database URL:

```bash
# You can find the database URL for your project at
# https://console.firebase.google.com/project/_/database
FIREBASE_DATABASE_URL=https://<your-project>.firebaseio.com
```

Two escape hatches exist when discovery is not what you want. You can point at a file explicitly with the FIREBASE_CREDENTIALS or the GOOGLE_APPLICATION_CREDENTIALS environment variable, where a value of storage/app/firebase-auth.json is the shape given in the README, and that file sits inside the Laravel application rather than in a system path. Or you can transcribe the service account JSON as an array directly in config/firebase.php.

The array route is the one to think about. It means a private key lives in a PHP file inside your application directory, which is a materially different security posture from a file pointed at by an environment variable, and it is the configuration you want to avoid committing. The README does not warn about that, so the judgement has to come from your own review.

## Publishing the config file

The configuration file is config/firebase.php, and it can be customised in two ways: by copying it into your application's own config directory, or by defining the environment variables the file reads.

The publish command is the standard Laravel one, with the provider and the tag named explicitly:

```bash
# Laravel
php artisan vendor:publish --provider="Kreait\Laravel\Firebase\ServiceProvider" --tag=config
```

Two things are worth noting in that command. The provider class name is in the Kreait namespace, not beste, and the tag is simply config, which is the conventional Laravel tag rather than something specific to this package. If you are publishing tags for several packages at once, this one will be bundled with the others.

The alternative to publishing is to leave the package's own config in place and set the environment variables it reads, which is the pattern the FIREBASE_ prefix is designed around. For most applications that is the better default, because a config file copied into the repository is a file that has to be kept in step with the package across upgrades, while an environment variable is set once per environment.

The repository layout supports that model: config/ is a top-level directory, so the shipped configuration is visible in the source, and src/ holds the service provider and facades alongside phpunit.xml.dist and a tests directory.

## The facade defaults to one project, and can be told otherwise

Most applications have one Firebase project, and the facade is written so that the common case needs no argument. Multiple projects are supported through the projects array in config/firebase.php, and the facade resolves the default one unless you name a project.

The API is short enough to read in one go:

```php
use Kreait\Laravel\Firebase\Facades\Firebase;

// Return an instance of the Auth component for the default Firebase project
$defaultAuth = Firebase::auth();
// Return an instance of the Auth component for a specific Firebase project
$appAuth = Firebase::project('app')->auth();
$anotherAppAuth = Firebase::project('another-app')->auth();
```

The shape is component method call, so auth, and presumably the other components the SDK exposes, hang off the resolved project. Firebase::project('app') returns a project handle and auth() returns the component from that project rather than from the default.

For an application with several environments that map to several Firebase projects, this is the shape that matters, because the string argument is the only thing distinguishing them at the call site. That is worth a look during review: a mistyped project name fails at call time rather than at boot, since nothing forces the argument to match a key in the configuration array.

The topic list on the repository gives a good sense of which components are in play in practice: firebase-auth, firebase-cloud-messaging, firebase-database, firebase-realtime-database, firebase-remote-config and firebase-storage.

## Two names, one package, and a January 2026 move

The note near the top of the README is the kind of detail that costs an afternoon if you miss it. The project moved from the kreait to the beste GitHub organisation in January 2026. The namespace remains Kreait\Laravel\Firebase and the package name remains kreait/laravel-firebase. If you have forked or cloned the repository, you are told to update the remote URL.

The split is now three-way and worth writing down. The GitHub organisation is beste, so the clone URL and the issue tracker are under github.com/beste. The Packagist package is kreait/laravel-firebase, which is what composer require takes, and the version badges in the README point at packagist.org/packages/kreait/laravel-firebase. The PHP namespace is Kreait\Laravel\Firebase, which is what the service provider class name and the facade import use.

None of these are inconsistent, and the package name is deliberately unchanged so that existing composer.json files keep working. But a CI job that resolves the source repository by name, a badge generator configured for the old organisation, and a link in an internal runbook all need updating, and the README only tells you about the remote URL.

Maintenance facts alongside this: releases 7.1.0 on 2026-03-19, 7.2.0 and 7.2.1 both on 2026-05-07, the last push on 2026-08-20, and the repository is not archived. The 7.x line and the January move together suggest a stable, low-churn package rather than a fast moving one.

## Licence, terms and the security surface

The package is MIT licensed with a LICENSE file at the root, and the repository also carries CHANGELOG.md, CODE_OF_CONDUCT.md and SECURITY.md. No legal advice is offered here.

The licence line is short enough to be easy to skip and specific enough to matter. The code is MIT, and separately the README states that your use of Firebase is governed by the Terms of Service for Firebase Services, linking them on Google's site. The permission to modify and redistribute the PHP code and the terms under which Google's services may be used are two different contracts, and shipping this package in a commercial product means agreeing to both.

The security surface is concentrated in one file. A service account key is a credential that can authenticate as the project it belongs to, and this package offers three ways to supply it: discovered from the environment or from a well known path, pointed at with an environment variable, or written as an array in a config file. The first is convenient and invisible in review, the second is explicit, and the third puts a private key in a PHP source file.

Two operational notes follow. Whatever method you use, the key must be available to the process at runtime, which is the part that breaks in a container image built without the credential mounted. And the auto discovery path is the one to review carefully in an environment where other Google client libraries are installed, because discovery is shared behaviour and a file found for one library can be used by another.

## Conclusion

Adopt laravel-firebase when your Laravel application has to talk to Firebase server to server and you want the Admin SDK behind a service provider rather than constructing factories in your own code. Do not adopt it for end user authentication flows that belong in a client SDK, since the package exists for the server side. Verify first which repository URL your automation points at, because the project moved from the kreait to the beste organisation in January 2026 while the namespace and package name did not change, and check that your CI can reach the credential file that FIREBASE_CREDENTIALS or GOOGLE_APPLICATION_CREDENTIALS points at.

## FAQ

### How do I install laravel-firebase?

With `composer require kreait/laravel-firebase`. The package name is unchanged even though the project moved from the kreait to the beste GitHub organisation in January 2026, so existing composer.json files keep working.

### How are Firebase credentials configured in laravel-firebase?

Environment variables prefixed FIREBASE_ are read, and the database URL is usually the minimum required. The package also auto-discovers credentials for the default project, and you can override that with FIREBASE_CREDENTIALS or GOOGLE_APPLICATION_CREDENTIALS pointing at a JSON file, or by transcribing the service account as an array in config/firebase.php.

### Should I use new Factory() with laravel-firebase?

No. The README says you do not need and should not use the new Factory() pattern from the SDK documentation, because the Laravel Service Provider already does it. Use Dependency Injection, the facades or the app() helper instead.

### How do I use a second Firebase project in laravel-firebase?

Add another section to the projects array in config/firebase.php, then select it with the facade, for example Firebase::project('app')->auth(). Calling Firebase::auth() with no argument uses the default project.

## Sources

- [beste/laravel-firebase on GitHub](https://github.com/beste/laravel-firebase)
- [License: MIT](https://github.com/beste/laravel-firebase/blob/main/LICENSE)
- [Project website](https://github.com/kreait/firebase-php)
- [README](https://github.com/beste/laravel-firebase/blob/main/README.md)
- [Releases](https://github.com/beste/laravel-firebase/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/beste-laravel-firebase