Publish and update your app

Build and host

Run npm run check and npm run build. Serve the generated dist/ directory over HTTPS. The starter uses relative asset URLs, so a subdirectory works. It uses query-based example routes, so it does not need an SPA history fallback; add a fallback if your own application uses History API routes.

Your registered application, stream-overlay, and in-game-overlay URLs may share one build. Use ?view=overlay&demo=0 for the starter's live overlay. Demo links should say they use demo data. The unregistered starter placeholder must be replaced with your database-issued binding before live use.

Production HTML should revalidate; versioned scripts and styles can use immutable caching. Deploy the complete build together and retain assets needed by already-open sessions. Do not mix lazy chunks from different releases.

Allow the intended embedding

W3Booster embeds app surfaces. A blanket X-Frame-Options: DENY or SAMEORIGIN can prevent your remotely hosted app from loading. If you set CSP frame-ancestors, include the actual approved client/compositor origins you support and verify the Electron context too. Desktop and web hosts may differ; do not blindly copy a permissive wildcard policy.

App assets, SDK endpoints, and artwork may have separate origins. Ensure your CSP allows the network and image destinations your app uses. Never put user session credentials or browser-source secrets in deployed configuration. Client IDs and generated definitions are public metadata.

Stream and in-game surfaces

Make both html and body transparent and verify the final rendered background. Keep navigation, debug panels, and action buttons out of the overlay surface. Test several viewport sizes and missing data. In-game positioning and DPI alignment belong to the W3Booster host; your app renders within the provided viewport.

The user adds their stable W3Booster browser source to OBS. An individual app URL is not a substitute: the compositor supplies app-specific authorization and stacks enabled overlays. Check the app installation, individual surface switches, and global overlay switches when something is missing.

Test privately, then request review

Complete the app's name, description, screenshots, homepage/source links, scopes, and surface URLs. Invite testers through private invitation codes. A tester still installs and enables the application. Test initial load during an active match, no match, reconnects, revoked access, missing fields, settings changes, and every supported surface.

Request review from the app's developer page. Approval is required before public discovery. Follow the current platform review workflow rather than assuming a code deployment publishes the app record. Installation and enabling are different states; disabling preserves the library entry while revoking runtime access.

Update a definition and its bundle together

Changing database scopes or settings changes the definition revision. Regenerate the binding, review its diff, build, deploy, and verify a fresh launch. An old bundle may reject with APPLICATION_DEFINITION_MISMATCH during this transition; plan the release and provide actionable UI. Preserve the application's immutable client ID when renaming or updating it.

The SDK follows semantic versioning. Read its compatibility policy and changelog before upgrades. Test with a registry artifact, not an uncommitted local SDK link.

Prerelease addresses

The product and documentation site currently lives at https://w3booster.com/. Use that canonical address in app help links. The API, static catalog, compositor, and app origins remain separate. Do not derive their URLs by replacing the website hostname; the SDK selects platform endpoints.