AI Builder keeps overwriting custom service worker on deploy — need ability to control or disable injected service-worker.js

Google AI Studio
, ,
1

Hi everyone,

I’m building a custom React + TypeScript application in Google AI Builder and deploying it directly to Cloud Run using the built-in Deploy button. Overall the workflow is very smooth — except for one major blocker that makes production deployment extremely difficult:

:police_car_light: Issue: AI Builder automatically injects its own service-worker.js on every deploy

Each time I click Deploy in AI Builder, the final Cloud Run container ends up containing a folder structure like:

/server
  └── service-worker.js   ← auto-generated by AI Builder

This file overwrites any service worker I previously added in my project.
Even if I:

  • mirror the same folder structure in my AI Builder project (Server/Public/service-worker.js), or

  • add my own firebase-messaging-sw.js inside a /public folder (recommended in another thread),

…it still gets ignored or replaced during deployment.

The only way to make my Firebase Cloud Messaging logic work is to:

:backhand_index_pointing_right: Manually open the Cloud Run source after every deploy and paste my custom service worker code over the injected one.

This obviously is not sustainable for real development or production.

:speech_balloon: Why this matters

Service workers are core to:

  • Firebase Cloud Messaging (push notifications)

  • PWAs

  • offline caching strategies

  • background tasks

  • custom routing and asset handling

Right now, anyone using AI Builder for a serious application cannot reliably implement push notifications or custom PWA behavior, because the service worker is:

  1. Automatically generated,

  2. Not editable, and

  3. Overwrites all developer-provided service workers on every deploy.

This creates a frustrating loop where developers cannot control a critical part of their app lifecycle.

:pushpin: What other users are experiencing

Several threads on the Google AI and Serverless forums describe similar scenarios:

  • Developers unable to register their own messaging SW

  • AI Studio automatically creating a root service-worker.js

  • Custom SW files in /public or mirrored folder trees not being honored

  • Only workaround being manual patching in the Cloud Run container

This issue seems widespread but unresolved.

:folded_hands: What we need from Google

1. A way to disable or override the auto-generated service worker

Even just a toggle like:

[ ] Use AI Builder default service-worker.js

would solve this instantly.

2. Documentation on how the injection process works

If certain paths must exist (e.g., /public/service-worker.js), we need to know exactly how to provide our own version that will not be overwritten.

3. Access to edit or replace the injected files

Providing developers control (or even partial override hooks) would make PWAs and Firebase messaging possible without workarounds.

:memo: My request

Google AI Builder is incredibly promising — but service workers are essential to modern web apps, and right now the platform prevents developers from using them properly.

Please consider:

  • Allowing custom service worker injection

  • Allowing us to disable the autogenerated SW

  • Or at least documenting how to override it reliably

This would massively improve the experience for anyone building PWAs, Firebase-driven apps, or any app requiring custom SW logic.

Thank you for reading — I really hope this topic sparks discussion and visibility so this can be addressed.

5

I’m still hoping to hear whether anyone else working with AI Builder + Cloud Run has found a reliable way to prevent the auto-generated service-worker.js from replacing custom service workers.

At the moment, my workaround is to manually overwrite the file directly inside the Cloud Run container after each deployment — which confirms my code is correct, but also makes continuous development extremely inefficient.

If you’ve run into anything similar (FCM, PWA caching, or any custom SW setup that keeps getting overwritten), please leave a comment. Even a simple “same issue” would be very helpful for visibility. :folded_hands:

7

AI Builder’s deployment pipeline automatically scaffolds a static hosting layer that includes its own service-worker.js for caching and offline support. That file is generated during the container build stage and packaged from the build output the platform controls, which means any file named service-worker.js in your source is replaced by the generated one before the Cloud Run image is pushed. At the moment this behavior isn’t configurable—AI Builder doesn’t expose a flag or build hook to disable or override the service worker injection, and the /public or /server folder structures aren’t referenced during that stage.

The only reliable way to use a custom service worker today is to bypass the built‑in Deploy flow and export your app, then build and deploy manually to Cloud Run using gcloud run deploy or Cloud Build so your own service-worker.js remains in the container image. You can also host your worker separately under a distinct filename such as firebase-messaging-sw.js and register that explicitly in your app’s code, which avoids collision with the injected default worker. There’s no published configuration toggle yet, so for production scenarios needing full control over PWA or messaging behavior, manual deployment is the recommended path until AI Builder exposes service worker customization in its build options.

—Taz

8

Thanks, Taz — I really appreciate the clarification.
However, this is exactly why this issue needs to be elevated internally.

Right now, AI Builder’s auto-injected service worker effectively blocks an entire category of production-grade features:

  • Firebase Cloud Messaging

  • Custom PWA caching strategies

  • Offline routing logic

  • Background sync

  • Any app where the service worker must be controlled by the developer, not the platform

Manual export + manual Cloud Run deployment technically works, but it breaks the entire value proposition of AI Builder’s integrated deploy pipeline. If the recommended path for any serious PWA or messaging functionality is “don’t use the Deploy button”, then many real-world use cases become impossible to ship through AI Builder alone.

What we really need is:

  1. A platform-level toggle to disable or override the injected service worker

  2. Documentation on how the pipeline handles SW injection so developers can prepare their projects correctly

  3. A supported mechanism for bundling a custom service-worker.js or merging logic with the default one

Right now developers have zero control over a critical runtime file that modern web apps depend on, and it forces us into unsupported workarounds (like patching the Cloud Run container manually after each deploy).

I hope the AI Builder team can take this feedback seriously — service worker control is essential for real production workflows, and improving this would unlock far more advanced use cases for the platform.

10

It would be extremely helpful to know whether service worker customization is on the roadmap or under review.

Could we get an official comment or acknowledgement from the AI Builder/AI Studio engineering team on whether:

  • service worker overrides will be supported,

  • the injected SW can be disabled,

  • or build hooks/config flags are planned for future releases?

Even a rough confirmation that this issue is recognized would help developers plan our deployment strategies more clearly.