Launch and deployment boundaries Preview

This documents the draft integration candidate. Local event/team operation is implemented; cloud platform deployment and complete catalog playability are not verified release claims.

Local platform

make local runs the unified Bun server and two browser applications with persistent SQLite. make down stops owned local runtimes and preserves event data. The removed host target is not a second launch mode. See getting started for bootstrap, event creation and participant login.

Cloud platform: restored competition backend

make deploy and make destroy execute the current Lambda setup and platform teardown CLI with selectable Turso/DynamoDB. They reuse the standard CDKToolkit; only a missing toolkit triggers reviewed official cdk bootstrap inside make deploy. The default bootstrap CloudFormation execution role uses AdministratorAccess, so review bootstrap trust, caller permissions and application IAM changes. Existing toolkits are not rewritten; earlier custom TenkaCloud toolkits remain untouched. Cloud hosting uses 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. Destroy shows the account, region and owned targets, then removes platform hosting and its default-owned data. It leaves external Turso rows; make destroy-all explicitly resets them. Use event Teardown before platform removal for exercise cleanup. Retained resources can continue to incur charges. The preserved infrastructure/templates/cloud-pipeline.yaml defaults to the current CLI and explicitly approved unattended bootstrap/deployment. Review its broad CodeBuild caller role and source refs before creating or starting it. A container build is not deployment evidence or a zero-cost promise.

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.

Each cloud deployment uploads a fresh <configured-key>.executions/<uuid>.zip and requires source-bucket versioning. Current unique keys are not removed by the noncurrent-version lifecycle. Archives consume storage until separately reviewed source-bucket cleanup after referencing events finish. Platform destroy removes its owned execution snapshots, while the separate source archive bucket survives. Source tests and synthesis do not establish a live AWS or hosted Turso rehearsal.

Exercise deployment is separate

Local events use owned Docker Compose projects or native Battle execution. AWS-service problems are cloud-only and require reviewed competitor account/region/role configuration with ExternalId. Docker/Compose exercises are local-only and are not listed in the cloud catalog. Native Cryptography Battle runs on both hosting options. Exercise resources can incur charges; stopping a local process does not remove resources created by an older AWS-enabled revision.

New installations use tenkacloud-cloud stack names; existing tenkacloud-lite stacks keep their names. The CLI discovers Lite/cloud installations; if both exist, explicitly choose TENKACLOUD_STACK_LAYOUT=lite or cloud. Original Lite updates verify ownership and persistent resource IDs. Original unpinned Lite installations require a one-time confirmation that no active competitions remain, after resource/schema checks and before bootstrap, source upload or deployment. Keep active competitions on their installed version until completion. After verifying that condition, confirm interactively or use CLOUD_ARGS="--confirm-no-active-events" for a noninteractive upgrade; generic --yes cannot bypass this check. A legacy catalog key alone does not prove a safe upgrade, and historical data is not migrated automatically. New and already-restored installations keep ordinary automatic make deploy behavior. Published cloud-v1 resource/database layouts cannot be updated in place, and no data is migrated automatically. --drain-events is unavailable; finish event Teardown before removing the platform.

Both databases admit 99 teams; SQL coordination retains the original 4 MiB state policy. Nine current catalog templates exceed the 51,200-byte TemplateBody limit, and TemplateURL is not implemented. This is not an all-AWS-problems deployment claim.