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.
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 keysvm-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.nodepins which VM each container lands on; prod manifests live inprod/, stage instage/. - 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-controldrops recipients not matching*+stage@*) - trigger real Polar charges (
POLAR_API_URLpoints 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.