Mode C — Customer Cloud (BYOC)
import { Aside } from “@astrojs/starlight/components”;
Mode C is for regulated industries (pharma, finance, defense, public sector) or any customer whose CISO requires that customer data never leaves customer cloud. The Hub data plane lives in the customer’s cloud account; only telemetry envelopes (no payloads) flow back to Claresia Cloud.
When to choose Mode C
Section titled “When to choose Mode C”- Regulated industry (pharma, finance, defense, public sector)
- Data sovereignty requirement (e.g., German BSI, French ANSSI, UK NCSC)
- Custom region (AWS (EU residency only; no US-Gov pursuit), (Italian + EU residency only), Saudi region, …)
- CISO mandate that no customer data may be in a third-party-managed database
- Customer wants direct OS-level access to the Hub database
Topology
Section titled “Topology” CUSTOMER CLOUD ┌──────────────────────────────────┐ ┌─────────────────────────────────┐ │ CLARESIA CONTROL PLANE │ │ Hub data plane │ │ (eu-south-1 + eu-central-1) │ │ (customer's Postgres / │ │ │ │ SharePoint / Snowflake, │ │ Identity (WorkOS) │ │ customer KMS) │ │ Admin Console (Command Center) │ │ │ │ Distribution Plane │ │ Telemetry redaction Lambda │ │ Billing │ │ (strips payloads, emits │ │ Skill IR repo │ │ envelope-only via mTLS) │ │ │ │ │ │ Telemetry envelopes ONLY │←──│ Customer's WorkOS Connect │ │ (no payloads) │ │ (federates to Azure AD) │ └──────────────────────────────────┘ └─────────────────────────────────┘ ↓ ↑ Distribution publishes skills │ to customer's LLM workspace ──────────→ Customer's LLM platform (Claude Enterprise EU / Copilot M365 EU / ChatGPT Enterprise)What stays in customer cloud
Section titled “What stays in customer cloud”- Hub data plane — every
output,decision,governance_event,artifact,employee_profile,telemetry_eventpayload - Customer KMS keys — never copied to Claresia
- Telemetry payloads — stripped by the customer-side Lambda before envelope emission
- All connector data — Salesforce, M365, ServiceNow, etc. data flowing into Claresia stays in customer cloud
What flows back to Claresia Cloud
Section titled “What flows back to Claresia Cloud”- Telemetry envelopes only:
{tenant_id, skill_id, ts, success, latency_ms, tokens_in, tokens_out, cost_usd_estimate, archetype_id}— no payload, no PII, no business content - Provenance hashes — SHA-256 over the canonical-JSON form of each Hub record (the hash itself, not the record)
Customer-side install
Section titled “Customer-side install”Mode C requires the customer to apply a Terraform module in their cloud. Three modules are published:
claresia/aws-byoc— AWS (RDS Aurora Postgres, Lambda for redaction, KMS, IAM roles, VPC + Private Link to Claresia Cloud)claresia/azure-byoc— Azure (Azure Database for PostgreSQL, Function App, Key Vault, Managed Identity, VNet + Private Endpoint to Claresia Cloud)claresia/gcp-byoc— GCP (Cloud SQL Postgres, Cloud Function, Cloud KMS, Service Account, VPC + Private Service Connect to Claresia Cloud)
High-level customer steps
Section titled “High-level customer steps”- Provision a dedicated cloud account / subscription / project
- Apply the Claresia Terraform module in your cloud (Claresia provides a read-only var-file with the per-tenant config)
- Module outputs:
- mTLS endpoint URL (customer cloud → Claresia Cloud ingest)
- Customer-issued mTLS cert
- Hub URL (
hub.{tenant_slug}.claresia.comresolves to a Private Link / Private Endpoint inside customer cloud)
- Customer pastes endpoint URL + cert into Claresia Onboarding Portal
- Claresia control plane registers the customer endpoint; runs schema migrations via the customer-provided endpoint
- Customer-side WorkOS Connect federates to your IdP (so even auth tokens stay in your boundary)
Time-to-go-live
Section titled “Time-to-go-live”2–6 weeks. The variance is dominated by:
- Customer’s procurement (security review, change management, contract redlines)
- Customer’s network team (VPC peering, Private Link approval, DNS records)
- Customer’s CISO sign-off (often requires reading the SOC 2 Type 2 report
- the pen test executive summary + the architecture whitepaper)
Pricing
Section titled “Pricing”Standard cc-033 v2 pricing plus:
- +$50k/year BYOC fee (covers Claresia engineering on the Terraform modules + the mTLS infrastructure + the per-tenant Customer Lockbox)
- The customer pays their own AWS / Azure / GCP bill for the data plane (typical: $1–5k/month depending on Hub volume + telemetry retention)
| Tier | Target |
|---|---|
| Control plane uptime | 99.9% |
| Sev 1 response | 15 min |
| Data plane uptime | Customer-owned SLA |
The data plane SLA is the customer’s responsibility (it’s their cloud, their Postgres, their backup policy). Claresia provides best-practice runbooks + backup automation in the Terraform module.
What you trade off
Section titled “What you trade off”- Slower onboarding (2–6 wk vs <24h Mode A / 5d Mode B)
- Customer cloud bill (typical $1–5k/mo)
- Customer ops responsibility for the data plane (backups, scaling, patching follow your normal cloud-ops cadence — Terraform module ships defaults)
- Loss of payload-level telemetry in Command Center (envelope-only — you can see WHO ran WHAT skill WHEN, not the prompt/completion content)
What you gain
Section titled “What you gain”- Data sovereignty. Provable to your auditor.
- CISO sign-off. Mode C answers the “where does the data live?” question unambiguously.
- Custom region. (EU residency only; no US-Gov pursuit), Azure Gov, Saudi, etc.
- Direct database access. Your DBAs can query the Hub Postgres directly
with read-only credentials (we ship a
claresia_read_onlyrole).
Reference architectures
Section titled “Reference architectures”For each cloud, the Terraform module ships with:
- A base module (single region, single AZ)
- An HA module (multi-AZ)
- A multi-region module (active-active across two regions)
See the per-cloud Terraform reference under the architecture whitepaper (deep-dive docs to be added once the modules are GA).