Request: Allow overriding or disabling AI Builder’s auto-generated service-worker.js for full PWA + FCM support

Google AI Studio
, , ,
1

Summary

AI Builder’s automated deployment pipeline injects a platform-generated service-worker.js into the Cloud Run image during build. This behavior currently cannot be disabled or overridden, and any developer-supplied service worker is replaced during deployment.

This limitation prevents modern web apps built in AI Builder from implementing Firebase Cloud Messaging (FCM), advanced PWA features, offline routing, asset caching strategies, and background tasks.

Service worker control is fundamental infrastructure for progressive web applications. For AI Builder to be production-ready for real-world teams, developers must be able to override, disable, or extend the auto-generated service worker.

Background: Why Custom Service Workers Are Essential

1. Push Notifications & Firebase Cloud Messaging

FCM requires a developer-controlled root-level service worker, typically:

/firebase-messaging-sw.js
/service-worker.js

Without full control:

  • Messaging APIs fail to register

  • Background notifications cannot be received

  • SW event handlers cannot be implemented

This means notifications — an industry-standard feature — are impossible to configure reliably in AI Builder.

2. Professional PWA Requirements

Modern PWAs depend on service workers for:

  • Asset caching strategies

  • Preloading critical resources

  • Offline application support

  • Background sync

  • App shell architecture

  • Custom fetch handlers

  • Runtime caching policies (e.g., stale-while-revalidate)

Without SW control, developers cannot meet basic Lighthouse PWA requirements.

3. Consistency, Debugging & Production Parity

The inability to control the service worker creates:

  • Build–runtime inconsistencies

  • Debugging friction (the SW in Cloud Run does not match source code)

  • CI/CD instability

  • Non-reproducible builds

  • Hard-to-diagnose PWA failures

Professional teams require a stable, deterministic SW pipeline.

Current Limitations in AI Builder

What doesn’t work today

  1. Providing your own service-worker.js
    → Replaced during deploy.

  2. Mirroring folder structure (Server/Public/service-worker.js)
    → Ignored during build step.

  3. Using /public/firebase-messaging-sw.js
    → AI Builder creates its own /public directory and still prioritizes its generated SW.

  4. Editing Cloud Run container post-deploy
    → Gets overwritten on next deploy, impossible for real workflows.

Impact on Developers and Production Workflows

  • Prevents teams from shipping FCM or push notifications

  • Breaks PWA offline support

  • Blocks enterprise apps that rely on background processing

  • Forces developers away from AI Builder’s integrated deploy flow

  • Destroys development–production parity

  • Makes build output nondeterministic

  • Reduces trust in the deployment pipeline

  • Turns routine development into manual patching workarounds

Developers who test custom service workers confirm their logic works perfectly if manually patched into Cloud Run, proving the issue is exclusively caused by AI Builder’s build pipeline — not developer errors.

Proposed Feature: Service Worker Override Controls

Core capabilities requested

1. Ability to disable AI Builder’s injected service-worker.js

A simple toggle is enough:

[ ] Use AI Builder default service worker

2. Ability to supply a custom service worker

AI Builder should respect:

  • /public/service-worker.js

  • /service-worker.js

  • Explicit configuration in manifest.json or vite.config.js

3. Build hook or manifest setting

Example:

{
  "aiBuilder": {
    "serviceWorker": {
      "mode": "custom",
      "entry": "/public/service-worker.js"
    }
  }
}

4. Option to merge or extend the default SW

If Google has offline caching logic worth preserving, allow:

importScripts('default-sw.js');
importScripts('custom-sw.js');

Technical Implementation Considerations

Option 1: Add a build flag to skip SW injection

Simplest and least intrusive.

Option 2: Allow user-supplied SW to override the generated one

Respect developer files during build.

Option 3: Document how the injected SW is generated

Enable developers to reproduce, extend, or modify it.

Option 4: Optional SW template or plugin system

Lets developers customize caching strategies while retaining AI Builder conveniences.

Success Metrics

After implementation, developers should be able to:

  • Use Firebase Cloud Messaging without manual Cloud Run patching

  • Implement PWA offline strategies

  • Use custom fetch handlers and background sync

  • See consistent service worker behavior between source and Cloud Run

  • Deploy using AI Builder’s built-in Deploy pipeline without breaking SW functionality

  • Avoid manual container edits entirely

Priority: HIGH

Service worker control is not a niche feature — it is foundational to modern web applications, PWAs, and any production-grade frontend architecture.

Without this capability:

  • Push notifications are impossible

  • Offline apps are impossible

  • Advanced caching is impossible

  • Many enterprise workflows cannot adopt AI Builder

This limitation is already pushing developers away from using AI Builder’s integrated deployment flow.

Conclusion

AI Builder’s automatic service worker injection currently blocks real-world production use cases. Developers need explicit control over service-worker.js to implement modern PWA features, Firebase Cloud Messaging, and reliable offline-first workflows.

Request:
Please prioritize adding an option to disable or override the auto-generated service worker, or document an official way to integrate custom SW logic into the build pipeline.

This feature is essential for AI Builder to support professional-grade, production-ready applications.

3

Hi @Edvards_Bukovskis ,

Thank you for your feedback. We appreciate you taking the time to share your thoughts with us, and we’ll be filing a feature request.