Describe the bug
WebContainer.boot() works on localhost but hangs in production because the generated request to https://stackblitz.com/headless returns 404.
This resembles #2056, but our production page does not use Referrer-Policy: same-origin. It currently uses strict-origin-when-cross-origin, and a cross-origin echo test from the page confirms that the browser sends:
Referer: https://freebuff.com/
The API key is enabled and https://freebuff.com is listed under Allowed sites. The client_id query parameter is present and matches that key. Replaying the request with an explicit Referer: https://freebuff.com/ still returns 404.
The account currently uses the free plan. If this key is missing an entitlement required for a production custom origin, could you please confirm that? The API Console permits creating/enabling the key and adding the domain, but /headless only returns a generic 404.
Link to the blitz that caused the error
https://freebuff.com
The production project currently requires authentication. We can provide access or more request details privately. The failure happens before project code or dependencies are mounted: the /headless runtime itself returns 404.
Steps to reproduce
- Create and enable a WebContainer API key in the StackBlitz API Console.
- Add
https://freebuff.com under Allowed sites.
- Serve the top-level project page with:
Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin
Referrer-Policy: strict-origin-when-cross-origin
- With
@webcontainer/api@1.6.4, call configureAPIKey() before WebContainer.boot({ coep: 'credentialless' }).
- Open the production project page.
- Observe that the generated request below returns 404:
https://stackblitz.com/headless?client_id=wc_api_zedmatedu_…5a7704&coep=credentialless&version=1.6.4
WebContainer.boot() never resolves.
The key is partially redacted here because this is a public issue. It can be shared privately if needed.
Expected behavior
The authorized /headless request should return the WebContainer runtime and WebContainer.boot() should resolve.
Parity with Local
Screenshots and request evidence
The failed response is an ordinary StackBlitz 404 page and therefore also triggers Chrome's Cross-Origin-Resource-Policy: NOT-SET diagnostic. We believe that diagnostic is downstream of the 404, not its cause.
One failing request:
Timestamp: Mon, 20 Jul 2026 23:21:27 GMT
Status: 404
StackBlitz x-request-id: 82323b76-035b-4816-9ad2-b9149e674e52
A fresh browser-like replay with the correct key, Referer: https://freebuff.com/, iframe fetch headers, and a unique cache-busting parameter also returns 404. Adding corp=1 as discussed in #2100 does not change the 404; we use @webcontainer/api's /headless path rather than @stackblitz/sdk's /run or /edit embed paths.
Platform
- OS: macOS
- Browser: Chrome/Chromium 144
- WebContainer API: 1.6.4
- Production host: Cloudflare in front of Render
Additional context
The deployed page headers have been verified through Cloudflare and Render. The SDK-created hidden iframe already has allow=\"cross-origin-isolated\". Could a maintainer inspect the request ID above and confirm whether the rejection is due to key/domain propagation, account entitlement, or another authorization condition?
Describe the bug
WebContainer.boot()works on localhost but hangs in production because the generated request tohttps://stackblitz.com/headlessreturns 404.This resembles #2056, but our production page does not use
Referrer-Policy: same-origin. It currently usesstrict-origin-when-cross-origin, and a cross-origin echo test from the page confirms that the browser sends:The API key is enabled and
https://freebuff.comis listed under Allowed sites. Theclient_idquery parameter is present and matches that key. Replaying the request with an explicitReferer: https://freebuff.com/still returns 404.The account currently uses the free plan. If this key is missing an entitlement required for a production custom origin, could you please confirm that? The API Console permits creating/enabling the key and adding the domain, but
/headlessonly returns a generic 404.Link to the blitz that caused the error
https://freebuff.com
The production project currently requires authentication. We can provide access or more request details privately. The failure happens before project code or dependencies are mounted: the
/headlessruntime itself returns 404.Steps to reproduce
https://freebuff.comunder Allowed sites.@webcontainer/api@1.6.4, callconfigureAPIKey()beforeWebContainer.boot({ coep: 'credentialless' }).WebContainer.boot()never resolves.The key is partially redacted here because this is a public issue. It can be shared privately if needed.
Expected behavior
The authorized
/headlessrequest should return the WebContainer runtime andWebContainer.boot()should resolve.Parity with Local
Screenshots and request evidence
The failed response is an ordinary StackBlitz 404 page and therefore also triggers Chrome's
Cross-Origin-Resource-Policy: NOT-SETdiagnostic. We believe that diagnostic is downstream of the 404, not its cause.One failing request:
A fresh browser-like replay with the correct key,
Referer: https://freebuff.com/, iframe fetch headers, and a unique cache-busting parameter also returns 404. Addingcorp=1as discussed in #2100 does not change the 404; we use@webcontainer/api's/headlesspath rather than@stackblitz/sdk's/runor/editembed paths.Platform
Additional context
The deployed page headers have been verified through Cloudflare and Render. The SDK-created hidden iframe already has
allow=\"cross-origin-isolated\". Could a maintainer inspect the request ID above and confirm whether the rejection is due to key/domain propagation, account entitlement, or another authorization condition?