Deploy modes and launch paths Preview

Lite and SaaS differ in audience, entry point, AWS services, and verification status. Use the competition organizer manual for the executable Lite procedure. The SaaS sections here describe repository architecture; they are not a recently live-verified setup procedure.

Two deploy modes

• Lite mode — One organizing group runs an event in its own AWS account. The recommended lite-pipeline.yaml entry point uses CloudFormation to create CodeBuild, which runs make deploy. It does not use AWS CodePipeline. A local checkout can also run make deploy directly.
• SaaS mode — Repository architecture for serving tenants to multiple organizations. It contains make deploy-saas, pooled and silo tenants, System Admin, and a CodePipeline for existing-tenant updates, but no recent recorded fresh-AWS run covers setup through teardown.

Treat Lite as the current organizer procedure. Re-verify SaaS in a dedicated environment before evaluating it.

How a new tenant is provisioned

SaaS architecture reference: This and the next section are not used by a current Lite event.

New-tenant provisioning and pipeline rollout are different paths — this is the distinction the old docs got wrong.

• A tenant creation event (onboardingRequest) is picked up by the SBT BashJobRunner, which runs provision-tenant.sh. By default the tenant is pooled (it shares the pooled stack); only a PLATINUM tier tenant gets a dedicated silo stack deployed directly (bun run cdk -- deploy tenkacloud-tenant-template-<id>).

So creating one tenant does not run the CodePipeline; it runs a provisioning job.

What the SaaS pipeline is for

tenkacloud-saas-pipeline (CodePipeline) exists to roll out tenant stacks across every existing tenant, not to create one. Its source is an S3 object (source.zip, uploaded by prepare-source-bundle.sh during make deploy-saas) that the pipeline polls; on a change it walks the tenant list from DynamoDB and deploys / updates each tenant stack in waves (a Step Functions WaveIterator driving CodeBuild). New-tenant creation and existing-tenant rollout therefore travel different routes.

How a problem deploys

When an organizer clicks Deploy in the console:

1. The console calls the Deploy API, which validates the request, writes a row to the Deployments table, and puts a DeployCreateRequested event on the bus.
2. A Step Functions execution starts a CodeBuild job (.sync).
3. The worker assumes a role into the competitor account using the tenant's ExternalId (always required) and runs a CloudFormation CreateStack there.

The console then polls deployment status until the stack reaches a terminal state.

Problem packs

Problem packs (see the first pack tutorial) ride the Lite path only. Lite reads activations for the fixed tenant id local at synth time, so activate with --tenant local before make deploy. SaaS mode fails loud at synth instead when any pack activation exists — it does not silently drop them from the pooled catalog. Set CDK_PARAM_SAAS_IGNORE_PACKS=true to override and proceed anyway; the activations then simply do not appear in any tenant's catalog.

Related: run an event end to end and the platform architecture.