Repositories

Every repository that makes up the platform — what each one holds, why it exists, and how it is used. They separate cleanly into the cloud foundation, shared modules/charts, and the applications that run on top.

Platform & infrastructure

u2i-gcp-infrastructure ↗

What: Foundation Terraform (managed with Terramate): the GCP org hierarchy, projects, GKE Fleet, networking, and the per-app CI/CD scaffolding.
Why: It is the single source of truth for the cloud foundation — every project, cluster, and pipeline exists because it is declared here.
Usage: Register a new app by adding an entry under foundation/4-tenants/terramate.tm.hcl; apply with terramate run -- terraform apply. app-cicd.tf then generates the app's triggers, service accounts, registries, and Cloud Deploy pipelines.

u2i-infra ↗

What: The tenant infrastructure reconciled onto the clusters by Config Sync: namespaces, Workload Identity bindings, and GCS buckets per app.
Why: Keeps in-cluster infrastructure declarative and GitOps-managed, separate from application workloads and from the cloud foundation.
Usage: Add a subchart under chart/charts/apps/ and enable it in k8s/{env}/rootsync.yaml. Config Sync continuously applies it to the u2i-nonprod / u2i-prod clusters.

Shared modules & charts

terraform-google-compliance-modules ↗

What: Reusable Terraform modules aligned with ISO 27001 / SOC 2 Type II — zero-standing-privilege IAM, PAM entitlements, organization policies, CMEK helpers.
Why: Encapsulates the compliance controls so every project inherits the same audited baseline instead of re-implementing it.
Usage: Consumed as module sources by u2i-gcp-infrastructure. Versioned; the foundation pins specific module versions.

gke-tenant-charts ↗

What: The shared Helm charts: gke-tenant-foundation (namespaces, Gateway, RBAC), gke-tenant-workload (ServiceAccount + Workload Identity, ExternalSecrets, KEDA), gke-tenant-storage (GCS buckets via Config Connector), gke-tenant-alloydb.
Why: Gives every app a consistent, reviewed deployment surface — apps declare intent and inherit platform conventions rather than hand-rolling manifests.
Usage: Each chart is versioned independently (foundation, workload, storage, alloydb each have their own line — there is no shared version sequence). Publishing runs on the GitHub Actions release workflow — NOT Cloud Build, and NOT on merge to main (a merge only runs lint). The tag NAME is the release: it alone selects which chart is packaged and at what version, so a wrong name publishes the wrong chart or fails — and each chart bumps on its own semver (patch = template fix, minor = additive field e.g. dns.publicZone.records was 0.6.4→0.7.0, major = breaking change). The workflow helm-pushes just that one chart to oci://europe-west1-docker.pkg.dev/u2i-bootstrap/helm-charts, keylessly via Workload Identity Federation. Consumers pin a version in their Chart.yaml dependencies. Two ways to cut a release:

Option 1 — push a tag (recommended)

git checkout main && git pull
git tag gke-tenant-foundation-0.7.1
git push origin gke-tenant-foundation-0.7.1

Option 2 — manual workflow dispatch

gh workflow run release.yaml --repo u2i/gke-tenant-charts \
  -f chart=gke-tenant-foundation -f version=0.7.1

Check what's actually published

gcloud artifacts docker tags list \
  europe-west1-docker.pkg.dev/u2i-bootstrap/helm-charts/gke-tenant-foundation \
  --project u2i-bootstrap

build-lib ↗

What: The shared Cloud Build engine: a Docker image (Nushell + gcloud/kubectl/helm/crane/buildx) plus a Nushell library of typed commands (build image, release package-for-config-sync, kube login, …).
Why: Keeps every app's CI/CD pipeline short and identical — the real build logic lives in one versioned place instead of being copy-pasted as bash across repos.
Usage: App deploy/cloudbuild/*.yaml run the build-lib image with the init-step/build-step wrappers and pin a version tag. See the build-lib page.

Applications

retrotool ↗u2i.dev live · retrotool.io WIP

What: The RetroTool app (Meteor / Node.js). Carries its workload Helm chart, Cloud Build pipelines, Skaffold config, and Dockerfile.
Why: The canonical reference deployment on the platform — the worked example used throughout this documentation.
Usage: Push to main deploys to dev; a version tag promotes through qa to the internal-prod tier; PRs get preview environments. It runs on the prod cluster at app.retrotool.u2i.dev (shared managed-lb cluster-gateway) — but the customer production domain retrotool.io is NOT yet migrated onto this infrastructure. See the Example page.

retrotool-landing-page ↗u2i.dev live · retrotool.io WIP

What: The public marketing / landing site for RetroTool.
Why: Separates the marketing surface from the product application and its release cadence.
Usage: Deployed as its own tenant app; runs on the prod cluster at retrotool.u2i.dev (shared cluster-gateway). The customer domain retrotool.io is not yet migrated onto this infrastructure.

gcp-platform-docs ↗prod live

What: This documentation site itself (Next.js). Its cluster infra (namespaces, Workload Identity, DNS zone + apex record) is declared in u2i-infra; the app ships via Cloud Build + Cloud Deploy → Config Sync.
Why: A standalone internal app and the live onboarding reference — the first non-family app onboarded onto the shared prod cluster-gateway.
Usage: dev/qa on the shared eg gateway; prod at gcp-platform-docs.u2i.dev on the shared managed-lb cluster-gateway.

u2i-compliance-portal ↗nonprod only

What: The U2i Compliance Portal (Elixir / Ash), registered on the platform as app key u2i-comp-portal.
Why: An internal-facing product tenant; exercises the platform's OIDC edge auth (Ash Authentication / Google) in lower envs.
Usage: Runs dev + qa on the nonprod cluster under compliance.u2i.dev (dev.compliance.u2i.dev, qa.compliance.u2i.dev), with per-PR previews. No production deployment yet — when added, prod would be the compliance.u2i.dev apex (or its own brand domain if it goes customer-facing).

compensation ↗prod shut down

What: An Elixir application running as a tenant on the platform.
Why: Demonstrates the platform is language-agnostic — the same foundation, charts, and pipelines host non-Node.js stacks.
Usage: Registered in the foundation like any other app; ships its own Helm chart depending on the shared workload chart. dev + qa run on nonprod; a compensation-prod namespace exists but production is currently shut down (0 pods).

wordpath ↗WIP migration

What: The WordPath application.
Why: Registered as a platform tenant; being migrated onto GKE.
Usage: dev + qa run on the nonprod cluster (with per-PR previews), but the production migration onto GKE is not complete — prod is still served outside GKE for now. Work in progress.

wordpath-home ↗WIP migration

What: The WordPath marketing / home page.
Why: Registered as a platform tenant alongside wordpath.
Usage: Nonprod tiers run on the platform; full production migration is a work in progress (same as wordpath).