When one domain must host several PWAs

Building a Progressive Web App across multiple origins is a known pain point: same-origin policy blocks service workers, caches, and permissions from being shared. The opposite problem is just as common: an organization wants to ship several distinct PWAs that still read as part of the same brand or service, using a single domain name to signal that connection.

For example, an ecommerce site may want a separate, installable inventory tool for sellers alongside its main storefront. A sports news site may want a standalone app for a major event, with its own notifications, that users still recognize as coming from the news company. A company may want independent chat, mail, and calendar apps, each installable on its own, but clearly tied to the same name.

Before choosing an architecture, it helps to get the terminology straight:

  • Domain: Any sequence of labels as defined in the Domain Name System (DNS). For example: com and example.com are domains.
  • Hostname: A DNS entry that resolves to at least one IP address. For example: www.example.com is a hostname; example.com could be a hostname if it had an IP address; com would never resolve to an IP address.
  • Origin: A combination of a scheme, hostname, and optionally port. For example, https://www.example.com:443 is an origin.

Same-origin policy operates on origins, so that term is most precise. But in practice, creating distinct origins on the same domain means using subdomains.

The cleanest way to provide multiple, related PWAs under one domain is to give each conceptually distinct app its own origin via subdomains. A company offering internet apps could host mail at https://mail.example.com and calendar at https://calendar.example.com, with the main service at https://www.example.com. A sports site might create https://footballcup.example.com as an independent, installable app for a championship. Platforms that let customers create branded apps can even assign each merchant its own origin: https://merchant1.example.com, https://merchant2.example.com, and so on.

Separate origins give each app full isolation over the browser features that matter:

  • Installability: Each app has its own manifest and its own installable experience.
  • Storage: Caches, local storage, and all device-local storage are independent; no app can touch another’s data.
  • Service workers: Each app controls its own registered scope.
  • Permissions: Scoped per origin, so users know exactly which service they are granting permissions to, and features like notifications are attributed to the right app.

Apps on subdomains that need to share local data can still do so via cookies; for more advanced synchronization, storage can be coordinated through a server.

Same-origin alternatives and their limits

When separate origins are not possible, PWAs can be built on the same origin using path-level scoping. There are two shapes this can take:

  • Non-overlapping paths: https://example.com/app1/ and https://example.com/app2/.
  • Overlapping or nested paths: An outer app at https://example.com/ with an inner app at https://example.com/app/.

The service worker API and manifest format technically support both. The problem is that the browser will not fully treat these as distinct apps, which leads to real practical issues:

  • Storage: All device-local storage is shared across the origin. Clearing local data for one app—including the cleanup a browser prompts for when uninstalling an app—wipes it for every app on that origin. Apps also share a storage quota, so one app’s heavy usage can starve the others.
  • Permissions: A permission grant or block applies origin-wide. Blocking a permission for one app silently prevents all other apps on the origin from requesting or using that feature. System-level permissions, such as notification settings at the OS level, are still granted per app regardless of whether multiple apps point to the same origin.
  • User settings: Per-origin settings like zoom cannot be adjusted for a single app. If two apps need different zoom levels, the user is forced to apply a compromise setting to both.

Nested paths add worse behavior

The nested-path scenario—outer app at https://example.com/, inner app at https://example.com/app/—adds problems of its own because every URL in the inner app is also in scope for the outer app.

  • Installation promotion: If the outer app is already installed and the user visits the inner app, the browser will not show install promotional banners, and the BeforeInstallPrompt event will not fire—the browser concludes the page already belongs to an installed app. Workarounds are clunky: install the inner app manually via the browser’s “Create Shortcut” menu, or install the inner app first, before the outer app.
  • Notifications and Badging API: If the outer app is installed but the inner app is not, notifications and badges from the inner app will be attributed to the outer app, the nearest enclosing scope of an installed app. Attribution works only when both apps are installed.
  • Link capturing: The outer app may capture URLs that belong to the inner app, especially when only the outer app is installed. Links inside the outer app that point to the inner app will not open in the inner app because they are considered within the outer app’s scope. On ChromeOS and Android, apps distributed through the Play Store as Trusted Web Activities suffer further: the OS treats the outer app as the capture target for all links, even showing it as an option when the inner app is installed.

If a separate origin is not an option, non-overlapping paths are strongly preferred over nested ones. From a user and browser standpoint, the practical ranking is clear:

  • Separate origins: Recommended
  • Same origin, non-overlapping paths: Not recommended
  • Same origin, overlapping and nested paths: Strongly not recommended

Subdomains are the default answer for hosting independent PWAs under one domain. When that is impossible and paths are the only choice, keeping scopes separate and non-nested preserves whatever isolation the browser can offer.

Diving Deeper

For more context on handling scenarios that go beyond a single domain, the article Progressive Web Apps in multi-origin sites provides additional guidance.

Acknowledgements

This work benefited greatly from the technical reviews and suggestions of Joe Medley, Dominick Ng, Alan Cutter, Daniel Murphy, Penny McLachlan, Thomas Steiner and Darwin Huang.