Skip to main content

Vertex — decision log

All decisions below were taken on 2026-09-24 unless stated otherwise. Vendor facts were checked against the linked documentation on that date.

#DecisionWhyAlternatives rejected
D1Environments are named stage and prod"stage" signals UAT with deliberate deploys; avoids the legacy vertex-dev-* AWS namesdev/prod (name collision with legacy), test
D2Code repo + infra repo pattern: <name> and <name>-infraVendor keeps write on code; all cloud credentials and deploy logic live in a TTG-only repo; no paid GitHub plan neededTwo code repos (dev/prod) — duplicate codebase
D3Both stage and prod deploy manually from ttg-infraOn GitHub Free, anyone with write can read every repo secret, so no deploy credential may live in vertexAuto-deploy from vertex (credential exposure), scheduled polling
D4One Cloudflare account, per-Worker scoped API tokensCloudflare supports tokens scoped to Specified Workers with the Editor role (GA 2026-09-15)Separate Cloudflare accounts
D5No Workers Builds (Cloudflare-side CI) for nowBuild tokens are user tokens only ("account-owned token support coming soon") and cannot be scoped to one Worker; the build runs code from the vendor repoRevisit when account-owned build tokens ship
D6Images in GHCR, not ECRContainer registry storage and bandwidth are currently free; packages published from ttg-infra inherit its accessECR
D7Region eu-west-1 (Ireland)Cheapest EU region for the stack (≈10 % below Frankfurt); fully EU for GDPReu-central-1 Frankfurt (+$4.41/month for prod)
D8ECS Fargate, one task per env with three containers (core, identity, cloudflared)No servers to patch, rolling deploys with automatic rollback, stage can scale to zero; containers share localhostEC2 + Docker Compose; merging core and identity (no code changes wanted now)
D9x86_64 task architectureCurrent images already build and run as amd64; no code or build changesARM64 (≈$5.37/month cheaper — revisit later)
D10Private subnets + NAT instanceAWS guidance prefers private subnets for containers that store user data; a NAT instance keeps the standard layout at low costPublic subnet + public IP (cheaper, less isolation); NAT gateway (≈$41/month per env)
D11Dedicated RDS per env, clean startComplete stage/prod separation; no dependency on the legacy VPCShared legacy RDS instance with peering
D12One Cloudflare Tunnel per env, path-based ingressA single cloudflared can route /auth, /api/auth, /api/users → identity and everything else → coreOne tunnel per service
D13Separate Google Cloud project per envInternal/External user type is per project; stage can run in Testing mode with vendor test users while prod stays Internal or brand-verifiedShared OAuth client (would leak the prod secret into stage)
D14Hostnames on thetaxgraph.com: prod <subdomain>, stage stage-<subdomain>Zone is already on Cloudflare (full setup) in the same accountworkers.dev only
D15One infra repository ttg-infra for all TTG apps (renamed from vertex-infra)Shared layer, app stacks and deploy workflows in one TTG-only place; on GitHub Free, environments are unavailable on private repos, so workflows in one repo are not isolated from each other — acceptable while only TTG admins operate itOne infra repo per app (revisit if ownership splits)
D16Naming: common layer ttg-<env>-*, app resources <app>-<env>-*Shared VPC, NAT and RDS are not Vertex-specific; names must survive new appsVertex-prefixed shared resources

Sources