Deploying on Cloud
Run Orbtrace on a managed Kubernetes cluster — EKS, AKS, or GKE — using the Helm path plus the cloud's managed Postgres, cache, storage, and load balancer.
Deploying on a managed cloud cluster is the Kubernetes (Helm) path, with a few provider-specific choices: which managed Postgres to use, which storage class backs the volumes, and how traffic reaches the cluster. The recommendation is the same everywhere — run the stateful databases as managed services (or on VMs), and let Helm deploy only the stateless app.
In the managed cluster — Helm deploys
Cloud-managed / VMs — you run these
On every cloud the shape is identical: apps send OTLP to your Collector, which writes to Doris; the stateless Orbtrace app reads telemetry back and keeps settings + cache in managed Postgres + the bundled Valkey. Only the app and the ephemeral cache live in the cluster — the data you can't lose (managed Postgres, Doris) stays outside the pod lifecycle. The [Why keep the databases outside the cluster?](/docs/deploy-kubernetes#why-keep-the-databases-outside-the-cluster) reasoning applies on every provider.
Every managed cloud Postgres listed below supports the pgvector extension, which is all Orbtrace needs for its RCA vector store — so managed Postgres is the easy, recommended choice on all three clouds.
| AWS | Azure | GCP | |
|---|---|---|---|
| Managed Kubernetes | EKS | AKS | GKE |
| Managed Postgres + pgvector | RDS for PostgreSQL 18 | Azure Database for PostgreSQL (Flexible Server) | Cloud SQL for PostgreSQL |
| Cache (optional — Valkey stays bundled) | ElastiCache (Valkey/Redis) | Azure Cache for Redis | Memorystore (Redis) |
| Tunable-IOPS StorageClass | gp3 (raise iops/throughput) | Premium SSD v2 | Hyperdisk Balanced |
| Ingress / TLS | AWS Load Balancer Controller (ALB) + ACM | Application Gateway (AGIC) or ingress-nginx | GKE Ingress (GCLB) + managed cert |
| Doris | doris-operator in-cluster, or on EC2 VMs | doris-operator in-cluster, or on Azure VMs | doris-operator in-cluster, or on GCE VMs |
Pick your provider — in practice the choice follows where you already are (existing cloud account, DBAs, and TLS/secrets tooling), not a feature gap; Orbtrace runs the same on all three:
- Deploying on AWS (EKS) — RDS + ACM + the AWS Load Balancer Controller.
- Deploying on Azure (AKS) — Flexible Server + Key Vault + Application Gateway (AGIC).
- Deploying on GCP (GKE) — Cloud SQL + a ManagedCertificate, and zero-config LB health checks from the readiness probe.
Three things that are the same on every cloud
The per-provider pages differ only in service names and annotation syntax. The decisions behind them are identical everywhere:
- Doris is yours to run. No managed cloud offers Apache Doris as a service. Run it with the doris-operator in the cluster, or on provider VMs (EC2 / Azure VMs / GCE), and point
doris.hostat it — see Setting up Doris. The node kernel setting (vm.max_map_count ≥ 2000000) applies to whichever nodes the Doris BE lands on. - Tune the disk — the default class is too slow for Doris BE. Every provider's default SSD class ties IOPS to disk size or caps it low; BE compaction is IOPS-bound. Each page uses the provider's independently-tunable disk (gp3 with raised IOPS, Premium SSD v2, Hyperdisk Balanced) — this is the single most common cause of a sluggish cluster.
- Block volumes are zone-locked. An EBS volume / Azure disk / zonal PD lives in one zone, so a Doris BE pod can only run where its data is. Keep each BE in one zone (or one BE pool per zone with anti-affinity); the stateless app spreads freely. Each page shows how.
Size before you provision
Run the Capacity planning calculator first — it returns the Doris FE/BE counts, per-node vCPU/memory, and disk, which the node-group / node-pool shapes on each provider page follow directly.