What happens to Firebase Extensions on March 31, 2027
Firebase Extensions shuts down on March 31, 2027, and after that date installed extensions can no longer be updated, reconfigured or uninstalled. Every workflow an extension runs today, such as resizing images, sending trigger emails or syncing data to another service, needs a named owner and a replacement plan before that date. Extensions that keep running after the shutdown should not be assumed to keep working unchanged, so inventory them now and decide for each one whether to keep it, rebuild it or retire it. The Firebase Extensions deprecation FAQ is the authority on shutdown behavior, and you should confirm exactly what still runs, and what breaks, once the date passes.
Start the inventory with the Firebase console and the Firebase CLI, and record for each instance its project, the extension name and version, its configuration parameters, the triggers it listens to and the Cloud Functions and Cloud Storage resources it created. Your data stays in Firestore, Cloud Storage or Realtime Database, so exporting the data itself is usually a separate task from exporting the extension. Confirm with the extension's own documentation which collections, buckets and secrets it writes, because those are the data you must preserve and the configuration you must re-create. Plan for the code to be lost as an artifact: you will own the replacement logic, not the vendor package.
Replacing an extension means rebuilding its behavior as functions or services in your own infrastructure. A trigger-based extension becomes a function or an event handler that reacts to the same data change, and an extension that calls a third-party API needs its secrets moved into a store you control. Choose the destination with the wider move in mind, since a Postgres-based stack like Supabase Edge Functions or an Appwrite Functions deployment changes how triggers and secrets are handled. Test each rebuilt workflow against copied data before the Firebase version is switched off, and keep the original extension running until the replacement has passed that test.
Which extension data and settings you can export before the deadline
This table lists each kind of data a Firebase extension touches and the documented export path, output format and limits for it. Read each row against your own project, because extension-specific settings and limits can differ, and confirm them in the Firebase Extensions FAQ before you start. The main takeaway is that data in Firestore, Authentication and Cloud Storage can be exported through the standard Firebase paths, while extension configuration and function source need to be recorded by you.
| Data type | Export path | Output format and limits |
|---|---|---|
| Extension configuration values | Record from the deployed instance parameters in the Firebase console or CLI before any change, and keep a copy in your own repository | Plain key and value settings. No documented export command is supplied for extension configuration, so confirm what is retrievable for each extension |
| Firestore documents written by the extension | Firestore managed exports to a Cloud Storage bucket, with the export scoped to the collections the extension uses | Managed export files in Google's export format, which need a Firestore import or a custom parser to read. Confirm collection names and the bucket permissions for your project |
| Cloud Storage objects created by the extension | Download the objects with the Firebase console, gsutil or the Cloud Storage client libraries, preserving the bucket path | Original file formats with their metadata. Large buckets take longer to copy, and access rules must allow the downloading account to read the objects |
| Authentication users created by the extension | Firebase CLI auth:export to a JSON file, including password hashes and hash parameters | JSON records with scrypt parameters for password hashes. Export only users the extension created, and treat the file as sensitive credential material |
| Function source code you own | Keep the source in your Git repository or copy it from the local project directory used for deployment | Original source files in your language of choice. Deployed copies are not the source of record, so confirm your repository matches what runs in production |
What stops working after the shutdown and what cannot be recovered
Firebase Extensions stop receiving changes on March 31, 2027, so each installed extension becomes a fixed piece of your backend. The cards below cover what you lose, what you can still do before the deadline, and what to rebuild on infrastructure you control.
Update, reconfigure and uninstall controls
After the shutdown, you can no longer update, reconfigure or uninstall deployed extensions. A configuration you chose years ago stays in place, and any later bug fix or security patch in the extension code will not reach your project. Before the deadline, record each instance's parameters, the Firebase project it runs in and its trigger events. Treat the current configuration as frozen and plan the replacement while you still can change it.
Uncertain runtime behavior after shutdown
Nothing in the supplied documentation guarantees how a deployed extension will behave once the service is switched off. Triggers may stop firing, or they may keep running on a code path that no one maintains. Ask Firebase support or check the deprecation FAQ for the exact post-shutdown behavior before you rely on any extension. Test the trigger path in a staging project so a silent failure does not surface first in production.
Extension-managed resources you cannot change
Extensions create their own Cloud Functions, service accounts, Cloud Storage buckets and sometimes Firestore collections on your behalf. Those resources sit outside the code you deploy, so the console may not let you adjust their settings once the extension is frozen. Export the list of resources each instance created and note which ones hold data. Decide whether each resource will be retired, copied or kept as a read-only archive before the rebuilt function goes live.
Storage requires the Blaze plan
Cloud Storage for Firebase has required the pay-as-you-go Blaze plan since the changes announced in September 2024. Extensions that write files into Storage therefore depend on a billing account that stays active. If you move the file handling into a function, confirm the Blaze billing and budget alerts still apply to the storage path. Consider whether the files should stay in Firebase at all, or move to a store you operate, before rewriting the trigger that writes them.
Documented configuration in your repository
The configuration you can still read is your best record of how an extension was set up. Copy each instance's parameters, secrets references and trigger definitions into a version-controlled repository before the deadline. Store secret values in a secrets manager rather than in the repository itself. This gives your rebuilt functions a documented baseline, and it lets a reviewer confirm that the replacement handles the same events the extension did.
How to inventory Firebase Extensions and map each to a replacement
The inventory sets the scope of any migration, so it comes before any choice of replacement. In each Firebase project, list every extension instance, because the same extension can be installed more than once with different settings. For each instance, record the installed version, its configuration parameters and its triggers, whether that is a Firestore write, a Storage object event, a scheduled run or an HTTP call. Then write down the Firestore collections and Storage paths it reads and writes, and every application or downstream system that consumes its output. Teams most often miss those dependencies, because an extension may quietly feed a dashboard, an email flow or a search index.
Each instance then falls into one of three outcomes. Keep as a function means the logic is small enough to rewrite as server code on the platform you choose. Replace with a service means a dedicated hosted or self-hosted product already covers the job, such as image resizing, email delivery or text search, and its consumers move to that service. Retire means nothing depends on the output anymore, or another path already reproduces the data. Record the outcome, an owner and a decision date for each instance. The Firebase Extensions deprecation FAQ confirms the shutdown date. After March 31, 2027, deployed extensions can no longer be updated, reconfigured or uninstalled, so any instance you cannot yet classify needs a plan well before that date.
Effort grows with the number of projects, the number of instances and the number of consumers per instance, and it does not depend on how many distinct extension types exist. A team with several projects, each running several instances that write into shared collections, needs far more analysis than a single project with one instance. Treat the inventory as the first deliverable of an engagement. It turns unknowns into a list of instances, dependencies and outcomes that a provider can price against a written scope. When you ask for a quote, request that it cites the inventory output, and confirm which projects, environments and data locations are included. Those decisions determine most of the cost before any code is written.
Rebuilding extension behavior as functions on each target platform
Supabase runs server-side code as Edge Functions on the Deno-based Edge Runtime, which is one of the services in the self-hosted Docker Compose stack. Extension behavior that reacts to data changes usually maps to Postgres triggers that call a function, or to an HTTP-invoked function that a database webhook calls. Auth events translate less directly, so teams often rebuild them as a post-signup step in the application or as a function called after sign-in.
- Database triggers: Write a Postgres trigger or webhook for each Firestore-era event, and confirm that the function runs idempotently because retries are possible.
- Auth triggers: Replace user lifecycle hooks with a function invoked from the client or a database trigger on the auth schema, then test each sign-up and deletion path.
- Secrets: Store API keys as function secrets set through the self-hosted configuration, and keep the service role key out of client code.
- Optional service: If no functions are used, the Edge Runtime service can be removed from
docker-compose.yml, but keep it if any extension logic moves here. - Support model: Self-hosted Supabase is community-supported through GitHub Discussions, GitHub Issues, Discord and Reddit, so plan internal ownership of upgrades.
Before cutover, confirm that every extension trigger has an owner, a test case and a monitored failure path in your own environment.
Appwrite runs server-side code as Functions on Open Runtimes, and the sample Docker Compose setup includes an executor that runs them. Appwrite Functions are invoked by events from its services, scheduled jobs or direct HTTP calls, so extension logic that reacted to document or user changes is typically rebuilt as an event-subscribed function. Confirm the exact event names in the Appwrite documentation for your installed version, because the 2.0 line changed the engine underneath the platform.
- Event triggers: Subscribe functions to database and user events, and test the payload shape each function receives after migration.
- Scheduled work: Move any extension that ran on a timer to a scheduled function, and check time zones and overlap behavior.
- Secrets: Store secrets as function variables in the Appwrite project, and rotate them through the same mechanism rather than hard-coding them in the function bundle.
- Executor capacity: Size the executor for peak function volume, since the sample Compose file runs it on the same host as the API and workers.
- Support model: The official Helm chart runs built-in PostgreSQL, Redis, ClickHouse and object storage as single replicas, so production event processing needs managed or operator-run data services. Self-hosted support is the operator's responsibility.
Before cutover, test each function against a restored copy of the data and confirm that failed executions are visible in your logs.
PocketBase extends its server with JavaScript hooks, which suit smaller apps where the whole backend is a single executable with embedded SQLite. Record and auth events can be handled in hook code that runs inside that process, so extension logic often fits here without an extra runtime. The trade-off is that the whole backend shares one process and one database file, so heavy or long-running work should move elsewhere.
- Record and auth hooks: Attach handlers to record create, update and delete events, and to auth events, then verify each handler on a copy of the database.
- Secrets: Keep API keys in environment variables supplied to the process, since hook code is part of the deployed application.
- Scale limits: PocketBase scales vertically, so measure whether a single node handles the peak load the extensions produced.
- Compatibility: Pin the release you test, and review the releases page before each upgrade because the project is pre-1.0.
- Support model: PocketBase is self-hosted only and developed on a volunteer basis, with no promises of maintenance or support beyond what is available, so the team must own fixes.
Before choosing this path, confirm that the app's data volume and concurrency fit a single node and that no extension depends on a service PocketBase cannot host.
Keeping extension logic on Firebase Cloud Functions buys time while the wider platform decision is made, but it still requires action. Cloud Functions requires the Blaze plan, which is pay-as-you-go, so the cost of function invocations and related services continues. Logic that was an extension must be redeployed as your own function code, since extensions themselves stop being updatable, reconfigurable or removable after March 31, 2027.
- Rewrite before the deadline: Copy each extension's behavior into your own function source, because the deployed extension will not receive fixes after shutdown.
- Billing: Confirm the Blaze spend limits and alerts you have set, since usage-based billing applies to invocations and outbound calls.
- Secrets: Move values into Firebase's secret management and remove any configuration that lived in the extension instance.
- Migration path: Record which functions must move later, so the Supabase, Appwrite or PocketBase tab can be applied per function.
- Support model: Support comes from Google's Firebase documentation and support channels for the platform, while your team owns the code.
Before relying on this option, read the Firebase extensions deprecation FAQ and confirm your exact extension list and dates in the Firebase console.
Export and cutover sequence with verification at each step
This sequence moves each extension's configuration, data and users off Firebase in an order that keeps a working copy of every step until the new functions are verified against the export. Each step closes with a check, so the cutover happens only after the data and triggers match.
Freeze the extension inventory
Before any export, list every installed extension in each Firebase project, with its version, configuration parameters, the Firestore collections, Storage paths and Realtime Database paths it reads or writes, and the triggers it registers. The owner of each application signs off on the list, and the list is saved as a versioned file in your own repository. The step is done when every project has a complete list that the application team has reviewed and no extension is left unassigned.
Export configuration and each data store
Record each extension's parameter values, then export every data store the extensions touch, starting with Firestore collections through managed exports to Cloud Storage and the Realtime Database as JSON. Store the exports in a location you control and note the permissions and costs that apply to each export. The check is a manifest that lists each collection or path with its document or node count, so that later comparisons have a fixed reference.
Export Authentication users with hash parameters
Export user accounts with the Firebase CLI so that password hashes and their scrypt parameters come with the records, since the target platform needs them to verify existing passwords without a reset. Confirm the export includes the expected number of accounts and the providers each account uses. The check is a count comparison against the console total and a test login on a copied account in the target environment before anything else moves.
Export Storage objects
Copy the files that extensions created or process, such as resized images or generated documents, from Cloud Storage to a bucket you own, keeping the original paths so that references in documents still resolve. Record the object count and total size per bucket. The check is a sample of files opened from their new location and a comparison of object counts against the bucket listing from the manifest.
Rebuild each extension as a function
Rewrite each extension's logic as a function on the target platform, such as Supabase Edge Functions or Appwrite Functions, and map each Firebase trigger to an equivalent database or auth event on the new side. Store the parameters that were set in step two as environment configuration. The output is a repository with one function per extension, a mapping table of old triggers to new ones, and a short note on any behavior that cannot be reproduced exactly.
Run new functions beside the old ones
Run the rebuilt functions against a staging copy of the imported data while the Firebase extensions keep running in production. Make a test write that the old extension would handle and confirm that each new function fires once and produces the same result. The check is a log comparison showing one invocation per event on each side, with no duplicate writes and no missed triggers.
Verify counts and sample content
Compare record counts for every collection, path and bucket against the manifest from step two, then spot-check a set of documents and files chosen across each data type, including the oldest and newest records. Confirm that imported users can sign in and that references between records resolve. The step is complete when every count matches, every sampled record reads correctly, and any difference is explained and signed off by the data owner.
Cut over traffic and remove the extension
Switch application traffic to the new backend in a planned window, then disable the Firebase extension's triggers so they cannot run twice, and watch logs for duplicate or missing events. Once the new system has run cleanly, uninstall each extension before March 31, 2027, the date Firebase Extensions shuts down, and keep the final export as the archived record. The output is a signed cutover record and a confirmation that no Firebase extension remains active.
What to plan before the Firebase contract or billing changes
Firebase Extensions stop receiving updates on March 31, 2027, so the work splits into decisions that must be made early and tasks that take time to finish. The cards below cover the billing, timing, residency, operations and budget questions that shape how much room the team has before that date.
Confirm which Blaze charges continue
Extensions run on top of the Blaze plan, and several of the services they touch, such as Cloud Storage for Firebase, already require Blaze. Before planning a parallel run, list every Firebase service the extensions depend on and confirm with Google which charges will continue while both stacks are live. Ask the billing team to tag costs by service so the overlap period is visible on the invoice.
Work backward from the deadline
Set the removal window from the shutdown date rather than from when the team starts work. Each deployed extension needs its function rebuilt, tested against real events, and cut over, and some will reveal dependencies that take longer to resolve. Schedule freeze dates for schema and configuration changes so that the last extension is retired with room to spare, not on the final day.
Fix where auth and data reside
Firebase Authentication processes data only in the United States, and a Cloud Firestore location cannot be changed after provisioning. If your obligations require EU or other regional residency, decide the target region before any data moves, because the replacement's location becomes a fixed choice. Confirm with your legal and privacy teams whether the extensions currently export data to any location that must be reviewed.
Name the operator and support model
Replacing extensions with self-hosted code moves patching, scaling and incident response to your team or a partner. Decide who owns the Docker or Kubernetes deployment, who receives upgrade notices, and who answers when a function fails at night. Self-hosted Supabase is community-supported, so any response commitment beyond community channels must come from your own staff or a written support agreement.
Budget for parallel running
During cutover, Firebase bills and the new servers both run, and the team pays for time spent on rebuilding functions and testing. Ask each candidate partner or vendor for a written scope that separates one-time migration work from recurring hosting and support. Include the cost of rollback capacity, backups taken before each cutover step, and the staff hours needed for testing.
Plan for the broader Firebase move
Extensions are often the smallest part of a Firebase footprint, so the same deadline can carry Authentication, Firestore, Storage and Functions work. Inventory those services now, since moving users requires password hash compatibility, and Firebase Auth uses a modified scrypt algorithm by default. Testing hash import early shows whether users can sign in without forced resets.
How much effort does replacing Firebase Extensions take and who should do it?
What drives the cost and effort of replacing Firebase Extensions?
The main driver is how many extensions are installed and how much custom configuration each one carries. Each deployed extension is a set of functions, triggers, IAM roles and config values that must be rebuilt as your own code and then tested against real data. Cost has three parts: the internal or external engineering time to inventory and rebuild, the testing and cutover work, and the recurring cost of running the replacement on your own infrastructure. Ask any quote to price each extension separately, list the trigger types it uses, and state whether data migration is included.
How long does it take to move off Firebase Extensions before the deadline?
No fixed duration is set by Firebase for this work, so treat the timeline as something to confirm for your environment. Firebase Extensions shut down on March 31, 2027, and after that deployed extensions can no longer be updated, reconfigured or uninstalled. The duration depends on the number of extensions, whether they touch Firestore, Auth or Storage triggers, and how many environments (development, staging, production) need the change. Ask for a written schedule with milestones for inventory, rebuild, parallel run and cutover.
What does the client need to provide before replacement work starts?
Start with a complete inventory of every installed extension in every Firebase project, including the version, the configuration values and the service accounts or roles each one uses. You will also need named owners who can approve data decisions, read and deploy access to the Firebase projects, and access to the target infrastructure where the self-hosted platform will run. Without a complete inventory, the scope in any written quote will be incomplete, so make the inventory the first deliverable.
Can our own engineering team replace Firebase Extensions without outside help?
Yes, a team with Firebase and backend experience can rebuild extensions in-house, especially if there are only a few and they are simple. The work is mostly rewriting triggers as functions and testing them, which is familiar to most backend teams. Outside help is more useful when extensions handle sensitive data, when many projects must change at once, or when the team cannot spare people before the deadline. Whichever route you choose, confirm who owns the code after handover and who patches it.
What happens if we miss the March 31, 2027 deadline?
According to Firebase's extensions deprecation FAQ, after March 31, 2027 deployed extensions can no longer be updated, reconfigured or uninstalled. That means an extension you have not replaced keeps running in its current state, but you lose the ability to change it, fix its configuration or remove it cleanly. Plan for that state as a security and operations risk, and confirm with Firebase what happens to existing deployments before you rely on any fallback.
Do self-hosted platforms behave the same way as Firebase for these workloads?
Not exactly, so test before you cut over. Self-hosted Supabase runs as a single project, so Studio does not support multiple organizations or projects, which matters if you currently manage several Firebase projects. Appwrite's built-in PostgreSQL, Redis, ClickHouse and object storage each run a single replica without replication or failover, according to its Kubernetes Helm chart docs, so production data needs managed services or operators. Confirm these limits against your availability and multi-project needs before choosing a platform.
What should we ask for in a written quote for this work?
Ask for a per-extension breakdown that lists each extension, its triggers, the replacement approach and the test plan. Request the deliverables in writing, including the inventory, rebuilt functions, runbooks, backup steps and cutover checklist. Confirm the fixed scope, the assumptions about data volumes and user counts, what is one-time and what recurs (such as support or upgrades), and the schedule with milestones. Also ask who performs each task, what the client must supply, and how changes to scope are priced.
How DeployOpen scopes an extensions exit
DeployOpen plans and builds the replacement for each installed Firebase extension as part of a written, fixed scope, then hands the result over with documentation your team can run. The work is done inside your own cloud accounts or data centers, so the replacement services and their data stay under your control.
How we scope
- We inventory every deployed extension, its configuration, triggers and the data it reads or writes.
- We map each extension's behavior to a replacement function, database rule or storage workflow, and flag gaps.
- Scope, deliverables and timelines are agreed in writing before any work starts, and a quote follows from that scope.
How we build
- We rebuild each required behavior as functions or scheduled jobs on your chosen open-source platform.
- We run the replacements against test data and check that triggers fire on the same events as before.
- We harden secrets, access rules and network paths so the new services meet your security baseline.
How we hand over
- We document each replacement with its configuration, dependencies, triggers and the operations it performs.
- We provide a cutover checklist and a rollback plan so your team can switch over before the March 31, 2027 deadline.
- We train your engineers to operate, monitor and update the replacement services after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover patching of the open-source platform and regression tests for rebuilt functions.
- Ask us to confirm response expectations and what is included in the retainer before you sign.
