BYOC Deployment
BYOC (Bring Your Own Cloud) is Fascia's deployment model. All runtime infrastructure lives in the customer's own GCP project. Fascia never stores or processes customer business data -- it only generates and deploys execution artifacts.
What BYOC Means
In a traditional SaaS model, the vendor hosts everything: application servers, databases, and customer data all live on the vendor's infrastructure. Fascia takes a different approach.
Fascia splits responsibilities across two planes:
- Control Plane (Fascia-hosted): Handles spec design, validation, risk analysis, and deployment orchestration. Stores only specs, metadata, and deployment records.
- Data Plane (Customer GCP): Runs all execution logic and stores all business data. Owned and billed to the customer's GCP account.
This means customers retain full ownership and control over their data, infrastructure, and billing. Fascia acts as a design and deployment layer, not a data processing layer.
What Runs Where
Customer GCP Project
All runtime components are provisioned inside the customer's own GCP project:
| Resource | Service | Description |
|---|---|---|
| Executor | Cloud Run | The Go binary that executes Tool flow graphs. Receives SpecBundles compiled from the customer's specs. Scales to zero when idle, starts in approximately 50ms. |
| Database | Cloud SQL (PostgreSQL) | One PostgreSQL instance per workspace. Stores all business entities, relationships, and audit logs. Auto-provisioned with backups enabled. |
| Scheduler | Cloud Scheduler | Invokes cron-triggered Tools on their configured schedule. Each cron Tool gets a dedicated scheduler job. |
| Secrets | Secret Manager | Stores all sensitive values: JWT signing keys, OAuth client secrets, API keys, database credentials. Secrets are created and managed via Terraform during deployment. |
| Messaging | Pub/Sub (optional) | Enables queue-triggered Tools and asynchronous event-driven workflows between Tools. Provisioned only when queue triggers are used. |
Fascia-Hosted (Control Plane)
| Component | Description |
|---|---|
| Chat Studio | Conversational design interface. LLM-powered spec generation. |
| Flow Studio | Visual flow graph editor. |
| Spec Registry | Versioned storage for Entity, Tool, and Policy specs. |
| Safety Agent | AI-powered spec analysis and risk detection. |
| Risk Engine | Flow graph evaluation and risk classification. |
| Deploy Pipeline | Terraform orchestration for customer GCP provisioning. |
Data Sovereignty
Fascia enforces strict data isolation:
- Customer business data never leaves the customer's GCP project. All Entity records, relationships, status transitions, and audit logs are stored in the customer's Cloud SQL instance.
- Fascia stores only specs and metadata. The Spec Registry contains structured definitions (Entity specs, Tool specs, Policy specs) and deployment records. It does not contain any customer business data.
- Each workspace gets its own database. There is no shared database between workspaces. Each workspace has a dedicated Cloud SQL instance, providing full isolation.
- Secrets stay in the customer's project. JWT signing keys, OAuth client secrets, and API keys are stored in the customer's GCP Secret Manager. Fascia does not have access to these secrets after initial provisioning.
IAM and Access
Fascia requires minimal IAM access to the customer's GCP project, following the principle of least privilege:
| Permission | Purpose | When Used |
|---|---|---|
| Cloud Run Admin | Deploy and update the Executor service | During deployment only |
| Cloud SQL Admin | Provision database instances and run migrations | During initial setup and schema changes |
| Cloud Scheduler Admin | Create and update cron jobs | During deployment of cron-triggered Tools |
| Secret Manager Admin | Create secrets for initial provisioning | During initial setup only |
| Service Account Creator | Create runtime service accounts | During initial setup only |
After deployment, the Executor runs under a dedicated GCP service account with access limited to its own Cloud SQL instance and Secret Manager entries. Fascia's deployment service account can be revoked after provisioning if the customer manages infrastructure updates independently.
Deployment Flow
When a user deploys a Tool (or set of Tools) from the Control Plane, the following steps execute:
1. Spec Compile
└── Specs are compiled into a SpecBundle (self-contained execution artifact)
2. Terraform Plan
└── Infrastructure changes are computed (new Cloud Run revision, DB migrations, scheduler jobs)
3. Terraform Apply
└── Changes are applied to the customer's GCP project
4. Cloud Run Deploy
└── New SpecBundle is deployed as a Cloud Run revision
5. Health Check
└── Fascia verifies the new deployment is healthy (HTTP health endpoint)
6. Record
└── Deployment record is written to the Spec Registry (timestamp, version, status)
If any step fails, the deployment is rolled back to the previous known-good state. The Spec Registry records the failure for audit purposes.
One Database Per Workspace
Each workspace receives its own Cloud SQL PostgreSQL instance. This design provides:
- Full isolation -- No risk of data leakage between workspaces.
- Independent scaling -- Each database scales based on its own workload.
- Independent backups -- Backup schedules and retention are per-workspace.
- Clean teardown -- Deleting a workspace removes its entire database instance.
The database schema is automatically derived from the customer's Entity specs. When entities are created or modified, Fascia generates and applies the corresponding SQL migrations during deployment.
Cloud Provider Support
Fascia currently supports GCP only. This decision was made to reduce deployment complexity and maintain deep integration with GCP-managed services (Cloud Run, Cloud SQL, Cloud Scheduler, Secret Manager).
Multi-cloud support (AWS, Azure) is planned for future releases. The infrastructure layer is designed with an abstraction boundary to facilitate this expansion, but it is explicitly excluded from the current roadmap.
For the full rationale, see the Architecture Decision Record on BYOC with GCP.
Cost Model
Because all runtime infrastructure lives in the customer's GCP project, the customer pays GCP directly for their usage:
| Resource | Billing Model |
|---|---|
| Cloud Run | Per-request + CPU/memory time (scales to zero) |
| Cloud SQL | Hourly instance cost + storage |
| Cloud Scheduler | Per-job invocation |
| Secret Manager | Per-secret version + access operations |
| Pub/Sub | Per-message (if used) |
Fascia charges separately for Control Plane usage (spec storage, design tools, deployment orchestration). The customer's GCP costs are independent of Fascia's pricing.
See Also
- System Architecture -- Overall two-plane architecture and tech stack
- Risk Classification Rules -- How the Risk Engine evaluates Tool safety before deployment
- Tool Spec Schema -- Tool definitions including trigger types and flow graphs