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
Published to oci://europe-west1-docker.pkg.dev/u2i-bootstrap/helm-charts. App charts (and u2i-infra subcharts) list them as dependencies in Chart.yaml.
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
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 prod; PRs get preview environments. See the Example page.
retrotool-landing-page
What
The public marketing / landing site for RetroTool.
Why
Separates the marketing surface from the product application and its release cadence.
Usage
Deployed on the platform as its own tenant app, following the same CI/CD pattern.
compensation
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.
compliance-demo
What
A JavaScript demo application showcasing the compliance platform end to end.
Why
A reference / showcase used to validate and demonstrate the compliance controls in a running app.
Usage
Deployed on the platform; exercises the same registration, secrets, and rollout flow.