AI & TechnologyFirebase ML Model Hosting Shutting Down: How to Migrate

Firebase ML, including custom model hosting, will be shut down on June 15, 2027, and Firebase's named replacement for hosted TensorFlow Lite models is Cloud Storage for Firebase. If your app downloads a .tflite model through the Firebase ML model downloader, you need to host the file somewhere else and change the download code before that date.

The facts below come from Firebase, Google for Developers and pub.dev, as shown in the sources. I checked each one on October 18, 2026. Google can change a date, so open the linked page before you plan around it.

Disclosure: App369 is my studio. I build and fix Flutter and Firebase apps, and the last section mentions what I sell. Google doesn't pay me for anything on this page.

The dated timeline

I found no other dated step on these pages. For the other Firebase retirements, see my Firebase deprecations table.

What stops, and what the pages leave out

Firebase's banner on its Firebase ML pages reads: "Firebase ML is deprecated and will be shut down on June 15, 2027." For TensorFlow Lite models used for local inference, it says to migrate your apps to use Cloud Storage instead.

Here is what I could not confirm. The Android model downloader page describes getModel() fetching a model you deployed to Firebase, caching it on the device and updating it by download type. None of the pages I read say which of those calls fail on June 15, 2027, or what happens to an app already in the store. They also do not mention the Admin SDK or REST model management. I am leaving those out rather than guessing.

My advice: assume anything that talks to Firebase ML for models stops working on June 15, 2027, including the model downloader in apps you already shipped. Old app versions in users' hands are the real risk, because they keep calling the old path until people update.

What about ML Kit?

Firebase's migration guide does not mention ML Kit on-device APIs. The Firebase ML overview page says ML Kit's on-device APIs are available through a standalone SDK, and it does not say whether ML Kit is deprecated. The ML Kit custom models page says some ML Kit APIs let you replace the default models with custom LiteRT models, and that ML Kit only supports custom image classification models. That page does not mention Firebase ML hosting.

My advice: if you use ML Kit with a model you pulled through Firebase ML, check how that model gets onto the device. If it comes from Firebase ML hosting, it is covered by this guide.

The migration, step by step

This is Firebase's route, which its guide splits into download, upload and configure steps. I have laid it out as seven steps, with my notes.

1. Download your models. In the Firebase console's Machine Learning page, open a model's three-dot menu and click Download model. For many models, click Get command for bulk download, which gives you a curl command. Firebase warns that these URLs expire in 7 days, and the command saves to a local hosted_models folder. Cloud Shell has a 5GB disk limit.
2. Create a bucket. In the console, go to Databases & Storage, then Storage. The guide says this requires a billing account. The Flutter Storage page says the project must be on the Blaze plan.
3. Upload the files. Upload .tflite files one at a time in the Storage section, or in bulk with Firebase's command: gcloud storage rsync --recursive ./hosted_models gs://<your-storage-bucket>/models/
4. Set Storage security rules so your app can read the files. The guide says to ensure your rules allow reads, for example by restricting access to authenticated users. Firebase's rules page shows a pattern like this one, which allows reads and writes to signed-in users. For model files, allow read only, as in the sketch below (my example, not Firebase's), and keep uploads to the console or a trusted admin:

service firebase.storage {
  match /b/{bucket}/o {
    match /models/{fileName} {
      allow read: if request.auth != null;
    }
  }
}

5. Add the Storage SDK for your platform, using Firebase's setup guides for Android, Apple or Flutter.
6. Change the app code to download from Storage, then load the file with your existing TensorFlow Lite library.
7. Optional: Remote Config. Firebase suggests it for updating model paths without a new app release.

My advice: test your security rules with a signed-out user and a signed-in user before you ship. My guide on testing Firebase security rules shows how.

The app code, by platform

Firebase's guide describes the same pattern on each platform. Get a reference to the file from its gs:// URL, download it to a local file, then load it. I list what the guide names here, so check its page for the full samples.

Android

The guide gets a reference with storage.getReferenceFromUrl("gs://YOUR_BUCKET/path/to/model.tflite"), creates a temp file, and calls getFile with success and failure listeners. After the download, you load the file into your TensorFlow Lite interpreter as before.

Apple platforms

The guide gets a reference with storage.reference(forURL:) and downloads to a local file with write(toFile:), handling errors in the completion closure. Its sample uses a placeholder local path, so pick a real location in your app's container.

Flutter

The Flutter plugin you use today, firebase_ml_model_downloader, is marked discontinued on pub.dev, with a note that Firebase ML is deprecated and will shut down on June 15, 2027. Version 0.4.5 was the latest when I checked. Replace it with firebase_storage, which was at 14.0.0 when I checked and lists Android, iOS, macOS, Web and Windows. Add it with flutter pub add firebase_storage path_provider (path_provider was at 2.1.6 when I checked), run flutterfire configure so your default bucket name is in firebase_options.dart, and import it.

The guide gets a reference with FirebaseStorage.instance.refFromURL(...), builds a local path under the app documents directory, calls writeToFile, and listens to snapshotEvents for the task states. Here is my sketch of the same shape. It is not a copy of Firebase's sample, so test it:

import 'dart:io';
import 'package:firebase_storage/firebase_storage.dart';
import 'package:path_provider/path_provider.dart';

Future<File> downloadModel() async {
  final ref = FirebaseStorage.instance
      .refFromURL('gs://YOUR_BUCKET/models/model.tflite');
  final dir = await getApplicationDocumentsDirectory();
  final file = File('${dir.path}/model.tflite');
  await ref.writeToFile(file);
  return file;
}

One thing the model downloader did for you is caching and update logic: it kept the model on the device and updated it by download type. With Storage, you write that part. Check whether the file exists before you download it, and decide when to fetch a newer one.

My advice: keep a copy of the last good model on the device and only replace it after a download finishes, so a failed download never leaves you with no model.

Bundling the model instead

Firebase's guide documents Cloud Storage, not bundling. I mention bundling as an option for a small model that rarely changes: you add the .tflite file as an app asset and skip the download code, the bucket and the rules. The cost is that every model change needs a new store release, and a bigger app. If your model changes often, or is large, Storage with Remote Config is the better fit.

Optional: LiteRT CompiledModel

If your app uses the legacy TensorFlow Lite Interpreter API, Firebase's guide suggests moving to the LiteRT CompiledModel API, which it says offers improved hardware acceleration support. The LiteRT page says Interpreter "remains available for backward compatibility" and that CompiledModel is where new performance and accelerator features are prioritized. It lists Kotlin, C++, Python and JavaScript examples for CompiledModel.

I would do this as a separate change. The shutdown deadline needs the hosting move only, and mixing in an inference API change makes a bug hard to trace.

A short plan

1. Find every use. Search your code for firebase-ml-modeldownloader on Android, firebase_ml_model_downloader in Flutter and the Firebase ML model downloader on Apple platforms. Check the Machine Learning page in the console for each project.
2. Download every model now, because the bulk URLs expire in 7 days.
3. Enable billing and create the bucket.
4. Upload, set rules and test with a signed-out and a signed-in user.
5. Ship an app version that downloads from Storage, in all your platforms.
6. Leave the old models in Firebase ML until most users have updated, then check which versions still call the old path.
7. Finish well before June 15, 2027, so a slow update cycle on the app stores doesn't strand old versions.

Storage downloads add to your Firebase bill. See my guide on cutting your Firebase bill for what to watch.

For every other dated Apple, Google Play and Firebase requirement in 2026 and 2027, see App Store and Google Play deadlines for 2026 and 2027.

Need a hand?

If your app downloads TensorFlow Lite models through Firebase ML and you want it moved before the shutdown, the App Fix Ticket covers it in two fixed-price steps. A $450 Diagnosis gives you the root cause with evidence and a fixed repair quote within 3 business days, credited toward the fix. If you go ahead, the $1,200 Fix takes 5 business days and comes as a pull request. Or send me a short description.