An immersive streaming platform is not one big app. It's a set of jobs with very different shapes — a REST API that changes constantly, a player that must be locked down, an encoder that needs GPUs — and forcing them into one deployable is how you get a slow, fragile monolith. ZeusXR runs as 17+ Cloudflare Workers at the edge, with GPU encoding on RunPod and R2 for storage.

Four layers

Requests flow through four layers: devices hit the Cloudflare edge (Workers plus Pages for the frontend), the edge talks to encoding infrastructure on RunPod/Docker, and finished assets land in R2. Each layer has one job and a clear contract with the next.

Why so many Workers

The split follows blast radius and change rate. The main API worker changes daily and carries videos, billing and pairing. The player worker changes rarely and is hardened against cloning — you do not want its release cadence coupled to the API's. Cinema, social and auth each own their data and their failure modes. A bug in the social feed cannot take down playback.

Shared config, never copied config

The one rule that keeps 17 Workers from drifting: shared concerns live in exactly one place. CORS origins come from a single shared module that every Worker imports — never an inlined list. The moment you copy a config value into a second Worker, the two begin to diverge, and six months later one of them is wrong.

Encoding lives off the edge

Workers are perfect for routing, auth and delivery, and useless for transcoding 8K immersive video. That work runs on GPU nodes with CUDA and FFmpeg, orchestrated from the API and autoscaled to demand. The edge never blocks on a long job; it hands off and tracks state.

What we'd tell our past selves

Draw the Worker boundaries around what changes together, not around nouns. "Videos" is a noun; "the thing that must never break in a headset" is a boundary. The second one is the useful one.