Skip to Content
EngineeringRunbooksDeployment record

Deployment record

The first release ran on 2026-09-13 following the first release runbook. Every resource below was created by Terraform in the infra repository or by its release script; nothing was created in a console. The record lists identifiers that are safe to publish; secrets and account-specific values live in the ignored envs/dev.tfvars and in Secrets Manager.

The hosts answer and sign-in is configured through the identity provider (runbook step 7, a dedicated trovensa-console registration). Every product still carries the status designed: what the console shows is the designed workflow over illustrative seed data, not a validated product.

Environment

ThingValue
Region / environmentus-east-1 / dev (resource prefix trovensa-dev)
Terraform stateS3 bucket trovensa-tfstate-<account id> with DynamoDB lock table trovensa-tflock (terraform/bootstrap)
Stacksterraform/dns (hosted zones, state key trovensa/dns/terraform.tfstate) and terraform (environment, state key trovensa/dev/terraform.tfstate); both plans read No changes. after the release
ClusterEKS trovensa-dev, Kubernetes 1.35, two t3.medium nodes, load-balancer controller and external-dns via Helm, Pod Identity for the api and worker service accounts
DatabaseAurora PostgreSQL 16.14 Serverless v2 (0.5 to 4 ACU), database trovensa, migration 0001 applied by the migrate Job
RegistryECR repositories trovensa-api, trovensa-web, trovensa-agent (immutable tags, scan on push)
ZoneRoute 53 trovensa.com (owned by the dns stack), delegated from the registrar on 2026-09-13
CertificateACM console.trovensa.com with SAN api.trovensa.com, DNS-validated in the zone, pinned in k8s/overlays/dev/ingress-patch.yaml
Load balancerone ALB trovensa-dev with host rules for console and api; external-dns publishes both names as ALIAS records
Static hostsAmplify apps trovensa-site (apex and www) and trovensa-docs (docs); the apex A ALIAS, the www and docs CNAMEs and the certificate-verification CNAME are Terraform records (imported after the static host wrote them)
Agent runtimeBedrock AgentCore runtime trovensa_agent version 1 from trovensa-agent:acc1bef (linux/arm64), pinned in the api config map with FEATURE_AGENT_RUNS: "true"; the model id is an environment value, never a literal

Running images (short git shas)

WorkloadImage tagReplicas
trovensa-apif6d75ff2 (HPA 2 to 4)
trovensa-web6cc85c52 (HPA 2 to 4)
trovensa-workerf6d75ff (same image, python -m app.worker)1
agent runtimeacc1befmanaged

Verification on the day

curl -fsS https://api.trovensa.com/api/v1/health/ready      # {"status":"ok","version":"0.1.0","env":"dev","database":"ok"}
curl -fsS https://console.trovensa.com/api/health            # {"status":"ok","service":"trovensa-web",...}
curl -s -o /dev/null -w '%{http_code}\n' https://console.trovensa.com/auth/bridge   # 200
curl -s -o /dev/null -w '%{http_code}\n' -X OPTIONS https://api.trovensa.com/api/v1/health -H 'Origin: https://console.trovensa.com' -H 'Access-Control-Request-Method: GET'   # 200
for h in trovensa.com www.trovensa.com docs.trovensa.com; do curl -s -o /dev/null -w "%{http_code} $h\n" https://$h/; done   # 200 200 200
terraform -chdir=terraform plan -var-file=envs/dev.tfvars | tail -1   # No changes.

The unauthenticated GET /api/v1/me answers 401 as application/problem+json with a WWW-Authenticate: Bearer header. TLS on the console host presents console.trovensa.com with the api.trovensa.com alternative name.

Things learned while executing

  • The static host writes the zone records itself when the hosted zone is in the same account. Terraform then fails to create them; terraform import of the four records (apex A, www, docs, the verification CNAME) brings them under management and the next apply only normalises their TTL.
  • A machine that queried api.trovensa.com before external-dns published it keeps a negative answer in its resolver cache for a while; dig @8.8.8.8 and curl --resolve see the record immediately.
  • The api pods can start before the migrate Job has created the tables on a first release; the pod restarts once and the readiness probe holds traffic until the seed succeeds.

Identity provider

Runbook step 7 ran on 2026-09-13 with a dedicated registration trovensa-console in the organisation’s tenant, created with the Azure CLI: SPA redirect URIs for https://console.trovensa.com (root and /auth/bridge) and http://localhost:3100 (root and /auth/bridge), Application ID URI api://<client id>, delegated scope trovensa.access, v2 tokens. The web image is built with the client id and the tenant authority; the API pins the tenant issuer, the client id as audience and the tenant JWKS (infra/k8s/overlays/dev/configmap-patch.yaml). The first person who signs in from the tenant becomes organisation owner and owner of the default program.

What is not done

  • Merge the eight feat/phase-1-build pull requests so main carries what is deployed.

Source: infra/RUNBOOK-first-release.md, infra/terraform/envs/dev.tfvars.example, infra/k8s/overlays/dev/kustomization.yaml, infra/k8s/overlays/dev/ingress-patch.yaml, infra/k8s/overlays/dev/configmap-patch.yaml, PRODUCT-CONTRACT.md section 9

Last updated on
First release