Skip to content

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.

  • 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
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)
  • Hub data plane — every output, decision, governance_event, artifact, employee_profile, telemetry_event payload
  • 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
  • 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)

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)
  1. Provision a dedicated cloud account / subscription / project
  2. Apply the Claresia Terraform module in your cloud (Claresia provides a read-only var-file with the per-tenant config)
  3. Module outputs:
    • mTLS endpoint URL (customer cloud → Claresia Cloud ingest)
    • Customer-issued mTLS cert
    • Hub URL (hub.{tenant_slug}.claresia.com resolves to a Private Link / Private Endpoint inside customer cloud)
  4. Customer pastes endpoint URL + cert into Claresia Onboarding Portal
  5. Claresia control plane registers the customer endpoint; runs schema migrations via the customer-provided endpoint
  6. Customer-side WorkOS Connect federates to your IdP (so even auth tokens stay in your boundary)

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)

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)
TierTarget
Control plane uptime99.9%
Sev 1 response15 min
Data plane uptimeCustomer-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.

  • 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)
  • 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_only role).

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).