Skip to content

BYOC (Enterprise) — Portability Proof

Not offered (§37)

Bring-your-own-cloud is not a current Starform offering. This entire page is retained as a portability proof — evidence that the ports/adapters design is cloud-agnostic — and as design context should BYOC ever be reconsidered. Nothing in MVP, launch, or seed scope depends on it. The same adapter mechanism is used for Starform-operated multi-cloud regions (geographic expansion, §12), which run in Starform's own cloud accounts — that is distinct from BYOC.

The architecture would permit bring-your-own-cloud with zero core logic changes:

What stays the same across all clouds:

  • Shuttle (cloud-agnostic — only talks K8s API)
  • Envoy Gateway (Kubernetes-native, any cluster)
  • Fluent Bit and vmagent (Kubernetes-native); the Vector aggregator (runs on any VM)
  • Gateway API HTTPRoutes (standard K8s CRDs)
  • All Starbase core business logic
  • Desired state model
  • Billing flow

What changes per cloud (new adapters only):

Port DO AWS GCP
ClusterProvider DOKS EKS GKE
DatabaseProvider DO Managed PG RDS Cloud SQL
RegistryProvider DO Container Registry ECR Artifact Registry
StorageProvider Tigris (Partner API) S3 or Tigris GCS or Tigris
CacheProvider DO Valkey ElastiCache Memorystore

Tigris note: Tigris is cloud-agnostic (globally distributed, not tied to any hyperscaler). The StorageProvider port could swap to a cloud-native store; absent a preference, Tigris is retained for egress-cost consistency. (Applies to Starform-operated multi-cloud regions; not a BYOC commitment.)

Adapter flow (illustrative, were a non-DO region added): Starbase registers a new region with that cloud's adapters → provisions cluster → Shuttle deploys → databases/storage provision → Starbase manages everything through the same ports. For Starform-operated regions this happens in Starform's accounts; the customer-credential variant (BYOC) is out of scope.


Cross-references

Ports & adapters (one adapter active per region) and the region registry → §12 / Starbase › Ports · the cloud-agnostic agent → Shuttle · desired-state model → §32 · billing flow → Billing. Canonical map: Canonical Sources.