Region Registry

The region is the binding point between business logic and a specific cloud. Each region carries its own adapter set.

Region struct · internal/region/registry.go

type Region struct {
    ID          string  // "nyc3", "me-south-1"
    DisplayName string  // "New York", "Bahrain"
    Cloud       string  // "digitalocean", "aws", "gcp"
    Cluster     ClusterProvider
    Database    DatabaseProvider
    Cache       CacheProvider
    Registry    RegistryProvider
    Storage     StorageProvider
}

Multi-cloud regions: Today you have nyc3 on DigitalOcean. Tomorrow you add me-south-1 on AWS for MENA. Core logic says "deploy to region X" — it never says "call the DigitalOcean API."

BYOC (Enterprise) — not offered

Starform does not currently offer bring-your-own-cloud. The text below describes a latent capability the ports/adapters architecture would permit, retained for design context only — it is not a roadmap commitment and no part of MVP, launch, or seed scope depends on it. If ever offered: a customer provides their AWS/GCP credentials, Starbase registers a new region with the customer's cloud adapters, Shuttle deploys to their cluster, databases provision in their account, images store in their registry — core logic unchanged. (Note: this is distinct from Starform-operated multi-cloud regions above, which are on the roadmap for geographic expansion and run in Starform's own accounts.)

---

Cross-references

The port interfaces each Region field holds → §10 · how a region is wired at startup → §10 wiring example · BYOC's full out-of-scope treatment + the portability proof → Foundations §37.