Platform architecture Preview

Reading order

Read the responsibilities and trust boundaries before selecting an execution environment. This draft candidate unifies local and cloud competition workflows without SaaS/SBT tenant provisioning.

Local competition and Docker

make local serves organizer and participant applications from one Bun process. Organizer roles and event/team keys authorize separate HTTP surfaces. SQLite and private key files retain competition state and runtime ownership. make down stops owned local runtimes while preserving data; explicit teardown is separate.

New Docker events prepare up to 512 dormant jobs, then participants Start / resume and Stop (keep data). Defaults are team 3 / host 12 active environments and 4096 MiB summed memory caps. The 40 gateway slots are active-only; runtime ports persist while stopped. Writable layers and volumes survive, not RAM. There is no automatic eviction or reset. Existing events keep their legacy lifecycle. The generic catalog and workbench expose all 106 former local definitions as Challenges and 15 declared terminals. Real Docker/browser verification covers representative SQL, PostgreSQL terminal and Battle flows; full play-throughs of all definitions remain incomplete. Verifiers must remain separate from public challenge surfaces and other teams.

AWS exercises and cloud platform

AWS-service problems are cloud-only. The restored CloudFormation workflows use registered competitor roles and mandatory ExternalId in SSM. Participant Console and CLI sessions use the problem's separate participant role. First-account IAM setup uses standard CDKToolkit; ordinary make deploy creates it automatically only when missing, after displaying the target and permission scope. Deployment credentials are never participant credentials. Live AWS access remains a separate rehearsal.

The cloud foundation uses Lambda, Cognito and selectable Turso or DynamoDB, with the restored EventBridge → Step Functions → Lambda/CodeBuild deployment paths. make deploy and make destroy use the scoped CLI with reviewed IAM setup and ownership-checked teardown. Cloud hosting restores the SBT-free Lite backend with Lambda and Cognito, selectable Turso or DynamoDB, generic CloudFormation deployment, flag/multi-flag and scheduled scoring, participant Console/CLI access, and native coordination including Cryptography Battle. Docker/Compose exercises are local-only and are not listed in the cloud catalog. Live AWS and hosted Turso event capacity remain unverified.

AWS resource exercises require a registered, verified competitor account. For your own self-test, confirm the hosting-account risk in the event creation dialog before an event or login keys are created. The acknowledgment is saved only for that event. Problem and participant roles may access or change hosting configuration and data, including across regions; consent does not provide isolation. A separate competitor account is recommended when third parties participate. For an existing event, choose Schedule → Deploy now and confirm the risk when prompted. Consent is saved before deployment continues; cancelling keeps the event unchanged. No recreation or key rotation is needed. Standalone and composite deployments without event membership remain closed to hosting-account targets. Multiple teams may share a separate competitor account in different regions, but global IAM remains shared and the catalog IAM audit has unresolved findings. This is not proof of complete isolation or least privilege for every problem.

The reviewed native ac26-crypto-battle profile with defaultScoreStealEnabled=false needs no Docker or competitor AWS account. Setting the score-steal parameter to true retains its AWS-backed variant and requires a verified competitor account.

Problem deployment and scoring

An authenticated organizer requests an event operation. Ownership is saved before external creation. Status, errors and recovery remain durable. Participant requests recheck team, event, problem and time; verified scores, progression and retry receipts commit together before success is returned. A failed verifier or uncertain cloud operation is not a success.

Cloud events and deployments save catalogKey for a private snapshot of catalog maps, hints, plugins and raw sources. An event created with catalog A continues using A after B is deployed or removes its problem. Lambda verifies pinned source hashes; CodeBuild uses the saved source ZIP key and exact S3 VersionId. Older unpinned records require recovery of their verified original snapshot through CDK_LEGACY_CATALOG_KEY; never assign the current catalog by guesswork. This recovery setting does not authorize upgrading an active original installation; finish its competitions on the installed version and satisfy the no-active-events preflight first.

Editable diagram sources

The repository's docs/architecture/README.md identifies the restored AWS-icon system-architecture.drawio and its generator. The drawing preserves the AWS icons and layout conventions while documenting the current local and cloud boundaries. A diagram is not evidence of an AWS event rehearsal.

Cloud design

The current cloud foundation selectively reuses single-installation Lambda + Turso/DynamoDB and Step Functions mechanisms. Logical event/team responsibilities are retained without speculative SaaS abstractions.