"Error: Service messaging is not available" only when self-hosting

[ModalityZ]

My site is able to register for webpush and receive notifications when using the js sdk from Google's CDN, but when I self-host I consistently get "Error: Service messaging is not available". When I switch back to the CDN, everything works fine using the same browser installation (Chrome beta/Linux).

I need to self-host because some browsers like Edge/macOS block cross-site scripts by default.

I have searched issues here, the firebase Discord history, and via Gemini about self-hosting the firebase js sdk but haven't found any steps beyond those I'm already trying:

1. npm install firebase
2. Copy firebase/ from node_modules/ to my own CDN (having the same origin as the host page).
3. Update my imports to use my own CDN

I've stepped through the invocation of the initializing of the messaging instance but I can't spot a reason for the failure. (Firebase heartbeats make this a challenge, btw.)

[initial-d]

Service messaging is not available usually means the Messaging component was never registered with the Firebase app/container. Since the same app works from the Google CDN, I would suspect the self-hosted module graph rather than Web Push itself.

The important distinction is: copying node_modules/firebase/ to a CDN is not the same as serving a browser-ready Firebase bundle. The npm package is meant to be consumed through a bundler or through its package exports. If you import files directly from a copied package directory, it is easy to load firebase/app but fail to load the firebase/messaging entrypoint that performs the side-effect registration. Then getMessaging() asks for the messaging service and Firebase says that service is not available.

I would verify these first:

import { initializeApp } from ".../firebase/app";
import { getMessaging, isSupported } from ".../firebase/messaging";
// or, if using compat scripts, make sure both app-compat and messaging-compat are loaded

and not only the app module.

For self-hosting, the safer approaches are:

1. Bundle Firebase into your app with Vite/Webpack/Rollup and self-host the generated JS assets from your own origin.
2. If using compat/global scripts, self-host the built browser files that match the CDN style and load them in order: app first, messaging second.
3. For the service worker, make sure it uses the matching SDK style too. Classic service workers usually use importScripts(...) with compat builds; ESM service workers need type: "module" support and correct module URLs.

I would also add this diagnostic before calling getMessaging():

console.log("messaging supported", await isSupported());

If isSupported() is true with the CDN but the self-hosted build still throws Service messaging is not available, that strongly points to the messaging module not being loaded/registered. In that case, do not copy the raw npm package directory; either bundle it or serve the correct built SDK files with the same entrypoints your CDN version used.

[ModalityZ]

Thanks, that is very helpful. My site does not use a bundler nor framework. The service worker uses the compat version, while the host page uses an ESM to request a token via messaging.

I just followed your safer approach as well as I could in this way:

1. Downloaded the following and put them in my own CDN:
   • https://www.gstatic.com/firebasejs/12.16.0/firebase-app.js
   • https://www.gstatic.com/firebasejs/12.16.0/firebase-messaging.js
   • https://www.gstatic.com/firebasejs/12.16.0/firebase-app-compat.js
   • https://www.gstatic.com/firebasejs/12.16.0/firebase-messaging-compat.js
2. Added checks in both the ESM and SW for isSupported before invoking getMessage

I breakpointed in the ESM and SW where isSupported() is invoked and in both places it returns true. However in the ESM just after that, invoking getMessaging still encounters "Service messaging is not available".

I'm testing with Chrome beta 151.0.7922.34 (Official Build) beta (x86_64) on Linux.

[ModalityZ]

In case it matters, the SW uses a custom filename and query parameters are appended.

I append query parameters so that a PWA manifest can be generated by the SW's fetch handler, because the site provides different PWAs having different start_url's.

[initial-d]

That extra detail is useful. If isSupported() is true but getMessaging() still says Service messaging is not available, I would focus on whether initializeApp() and getMessaging() are coming from the same modular SDK module graph.

In the modular SDK, firebase-app.js and firebase-messaging.js are not just independent scripts; the messaging module has to register the messaging component with the same Firebase app/container implementation that created your app. If your self-hosted imports accidentally load two different copies/URLs of the app internals, isSupported() can still return true, but the app instance you pass to getMessaging(app) will not have the registered messaging provider.

I would try one of these clean setups, avoiding a mixed graph:

Option A: one bundled modular page build

Use a small local entry file and bundle it, then self-host the bundle:

import { initializeApp } from "firebase/app";
import { getMessaging, getToken, isSupported } from "firebase/messaging";

const app = initializeApp(firebaseConfig);
if (await isSupported()) {
  const messaging = getMessaging(app);
  // getToken(messaging, ...)
}

This is the least fragile because the bundler guarantees that app and messaging share the same dependency instance.

Option B: compat everywhere for no-bundler usage

If you really want script-style self-hosting, use compat consistently on both the page and the service worker:

<script src="/firebase/firebase-app-compat.js"></script>
<script src="/firebase/firebase-messaging-compat.js"></script>
<script>
  firebase.initializeApp(firebaseConfig);
  const messaging = firebase.messaging();
</script>

and in the SW:

importScripts("/firebase/firebase-app-compat.js");
importScripts("/firebase/firebase-messaging-compat.js");
firebase.initializeApp(firebaseConfig);
const messaging = firebase.messaging();

I would avoid modular ESM on the page + compat in the service worker while debugging this. It can work in some setups, but it makes it harder to prove that both sides are using the same SDK style and version.

The custom service worker filename/query params are probably not the direct cause of Service messaging is not available in the page. That error happens before token registration details matter. But later, when calling getToken, make sure you explicitly pass the registration if your SW is not the default /firebase-messaging-sw.js:

const registration = await navigator.serviceWorker.register("/your-sw.js?...", { scope: "/" });
await getToken(messaging, { vapidKey, serviceWorkerRegistration: registration });

So my next test would be: make a tiny page that uses only compat scripts from your CDN. If compat works self-hosted, the issue is your modular ESM import graph. If compat also fails, then inspect MIME types, redirects, and whether the self-hosted files are byte-for-byte the expected browser builds.