Windows Store packaging is a single point of failure: no self-hostable/offline path means outages block all PWA → Store submissions #5974

Summary

Windows Store packaging for PWAs is a single point of failure. Every path — the pwabuilder.com web UI, msstore-cli (msstore init), and the official GitHub Action — ultimately POSTs to the one hosted service https://pwabuilder-windows-docker.azurewebsites.net/msix/generatezip. There is no self-hostable or offline alternative, because the tool that actually builds the modern (Hosted App) package, pwa_builder.exe, is not publicly available. When that single service is down, it is impossible for anyone to build or submit a Windows package for a PWA — via the site, the CLI, or CI.

The service is returning HTTP 502 right now (see #4842), and the result is a hard stop on all PWA → Microsoft Store releases and updates.

Evidence

• msstore init (the only msstore-cli command that builds a PWA package + writes pwaAppInfo.json) calls the same hosted endpoint internally. So the CLI is not an independent path — it depends on the same service.
• The packaging service (apps/pwabuilder-microsoft-store) is open source, but Resources/cli/pwabuilder/ is empty in the repo. Your own deploy-msstore-to-preview.yml downloads pwa_builder.exe from a key-gated endpoint:

  curl ... "https://pwabuilder.com/api/MsStorePackages/cli?key=${{ secrets.PWABUILDER_CLI_KEY }}"
  

  So the service cannot be self-hosted without a private key that only the PWABuilder team holds. The modern package genuinely cannot be built by anyone else.
• https://pwabuilder-windows-docker.azurewebsites.net/msix/generatezip → 502 Bad Gateway (consistent, multiple retries over time). The legacy pwabuilder-apiv2-node.azurewebsites.net host no longer resolves in DNS.

Impact

A single hosted service outage blocks 100% of PWA Windows Store submissions globally, with:

• no redundancy / failover,
• no self-hostable or offline fallback,
• no public status/health page to even confirm it's a known outage.

For teams using PWAs as their Microsoft Store delivery mechanism, this means releases and critical updates can be blocked for an unbounded amount of time, with no workaround.

Requests (any one of these would resolve it)

1. Self-hostable / offline path — make pwa_builder.exe (or an MSBuild/Windows-SDK-based equivalent) available so teams can build Store packages without the hosted service. The classic package already uses makeappx.exe; a supported offline path for the modern Hosted App package would remove the dependency entirely.
2. Redundancy + health endpoint — run the packaging service with HA/failover and expose a public status/health endpoint so outages are visible and don't take everyone down at once.
3. Documented offline fallback — officially document a hand-authored Hosted App MSIX (manifest + makeappx/makepri) as a supported way to produce a Store-ready package without the service.

Environment

• microsoft/microsoft-store-apppublisher@v1.1, windows-latest GitHub-hosted runner, and a local Windows 11 machine (msstore-cli 0.3.7).
• App type: PWA, packaging from a public URL.

Related

• [BUG] Creation of windows app fails #4842 — Windows app package creation failing (the current outage)
• Is there a way to package PWA for app stores via CLI or GitHub Action? #5470 — no CLI/Action path for PWA store packaging
• Allow non-interactive app selection in init (e.g. --app-id) so PWA publishing works in CI/CD microsoft/msstore-cli#146 — init requires an interactive prompt, blocking CI (separate but compounding issue)

Thank you. The core ask is resilience: PWA → Microsoft Store delivery should not be able to be halted globally by a single hosted service going down.