The Firebase Extensions service has a shutdown date, and the replacement is a function kit

The service closes on March 31, 2027

The deprecation notice is the first thing in the README and it sets the frame for everything else. The Firebase Extensions service is deprecated and will shut down on March 31, 2027. Extensions that are already installed will keep running, but you will not be able to manage them after that date, which is a specific and awkward guarantee: the functions deployed by an extension instance stay deployed and continue to be billed, while the layer that lets you see, reconfigure, update or uninstall them disappears. The documentation points at a user migration guide and an FAQ for the details, and recommends migrating to function kits. For anyone running extensions in production, that gives less than six months to move, and the useful way to think about it is that the deadline is for the management surface, not for the code, so the risk of doing nothing is not an outage on that date but an inability to change anything afterwards.

A function kit is your own function, packaged

The replacement mechanism is described in a few sentences. A function kit packages an extension's functionality as an npm package. You add it to your own Cloud Functions for Firebase, second generation, codebase and deploy it with the Firebase CLI, the same way you deploy your other functions, instead of installing a managed extension instance. The difference in ownership is the whole point. An extension instance is a managed thing on Firebase's side, configured through the console and kept up to date by a service that is going away. A kit is a dependency in a repository you control, deployed by your pipeline, versioned with your code, and reviewed when you upgrade it. The cost moves too, since you now own the deployment, the configuration and the updates, and the extension's own configuration surface has to be recreated in your own code rather than in the instance's settings.

One extension has a kit, and not every extension will get one

The table of kits currently available lists a single row, with the `firestore-bigquery-export` extension mapping to the `@firebase-function-kits/firestore-bigquery-export` package on npm. The documentation is careful about what that table means. More kits may be added over time, but not every extension will necessarily have one, which is the sentence that should drive your planning, because it rules out the assumption that a migration path will arrive for the extension you happen to run. To find out where you stand, the documentation gives two routes, running `firebase ext:list` in your project, or opening the Extensions page of the Firebase console. Publishers of their own extensions are pointed at a separate publisher migration guide, since the same service closure affects the people who publish into it and not only the people who install from it.

What each extension directory actually contains

The top level of the repository lists one directory per extension, and the naming makes the platform grouping visible. There is `firestore-bigquery-export`, `firestore-counter`, `firestore-send-email`, `firestore-shorten-urls-bitly` and `firestore-translate-text`, so five extensions on Firestore, plus `storage-resize-images` for Cloud Storage, `rtdb-limit-child-nodes` for the Realtime Database, and `delete-user-data` for account deletion. There is also a `samples/` directory, which currently holds a `rtdb-uppercase-messages` sample, and an `_emulator/` directory used by the test tooling. The documentation explains what each extension directory holds: the source code for the extension and a README explaining how it works, including the APIs it enables, the resources it creates and the access it is granted. That last part is the most valuable thing in the tree for anyone auditing what an extension does to a project.

Fixes for published extensions still ship from here

The deprecation does not mean the code has stopped moving, and the README is explicit about one continuing commitment: fixes for the published extensions are still released from this repository. The release list backs that up, with a release candidate for the storage resize images function kit on 2026-10-19, a stable `@firebase-function-kits/firestore-bigquery-export` at 0.1.1 on 2026-09-28, and an earlier release candidate for the same kit on 2026-09-24. The default branch is `next`, which is a branch name that fits a project with a migration running alongside the thing being migrated. So the practical reading of the repository's current state is that the extension sources are still maintained and tested, and that the function kits are being built out incrementally, one extension at a time, at a pace that will not cover everything before the shutdown date.

The test setup is an emulator, jest and lerna

The repository is a monorepo managed with lerna, and the root manifest shows how the pieces are built and tested. Formatting and linting are both prettier, with `format` writing and `lint` listing what differs, across JavaScript, Markdown, YAML, TypeScript and JSON files. The build runs through lerna with a sort order, and there is a `clean` target that runs the per package clean in parallel. The tests are the interesting part, because an extension is a set of Cloud Functions and resources that only mean something in a running Firebase project. The scripts start the local emulator suite in a project named demo-test and run jest against it:

cd _emulator && firebase emulators:exec jest -P demo-test

There is a local variant that starts the emulator and jest together with concurrently, a watch mode, a CI variant that sets a CI flag and forces the process to exit, and a coverage variant. A postinstall step bootstraps the lerna packages, rebuilds them and regenerates the package locks, and a `prepare` script installs the husky hooks, with commitlint and lint-staged configured in the root. The licence is Apache-2.0, with a header template and a script that checks or adds the licence header across the tree.

What to do in the next year

The repository does not spell out a migration plan for users beyond pointing at the guides, so the sensible approach follows from what the documentation does say. Start by listing what you have installed and separating the extensions with a function kit from those without, because the first group has a supported path and the second group needs a decision you make. For the first group, the work is adding the kit to your Cloud Functions codebase and redeploying, which also means taking ownership of whatever configuration the instance was holding. For the second, the options are to reimplement the behaviour in your own functions, to keep the existing deployed functions running and accept that they can no longer be managed, or to drop the feature. Whatever you choose, the deadline that matters is the management shutdown rather than the code shutdown, and the sources in this repository, with their per extension documentation of APIs, resources and permissions, are the reference for understanding what an installed extension has been doing to your project.

Editorial conclusion

firebase-extensions suits a team that already has Firebase extensions installed and needs to plan the move to their own Cloud Functions before the service closes on 2027-03-31, and it suits a developer who wants to read how a published extension is put together, since each directory documents the APIs it enables, the resources it creates and the access it is granted. It is a poor fit for a new project, because installing a managed extension now buys you a service that is being switched off, and it is a poor fit for a publisher, since the publisher migration guide exists precisely because the model of publishing to that service is ending. Before you do anything, check three things: which extensions you actually have installed, with `firebase ext:list`, whether a function kit exists for each of them, since not every extension will get one, and how much of your configuration is stored as extension instance resources rather than in your own code, since that is the part the migration has to recreate.

Frequently asked questions

Official sources

1. firebase/extensions on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases