Standout Builder Studio · planning Index / Platform architecture (cross-repo) review Updated 16 Jun 2026

Platform architecture (cross-repo)

The platform spans two repositories and two infrastructure providers. This page describes where each component lives, the seam between them, and the decisions that are now locked vs still open.

CONCEPT · proposed
Two repos, two providers
standout-platform (this repo) — the Cloudflare/D1 control plane. standout-games — the Royale game engine repo, source of game Workers, certified RNG, and shared types. Some components from standout-games are being pulled across into the control plane as the platform consolidates.

Three homes

1 · Control plane — Cloudflare (Workers + D1)

The authoritative registry for games and operators. All operator-facing surfaces and the internal dashboard live here.

Component Repo / path Role
apps/portal standout-platform Operator portal — magic-link login, game catalogue, factsheets, permissioned demos, per-game chat.
apps/web standout-platform Internal dashboard + Builder Studio — pipeline management, operator admin, builder oversight, revenue.
apps/admin * pulling from standout-games Operator management — splitting: super-admin half merges into apps/web; operator-scoped half goes into portal. See Users & surfaces.
games-service * pulling from standout-games B2B launch endpoint — validates HMAC, mints session JWTs, exposes game catalogue to operators. Lives on Cloudflare, talks to AWS runtime over the HMAC adapter contract.
D1 — operator registry standout-platform Source of truth for operators, operator_settings, wallet config, portal grants, game catalogue metadata. Shared across portal, dashboard, and games-service.

* = being pulled from standout-games into standout-platform.

2 · Game service — AWS (managed Postgres)

The stateful game runtime. Handles sessions, plays, bets, and the financial ledger. Intentionally separated from the control plane because of compliance and data-residency requirements on the financial record.

Component Role
Game runtime (ex game-engine) Handles session lifecycle, round resolution, bet/credit flows. Runs on AWS (container or Lambda — TBD).
gs_transaction ledger Financial record — bets, credits, reconciliation. Postgres on AWS (RDS/Aurora) — NOT Cloudflare D1. Decision locked 2026-06-16.
Reconciliation Periodic sweeps against operator wallet confirmations. Runs against the Postgres ledger.
HMAC adapter The contract the AWS runtime exposes to operator wallets — validates HMAC tokens minted by the Cloudflare games-service, authorises debit/credit calls.

3 · Shared libs (across both repos)

Package Role
@standout/shared Shared TypeScript types — game manifest, operator schema, session token shape, wallet contract interface.
game-rng Certified random number generator. Stays a shared lib — certified independently, consumed by both game Workers and the AWS runtime. Never duplicated or forked.
Game SDKs Per-game-type SDKs for Builders — typed wrappers over the HMAC adapter and session lifecycle. Sourced from standout-games, consumed by game Worker templates.

The seam: launch flow

The boundary between Cloudflare and AWS is the session JWT mint. The flow is:

  1. Operator (or a Builder testing in sandbox) calls games-service on Cloudflare with launch parameters (game slug, player ID, currency, jurisdiction).
  2. games-service validates the HMAC on the request and checks the operator's grants in D1.
  3. games-service mints a session JWT — signed with the platform's private key, scoped to the operator/player/game, short-lived.
  4. The JWT is returned as a signed launch URL: https://play.standout.games/launch?session=<jwt>&sig=<hmac>.
  5. The player's browser (or the Builder's sandbox iframe) loads the launch URL. The AWS runtime verifies the JWT, opens the session, and accepts wallet calls over the HMAC adapter contract for the duration of the session.
Operator wallet calls stay on AWS
All bet debit and credit calls go from the AWS runtime directly to the operator wallet — the Cloudflare control plane is not in the financial hot path once the session is open. The HMAC adapter validates that the call originated from a legitimately minted session.

Decisions locked

These decisions are locked — do not re-open without a documented reason
  • Game service + financial ledger → AWS + managed Postgres (RDS/Aurora). Locked 2026-06-16. The gs_transaction ledger and session runtime are Postgres on AWS. Not D1, not Cloudflare.
  • Redis dropped. Redis was scaffolded but never meaningfully used. It is removed from the target architecture. No caching layer between the control plane and game service.
  • Control plane → Cloudflare / D1. Operator registry, game catalogue metadata, portal grants, and all operator-facing surfaces run on Cloudflare Workers + D1.
  • game-rng stays as the shared certified lib. It is not duplicated, not replaced, and not forked. Certification is against a single canonical implementation.

Open decisions

These are genuinely unresolved — they need a human decision
  • (1) Operator identity source of truth. D1 (control plane) vs AWS Postgres. The operator admin UI lives on Cloudflare, so D1-as-truth with a CF→AWS read/sync is the leaning position — the AWS runtime needs operator records for launch validation and wallet calls, but those can be synced or looked up on session mint rather than stored authoritatively in Postgres. Unresolved.
  • (2) Cloudflare edge runtime track. The Workers for Platforms + Rust/WASM edge runtime documented in architecture.html (edge-do, edge-engine, packages/edge-game-sdk) was designed as the game delivery layer. Now that the game service is going to AWS, is the edge runtime track: (a) superseded — the AWS runtime handles this, (b) deferred R&D — we revisit once the AWS runtime is stable, or (c) a parallel track — certain game types (stateless, low-latency) still run on Cloudflare Workers while stateful sessions go to AWS? Unresolved.