[Alexanderamiri]

Part 2 of 6. For review; the platform team will not merge it.

Why

The platform builds infrastructure from one file, app.yaml. This PR adds moresleep's app.yaml, written so the architecture stays the same: same database, same size, same configuration, same hostname in the end. It also adds docs/platform.md, which explains how the platform runs moresleep.

What

• app.yaml, phase 1 (parallel run):
  • compute: 256 CPU / 512 MB / port 5000 / health check /. This is the old CDK service's size. desired_count: 0, so no task starts before the secrets are real.
  • routing.host: moresleep.javazone.no (new hostname), priority: 120. sleepingpill.javazone.no keeps pointing at the old stack.
  • resources.databases: adopt: dbmoresleep imports the existing RDS instance, with host_env: DBHOST and port_env: DBPORT.
  • resources.secrets: db-name, db-user, db-password, allaccess-user, read-user. These map to DATASOURCENAME, DBUSER, DBPASSWORD, ALLACCESS_USER and READ_USER.
  • environment: the non-secret values from the SOPS file. ALL_OPEN_MODE: "false" is explicit because the code defaults it to "true" (everyone gets full access). LOAD_FROM_SLEEPINGPILL: "false", DO_FLYWAY_MIGRATION: "false".
• terraform/: the generator's output for this app.yaml. It is committed so the pipeline has nothing to regenerate. Never edit it by hand.
• docs/platform.md: the guide. Start there.
• README.md: a short "Deployment" section that links to the guide.

How the platform piece works

app.yaml ──► scripts/generate-modules.py (in javaBin/platform) ──► terraform/*.tf ──► plan ──► apply

• The generator turns each section into a module from javaBin/platform/terraform/modules. compute becomes ecs-service, routing becomes service-routing (target group, listener rule, DNS record), each secret becomes service-secret (SSM SecureString), and the app always gets an ecr-repo, a service-role and service-alarm. Resource names are <team>-<name>, here moresleep-moresleep.
• adopt: is the important bit for moresleep. It does not create a database. It emits an import {} block, so Terraform takes dbmoresleep into this app's state. The service-rds-adopted module then manages only tags and deletion protection. Class, storage, network, security group and password stay exactly as they are. I checked this with a read-only plan against the real account: 1 to import, 1 to change (tags, deletion_protection), 0 to destroy.
• State lives in the platform state bucket under apps/moresleep/moresleep/terraform.tfstate. Only the moresleep team's CI role (and platform admins) can change resources tagged team=moresleep.

How verified

• app.yaml passes the platform's schema validation. The generated Terraform is terraform fmt clean.
• A local, read-only terraform plan of this exact generated code against the javaBin account (local state, never applied): 1 to import, 22 to add, 1 to change, 0 to destroy. It stops at the missing per-team execution role, which appears once the moresleep team is registered.

Merge when

After these are merged:

• feat(app-yaml): adopt an existing RDS instance and Route53 record platform#155: adds adopt, host_env/port_env and adopt_dns.
• javaBin/registry#40: registers the moresleep team.

On its own this PR deploys nothing, because there is no workflow until PR 3. Because PR 3 deploys whatever this PR describes, also check before merging:

• A manual snapshot of dbmoresleep exists and is available (aws rds describe-db-snapshots --db-snapshot-identifier dbmoresleep-pre-platform-migration-<date>). The first apply imports the production instance and changes its tags and deletion protection; without this snapshot the only backups are the 7-day automated ones. A platform admin takes it; it has not been taken yet.

🤖 Generated with Claude Code