Files
orca-platform/clusters/breakpilot-app
sharang 6be727d404
ci / shared (push) Successful in 9s
ci / validate (push) Successful in 4s
refactor(iac): cluster split — 1 cluster per plane, breakpilot-* naming (#6)
3 Orca clusters (breakpilot-edge / breakpilot-control / breakpilot-app), 1 plane each. Single-VM core with Keycloak co-tenant on vm-edge. App cluster gets prod + stage VMs. Manifests reorganized into clusters/<name>/services/; validator now enforces per-cluster node whitelist. Multi-VM rollout gated on legal entity.
2026-06-30 20:30:14 +00:00
..

breakpilot-app

App plane (formerly "Data plane" in the May 18 doc). Two VMs in one cluster:

  • vm-app-prod — production workloads, customer data, real keys
  • vm-app-stage — staging workloads, demo data, sandbox tenant

Becomes its own Gitea repo platform/breakpilot-app at migration time.

Services

Prod (services/prod/, 9 services)

Service Purpose
admin-compliance.toml Compliance back-office admin
ai-compliance-sdk.toml LLM-mediated compliance SDK
backend-compliance.toml Compliance scanner backend
certifai-dashboard.toml CERTifAI dashboard (first product)
litellm.toml LLM gateway
minio.toml S3-compatible object store
mongodb.toml Compliance + CERTifAI data
pg-app.toml Per-tenant application Postgres (SPOF — RISK-1 in §7)
qdrant.toml Vector store (rebuildable)

Stage (services/stage/, 11 services)

Service Purpose
admin-compliance.toml Stage admin
ai-compliance-sdk.toml Stage SDK
backend-compliance.toml Stage backend
certifai-dashboard.toml Stage CERTifAI
customer-portal.toml Stage portal (calls prod KC + prod tenant-registry with tenant.kind = "stage")
litellm.toml Stage LLM gateway (may reuse prod)
mongodb-stage.toml Stage Mongo
orca-proxy.toml Per-node ingress on vm-app-stage
pg-app-stage.toml Stage Postgres
qdrant-stage.toml Stage vector store
tenant-registry.toml (placeholder; stage calls prod registry — manifest exists for parity)

SLA targets (per INFRASTRUCTURE.md §6)

Owns:    DATA_RESIDENCY — all customer data (MongoDB, pg-app, MinIO) must stay EU
         RPO (product)  — compliance records ≤ 6h; chat history ≤ 24h
         DATA_ISOLATION — every query scoped by org_id / tenant_id
         AUDIT_TRAIL    — product-level actions
         AVAILABILITY   — CERTifAI ≥ 99.5%; compliance ≥ 99.5%

Why one cluster, two VMs

  • Same orca-platform config, different physical workloads. Stage and prod don't drift on infra config because they're in the same cluster.
  • No "oops touched prod" accidents. Per-service placement.node pins which VM each container lands on; prod manifests live in prod/, stage in stage/.
  • Blast radius is physical. A stage misconfiguration cannot exhaust vm-app-prod's memory because they share nothing but the Orca control socket.

Stage isolation contract

Stage services never:

  • email real customers (Stalwart accept-rule on breakpilot-control drops recipients not matching *+stage@*)
  • trigger real Polar charges (POLAR_API_URL points at sandbox)
  • carry real customer data (sandbox tenant resets nightly)

Stage services always:

  • authenticate via prod Keycloak with tenant.kind = "stage"
  • read tenant config from prod tenant-registry (read-only for stage tenants)
  • expose *.stage.breakpilot.com (or whatever the staging subdomain is)

See INFRASTRUCTURE.md §5 for the full stage-prod sharing contract.

Sandbox tenant

The sandbox tenant in stage/ is the only place that accepts writes from public demo visitors. A nightly cron (lands as sandbox-reset.toml when seed-data fixtures are wired in M13.1) resets its Mongo collections and Keycloak user attributes from a versioned seed.