Architecture
The platform is best read in three bands, from the cloud account inwards.
The three bands
Cloud managed services. DNS, load balancers, workload identity, object
storage, key management — Route 53 / Cloud DNS, ELB / Cloud Load Balancing,
Pod Identity / Workload Identity, S3 / Cloud Storage, KMS / Cloud KMS. The
platform provisions these through Crossplane rather than clicking them into
existence, but it deliberately leans on managed services for the things a
cloud does well. Nothing here is exotic, and that was the point: the set was
chosen so a second cloud could offer equivalents — which it since has. One
asymmetry is deliberate: public DNS is Route 53 for both clouds
(ADR-0019),
while Cloud DNS serves only gcp-0’s private zone. The full mapping is on
Cloud support.
The cluster. EKS on AWS, GKE Standard on GCP, both with Cilium as the CNI and kube-proxy replacement, on nodes provisioned on demand by Karpenter (AWS) or Node Auto-Provisioning (GCP). Above the datapath sit four tiers: GitOps and composition (Flux, Crossplane), compute and networking (Cilium, Gateway API, ExternalDNS, Karpenter, KEDA), security and identity (External Secrets, cert-manager, Kyverno, ZITADEL), and observability (VictoriaMetrics, VictoriaLogs, VictoriaTraces, Grafana).
Applications and data. The workloads a developer actually ships, plus the PostgreSQL, Valkey and object storage (S3 or GCS) the compositions provision for them. The self-hosted LLM platform lives here too, and is off by default.
Why it is shaped this way
Three decisions do most of the work, and each has its own page:
- Everything is reconciled, not deployed. No human and no CI job runs
kubectl applyagainst this cluster. See the GitOps model. - Infrastructure is requested through the Kubernetes API. A developer asks for a database with a claim, not a ticket. See progressive complexity.
- Access is denied by default and granted explicitly, at the network, the identity and the secret. See zero trust.
Where the boundary between clouds falls
The platform runs on AWS and GCP. The line between them is drawn deliberately, and it is not where people usually put it:
platform-facing APIs stay cloud-shaped and honest, while developer-facing
APIs stay cloud-neutral. An App claim should mean the same thing on any
cloud; an IAM policy document should not pretend to.
That rule is set out in ADR-0007, and it is why the documentation splits where it does: infrastructure bootstrap branches per provider, everything from the CNI upward does not.
Reading on
The mechanisms behind each band are documented under Platform — one section per domain, each describing what actually runs rather than what was planned.