An isolated origin per release
Each approved release is served from its own origin (<build-id>.<play domain>), separate from the store and from other games. Players reach it only through a short-lived launch ticket, so the game never sees store cookies, and one game cannot read another's storage.
The player page embeds the game in a sandboxed frame (allow-scripts allow-same-origin allow-pointer-lock). Popups, new windows and navigation away from the game are not available.
What your build may load
Every response carries a Content Security Policy built from your upload settings:
| Resource | Allowed |
|---|---|
| Scripts, styles, images, media, fonts | Your build's own files, plus the origins you declared |
Network (fetch, WebSocket) | Your declared HTTPS and WSS origins, plus PEERLESS multiplayer services your build uses |
| Workers | Your own files and blob: URLs |
| WebAssembly | Allowed (wasm-unsafe-eval) |
| Frames, plugins, forms | Not allowed |
Declare exact origins such as https://api.example.com and wss://play.example.com. Wildcards are rejected. Declaring an origin does not configure your server: allow the game's isolated origin in your backend's CORS settings.
Files and service workers
Only files recorded during the upload checks are served, at the paths they had in your ZIP. Service workers are refused. The runtime adds one small script to your HTML entrypoint so the player's volume and mute controls reach your audio; everything else is served exactly as uploaded.
Checks before review
Every upload is scanned for malware and opened in an isolated browser. The check fails a build that contacts undeclared hosts, opens popups or uses excessive CPU, and reports what it found so you can fix the build. Passing checks is a technical milestone; staff review is still required to publish.