TenkaCloud Docs
← Home
日本語 English

Getting started 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.

Start a local competition

Use the reviewed checkout, Bun 1.3.11 and its pinned problem submodule on macOS or Linux (including WSL2). Docker Engine with Compose is needed for Docker exercises. Run from the repository root:

git submodule update --init --recursive
bun install --frozen-lockfile --ignore-scripts
make local

The default organizer URL is http://127.0.0.1:5174; the participant URL is http://127.0.0.1:5175. Use the URLs printed by the process. Sign in with the organizer key only; no username or password is needed. Each interactive make local start displays a new key once and revokes the previous organizer key and sessions. To rotate it while running, use make local-reset in another interactive terminal with the same data directory. Events, scores, participant keys and problem data are preserved. Noninteractive and public/container starts retain existing keys without printing them to logs.

Create and play an event

  1. In the organizer console, create an event, its teams and selected problems.
  2. Prepare the selected jobs and inspect every result. New Docker jobs are dormant until a participant starts them; AWS exercises keep their deployment flow.
  3. Start the event from Schedule and give each team the participant URL and its team key.
  4. Open the participant portal with that key. For Docker, choose Start / resume, read and solve the problem, then check the score. Use Stop (keep data) when finished with that environment.

This is one competition system for organizers and participants. There is no separate individual-practice login. Docker catalog/workbench restoration is in progress: catalog visibility is not proof that all 106 problems, terminals or real Docker browser routes have passed.

Stop and resume without resetting data

In another terminal, from the same checkout:

make down
make local

make down stops the managed local process and owned Docker runtimes while preserving the database, scores, keys and Docker data. It does not end the event or remove AWS exercise stacks. The next start restores retained event data; new on-demand Docker jobs remain stopped until participants resume them. Writable layers and volumes survive Stop, but RAM does not. The event clock is not reset. End Event stops scoring; explicit environment teardown removes owned environments. Keep the data directory until cleanup succeeds.

Options use LOCAL_ARGS, for example make local LOCAL_ARGS="--no-build". When using a custom --data directory, pass the same directory to make down.

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.

Set up cloud hosting

Select your intended AWS CLI profile and check it with aws sts get-caller-identity. Run make env-init ENV=development to enter the organizer email, hosting account ID and region. The wizard creates the selected .env only if it is absent. Existing files must be edited when their settings need changes.

For Turso, run make turso-live ENV=development. It guides CLI installation/login, database creation, SSM token storage and an authenticated check, then asks before deployment. For DynamoDB, run make deploy ENV=development after env-init. make turso-live-guide shows offline instructions; make turso-token-rotate ENV=development renews the database token without printing it. Use ROTATE_ARGS="--expiration 30d" for a finite lifetime, and rotate before it expires. See the checkout's infrastructure/README.md for prerequisites, profile selection and every confirmation.

Cloud deployment status

make deploy and make destroy use the current Lambda + Turso/DynamoDB CLI after reviewed IAM setup. 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. Destroy confirms targets and honors deployed removal policies. Ordinary make destroy leaves external Turso rows; make destroy-all explicitly resets them. Exercise teardown is separate. The restored cloud backend does not promise a zero-cost deployment. AWS-service problems are cloud-only. Docker/Compose exercises are local-only and are not listed in the cloud catalog. Live AWS and hosted Turso event capacity remain unverified. The cloud pipeline defaults to the current CLI; review its source settings and deployment role before starting a build.

Codespaces forwarded-origin and exercise routing have not been verified for this candidate. Use the local checkout procedure above until that path has its own evidence.

Next: organizer manual, participant manual and deployment boundaries.

Books and compatibility

自分で作るクラウド競技 and Build Your Own Cloud Competition explain the teaching examples and design. The source of truth for current behaviour is this documentation and its matching checkout. The published book still has legacy setup instructions; docs/book-compatibility.md records the required command, scoring and runtime corrections without changing the external book.

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.