Cloud Ops overview

Owner: Cloud Ops
You’ll finish with: the Arbium backend running in your cloud account, plus one HTTPS endpoint and a key to hand to IT.

You deploy the Arbium backend into your own cloud account. The application layer is identical on every supported cloud; only the managed Kubernetes, PostgreSQL, secret store, ingress, and workload-identity wiring differ.

Naming note: the Helm chart and its Kubernetes resources are named
chaindb for historical reasons. Wherever you see chaindb in a command or
resource name, read it as the Arbium backend.

Installation flow

The flow forks only for Step 2, then converges:

                         ┌─ AWS: EKS + Aurora + Secrets Manager + ALB ─┐
Common prerequisites ────┼─ GCP: GKE + Cloud SQL + Secret Manager + LB ┼── Shared Helm ── Verify ── IT handoff
                         └─ Azure: AKS + PostgreSQL + Key Vault + nginx ┘

Supported cloud foundations

	AWS	Google Cloud	Azure
Kubernetes	Amazon EKS	Google Kubernetes Engine	Azure Kubernetes Service
PostgreSQL	Aurora PostgreSQL	Cloud SQL for PostgreSQL	PostgreSQL Flexible Server
Secret store	AWS Secrets Manager	Google Secret Manager	Azure Key Vault
Workload identity	IRSA	GKE Workload Identity	AKS Workload Identity
Ingress and TLS	AWS Load Balancer Controller + ACM	GCE Ingress + Google-managed certificate	ingress-nginx + cert-manager
Default embedding compute	CPU, optional GPU pool	CPU, optional GPU pool	CPU, optional GPU pool
Helm preset	`values-aws.yaml`	`values-gcp.yaml`	`values-azure.yaml`

Do not mix providers: the preset and provider values file must match the foundation Terraform created. The application values file is portable.

Parallel IT work

IT can start their Entra app registration while you provision the foundation. You need three of their values before the Helm step: the tenant ID, the agent client ID and — if the fleet console is enabled — the admin application values and SCIM group IDs.

Start with 1. Prerequisites & access.