Competition organizer manual Preview

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

Prepare the local host

Follow getting started with make local. Keep one process per private data directory. Sign in with the organizer key only; no username, password or local SAML account is needed. Each interactive make local start displays a new organizer key once. To rotate it while running, use make local-reset in another interactive terminal with the same data directory. Both revoke previous organizer keys and sessions while preserving events, scores, progress, participant keys and problem data. Noninteractive and public/container starts retain existing keys without printing them to logs.

Run the event

Create teams and select problems, prepare dormant Docker jobs, inspect failures, then start the schedule. Participants start each Docker environment when needed; AWS deployment remains a separate operation. Distribute the participant URL and each team's key only to that team. Rehearse correct and incorrect submissions, hints, scores, one team's failure, restart and teardown. End Event stops scoring; it does not prove resources were removed.

All 106 former local problems are intended to become Challenge competitions. The generic catalog/workbench is implemented. Real Docker/browser checks covered SQL access and a PostgreSQL terminal, three checkpoints, team isolation and data-preserving restart. Other problem and terminal variants remain unverified. Use the actual selected problem's evidence, not its presence in a picker, to decide event readiness.

AWS problems use cloud hosting

AWS-service problems are for cloud hosting only. Local hosting rejects the old AWS-region switch. 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. Ordinary deploy automatically bootstraps a missing standard CDKToolkit after displaying its scope; review the IAM setup guide. Deployment operators can administer TenkaCloud resources across environments in the selected account; environment names are not an IAM security boundary. Live AWS deployment remains unverified. Live AWS and hosted Turso event capacity remain unverified. Do not use a local command as an alternative cloud launcher. Existing AWS resources require their original reviewed cleanup procedure; keep their ownership records.

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.

Before an original unpinned Lite upgrade, finish all competitions on the installed version and satisfy the explicit no-active-events preflight. Generic --yes and a legacy catalog key do not bypass it; historical data is not migrated automatically.

Storage and shutdown

The local database is SQLite. Back up the complete private data directory consistently, including key files. make down preserves event data and stopped Docker state; use the same data directory on restart. New on-demand Docker environments stay stopped after make local until a participant resumes them. It does not delete AWS resources or reset the event clock. Never delete state that still owns environments.

Cloud hosting uses Lambda + Turso/DynamoDB; make deploy requires reviewed IAM setup; make destroy confirms targets and deletes platform-owned data by default. It leaves external Turso rows; make destroy-all explicitly resets them. Exercise cleanup uses event Teardown before platform removal. 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. A zero-fixed-cost cloud platform has not been established. AWS exercise charges are separate.

After stopping the host, make local-clear confirms removal of competition data and owned Docker exercises while retaining organizer access and host settings. make down preserves data; make local-reset rotates organizer access.

New Docker events prepare dormant team/problem jobs, up to 512 per event. Participants use Start / resume and Stop (keep data). Stop retains the existing writable layer and volumes, not RAM; there is no automatic eviction or reset. Existing events retain their legacy lifecycle.

Defaults allow 3 active environments per team, 12 across the host and a 4096 MiB sum of configured container-memory caps. These are admission limits, not measured usage or machine-size guarantees. New Compose plans preserve authored caps and add 512 MiB memory, 1 CPU and 256 PIDs where missing. Override admission limits with make local LOCAL_ARGS="--max-active-per-team 3 --max-active-environments 12 --container-memory-mib 4096" after reviewing the workload.

The 40 gateway slots apply only to active environments. Dense runtime-port assignments survive Stop. A synthetic 20-problem × 5-team plan allocated 100 jobs using 105 runtime ports; this proves allocation and lifecycle behavior, not concurrent Docker performance. See docs/local-play-requirements.md for measurement guidance.

--drain-events is rejected in the restored backend; finish event Teardown before removing the platform.