# beste/firebase-php: the Firebase Admin SDK for PHP servers

> An unofficial PHP admin SDK that wraps Firebase Auth, Realtime Database, Cloud Messaging, Storage and Firestore behind one factory. Here is how it installs, what it actually delegates to, and where it stops being the right tool.

**beste/firebase-php** — Unofficial Firebase Admin SDK for PHP

- Repository: https://github.com/beste/firebase-php
- Website: https://firebase-php.readthedocs.io/
- Stars: 2,436 · Forks: 454
- Language: PHP
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/beste-firebase-php

## What beste/firebase-php actually solves for a PHP backend

Firebase ships official Admin SDKs for Node.js, Java, Python, Go and C#. PHP is not on that list. If your application server is PHP and you need privileged access to Firebase, you either talk to the REST APIs and the Google OAuth flow yourself, or you use a community SDK. This package is that community SDK: the README describes it as enabling "access to Firebase services from privileged environments (such as servers or cloud) in PHP."

The audience is narrow and specific. It is for server-side code that holds a service account credential and acts on behalf of the project, not for browser or mobile clients. Typical work: minting custom tokens, looking up users, sending FCM pushes from a queue worker, writing to the Realtime Database from a webhook handler, or reading a Firestore document from a reporting job. If you are building a client app that talks to Firebase directly, this package is not in that path at all.

One naming detail trips people up. The project moved from the kreait GitHub organization to beste in January 2026, but the README says the namespace remains Kreait\Firebase and the package name remains kreait/firebase-php. So the repository path and the Composer package name no longer match, and existing require lines keep working unchanged.

## The factory pattern and what each create call returns

There is no single Firebase object. The entry point is a Factory that accumulates configuration and then hands out per-service clients. The README's quickstart shows the shape: build a factory, give it a service account JSON path and a database URI, then call createAuth, createDatabase, createMessaging, createRemoteConfig, createStorage or createFirestore.

That design has a consequence worth understanding before you design around it. The factory is a lazy dispatcher, not a connection pool. Credentials are resolved when a service client is created, and each service then speaks to its own Google endpoint. Auth calls go to the Identity Toolkit surface, Cloud Messaging to FCM, the Realtime Database to the database URL you passed in withDatabaseUri. Firestore and Storage are separate products with separate APIs. Nothing is unified underneath; the SDK unifies the entry point only.

So the practical unit of failure is per service. A missing IAM role on the service account breaks Firestore reads while Auth continues to work, and the error will surface at the call site of the failing service rather than at factory construction. Treat each create* call as its own integration with its own credential requirements.

The withDatabaseUri call is also load-bearing in a way that is easy to miss: it is only needed for the Realtime Database, and the URL is project specific. Omit it and createDatabase has nothing to point at.

## Installing with Composer and sending your first push

The README gives Composer as the recommended install path and pins the constraint to the 8.x line:

```bash
composer require "kreait/firebase-php:^8.0"
```

After that, the setup documentation (docs/setup.rst in the repository) covers connecting the application to Firebase. The README does not inline the credential setup steps, so read that page before wiring anything into production.

A minimal script that builds the factory and creates a Cloud Messaging client looks like this, following the quickstart:

```php
use Kreait\Firebase\Factory;

$factory = (new Factory)
    ->withServiceAccount('/path/to/firebase_credentials.json')
    ->withDatabaseUri('https://my-project-default-rtdb.firebaseio.com');

$cloudMessaging = $factory->createMessaging();
```

What you should see: no output at all if the credential file parses and the path is readable. The failure mode at this stage is a file or JSON parse error from withServiceAccount, not a network error, because no request has been made yet. The actual call to Firebase happens when you invoke a method on $cloudMessaging.

If you are inside Laravel or Symfony, the README points elsewhere rather than documenting framework wiring here: kreait/laravel-firebase on Packagist for Laravel and kreait/firebase-bundle for Symfony. Those packages handle service container registration; the base SDK does not.

## Where the abstraction leaks and when to pick something else

The honest limitation is coverage. Firebase is a moving product surface, and an unofficial SDK tracks it by hand. The README's quickstart enumerates six create methods, and that list is the SDK's public promise. Anything Firebase ships that is not behind one of those factory methods is not available through this package until someone adds it.

There is a second, quieter cost: the SDK is a wrapper over Google APIs whose behaviour is defined by Google, not by this project. When a response shape changes upstream, the fix lands here as a release. The repository has a NEXT_MAJOR_TODO.md at the top level, which tells you the maintainers are already tracking breaking changes for a future major version rather than pretending the surface is frozen.

If your only requirement is verifying Firebase ID tokens on a PHP backend, this is more SDK than you need. Token verification is a JWT check against Google's public keys, and the related searches around this project show a lot of people arriving with exactly that narrower question. Pulling in a full admin SDK to verify a signature is a large dependency for a small job.

And if you wanted Google's own PHP Admin SDK, there is no such thing to compare against. That absence is the whole reason this package exists.

## Alternatives: the REST APIs, framework bundles, and php-jwt

The real alternative is not another SDK. It is calling the Firebase and Google REST APIs directly with an HTTP client, handling OAuth2 token exchange yourself. The difference in approach is total: you get exact control over which endpoint is hit and which fields are sent, and you own the token refresh, the retry logic and every response shape. For a single narrow integration, say posting to one FCM endpoint from a cron job, that is a defensible amount of code and one fewer dependency to upgrade.

The second alternative is a framework bundle, and it is not really a competitor: kreait/laravel-firebase and kreait/firebase-bundle wrap this same SDK for container-based configuration. Choosing them means choosing this package underneath.

The third thing people confuse with this project is a JWT library. The related searches mix firebase-php with php-jwt repeatedly, and they solve different problems. A JWT library signs and verifies tokens. This SDK uses that kind of machinery internally to authenticate as a service account and to mint custom tokens, but it also gives you the service clients. If you need only the crypto, take the smaller library.

## Maintenance, versions and what the MIT licence does not cover

The repository is not archived and the last push was on 2026-09-25, three days before this writing. Release cadence is visible in the changelog: 8.4.1 on 2026-09-04, 8.4.2 on 2026-09-05, 8.5.0 on 2026-09-12. That is a project with an active release process, and the README notes it is downloaded over a million times a month and asks for sponsorship on that basis.

The upgrade cost is concentrated at major boundaries. The repository carries UPGRADE-8.0.md at the top level, so the 7.x to 8.x transition had documented migration steps, and NEXT_MAJOR_TODO.md signals that another one is being planned. Pin to ^8.0 and read UPGRADE-8.0.md before any major bump rather than discovering renames at runtime.

On licensing: the SDK is MIT, which is permissive and imposes no copyleft obligation on your application. That covers the SDK only. The README states plainly that your use of Firebase is governed by the Terms of Service for Firebase Services, so the licence question and the service question are separate, and the second one is a contract with Google rather than an open source licence. This is not legal advice; read both documents.

## Conclusion

Adopt it if your backend is PHP and you need admin access to several Firebase services from one credential file; skip it if you only need ID token verification in a framework that already ships its own Firebase integration, or if you want Google's own SDK, which does not exist for PHP. Verify first that the service account JSON you intend to use has the roles for the services you call, and check the docs for the specific service before assuming a method exists.

## FAQ

### How do I install the Firebase Admin SDK for PHP?

Install it with Composer using the constraint from the README, composer require "kreait/firebase-php:^8.0". The README then points to the setup section of the documentation for connecting your application to Firebase.

### What is firebase php jwt and how does it relate to this SDK?

They are different things. A JWT library signs and verifies JSON Web Tokens, while this SDK is a Firebase Admin SDK that exposes Auth, Database, Messaging, Remote Config, Storage and Firestore clients, and handles service account authentication internally.

### Is there an official Firebase Admin SDK for PHP?

The package describes itself as the Unofficial Firebase Admin SDK for PHP, and the README frames it as enabling access to Firebase services from privileged environments in PHP. No official PHP Admin SDK is mentioned in the README.

### What is the Composer package name for beste/firebase-php?

It is still kreait/firebase-php, and the namespace remains Kreait\Firebase, even though the project moved from the kreait to the beste GitHub organization in January 2026.

### Does beste/firebase-php work with Laravel or Symfony?

Not directly through this package. The README directs Laravel users to kreait/laravel-firebase and Symfony users to kreait/firebase-bundle for framework integration.

## Sources

- [beste/firebase-php on GitHub](https://github.com/beste/firebase-php)
- [License: MIT](https://github.com/beste/firebase-php/blob/8.x/LICENSE)
- [Project website](https://firebase-php.readthedocs.io/)
- [README](https://github.com/beste/firebase-php/blob/8.x/README.md)
- [Releases](https://github.com/beste/firebase-php/releases)

---

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