Skip to content

Architecture

The platform is best read in three bands, from the cloud account inwards.

Platform architecture: AWS and GCP managed services on the left, the aws-0 (EKS, Karpenter) and gcp-0 (GKE, Node Auto-Provisioning) clusters in four tiers in the centre, and applications and data stores on the right

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 apply against 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.