ADR-003: BYOC with GCP Only
Status: Accepted | Date: 2026-02-10
Context
Fascia follows a Bring Your Own Cloud (BYOC) model where all runtime infrastructure and customer data live in the customer's own cloud project. The architectural question is which cloud provider(s) to support.
Supporting multiple cloud providers means maintaining separate Terraform templates, handling different service abstractions (e.g., AWS Lambda vs Cloud Run vs Azure Functions), and testing deployment pipelines across all targets. This multiplies engineering effort at a stage where speed of iteration is critical.
Decision
The MVP and initial release support GCP only. The runtime stack deploys to the customer's GCP project using:
- Cloud Run -- Executor hosting (containerized Go binary)
- Cloud SQL -- PostgreSQL database (one instance per workspace)
- Cloud Scheduler -- Cron trigger execution
- Secret Manager -- API keys, OAuth secrets, JWT signing keys
Multi-cloud support (AWS, Azure) is explicitly excluded from the near-term roadmap but the infrastructure layer is designed with a provider abstraction to make future expansion feasible.
Alternatives Considered
| Option | Pros | Cons |
|---|---|---|
| GCP only (chosen) | Tight integration, single Terraform template, consistent developer experience | Limits addressable market to GCP customers |
| Multi-cloud (AWS + GCP + Azure) | Larger market, customer choice | 3x deployment complexity, different service abstractions, slower iteration |
| AWS only | Largest cloud market share | GCP offers better managed services for this use case (Cloud Run cold start, Cloud SQL simplicity) |
| Cloud-agnostic (Kubernetes) | Runs anywhere | Enormous operational complexity for non-technical users |
Consequences
Positive
- Single deployment target -- One Terraform template to maintain, test, and iterate on.
- Excellent cold start -- Cloud Run provides sub-100ms cold starts with the Go Executor, directly benefiting end-user experience.
- Fully managed database -- Cloud SQL handles backups, failover, and maintenance automatically.
- Deep GCP integration -- Native IAM for access control, Secret Manager for credentials, Cloud Scheduler for cron -- all within the customer's project boundary.
- Consistent cost model -- All customers use the same infrastructure primitives, making pricing predictable.
Negative
- Market limitation -- Customers on AWS or Azure cannot use Fascia until multi-cloud support is added.
- Perceived vendor lock-in -- Although customers own their GCP project and all data within it, the requirement to use GCP may deter some prospects.
Risks
- If GCP pricing changes significantly, all customers are affected simultaneously. Monitoring GCP pricing announcements is essential.
- The infrastructure abstraction layer must be designed early (even if only GCP is implemented) to avoid a costly rewrite when multi-cloud support is added.