Qwik Optimizer asset path failures in production deployments

Short answer

The recommended approach is to treat the base path as build-time configuration injected per environment, not a hardcoded value: set the Vite/Qwik base option from an environment variable in your CI pipeline, then verify it by inspecting the built output — specifically q-manifest.json and the URLs baked into the server-rendered HTML — before deploying. The Optimizer does not resolve paths at request time; it stamps the base into chunk URLs and the manifest during the build, so the only reliable "dynamic verification" is a post-build, pre-deploy check that the emitted URLs match the public deployment path.

Likely explanation vs. confirmed behavior

Confirmed, well-established behavior: Qwik's build emits hashed JS chunks plus a q-manifest.json mapping symbols to chunk URLs. The Qwikloader resolves lazy imports relative to the base path baked in at build time. A mismatch surfaces with a distinctive signature: the SSR'd page renders fine, but the first user interaction triggers failed dynamic imports or 404s in the console. If you see that pattern, suspect base path configuration, not application code.

Likely (but environment-dependent) causes, in rough order of frequency:

• base in the Vite config doesn't match the actual public path (e.g. deploying under /app/ or behind a CDN while building with the default /).
• SSR origin misconfiguration behind a reverse proxy — missing X-Forwarded-Host/X-Forwarded-Proto handling causes emitted URLs to point at internal hosts or http instead of https.
• A stale service worker from a previous deployment requesting old hashed chunk filenames that no longer exist.
• CDN or host rewrite rules that strip path segments or query strings, breaking the manifest-driven, path-sensitive imports.

Recommended CI/CD verification

1. Drive the base from the pipeline: base: process.env.DEPLOY_BASE_PATH ?? '/' in the Vite config, with the variable set per environment (staging, production, preview).
2. After npm run build, add a pipeline step that greps the output: confirm the base prefix appears in dist/build/q-manifest.json and in a rendered HTML entry point. A simple check like grep -q "${DEPLOY_BASE_PATH}build/" dist/build/q-manifest.json fails the build early on misalignment.
3. Post-deploy smoke check: fetch one hashed chunk URL through the CDN/proxy and compare response headers against the direct origin to detect path rewriting.
4. If failures are intermittent after a redeploy, unregister the service worker and hard-reload in devtools (Application → Service Workers) to rule out stale cached chunk URLs.

How the Optimizer handles overrides

The Optimizer itself doesn't negotiate paths at runtime. During the build it uses the configured base to generate chunk URLs and manifest entries, and the SSR layer uses the request origin (or configured origin) for prefetch and bundle links. Resumability survives across hosts because the serialized state references symbols, and the manifest maps those symbols to URLs — as long as the manifest and chunks are served from the same base the build assumed. This is why hardcoding a CDN origin into base breaks staging and preview environments: the override is global to the build artifact.

One caveat: exact config keys and adapter behavior vary by Qwik and adapter version, so verify against the version you have installed rather than assuming current docs apply. If you can share the failing chunk URL from the Network tab alongside your base value, the mismatch is usually identifiable immediately.