Sharang Parnerkar
8971152da0
Restructures the draft to reflect the 2026-06-30 cluster decision:
Three Orca clusters, each becoming its own Gitea repo at migration time:
- breakpilot-edge → vm-edge (Identity + Infra: KC, Gitea, Infisical, PowerDNS, Orca-Proxy)
- breakpilot-control → vm-control (Portal, tenant-registry, ERPNext, MariaDB, Stalwart)
- breakpilot-app → vm-app-prod + vm-app-stage (CERTifAI, compliance-*, Mongo, MinIO, Qdrant, LiteLLM)
Key model points encoded:
- Identity (Keycloak) co-tenant with Infra on vm-edge (1 VM core), per
INFRASTRUCTURE.md §6 — heap pinned so it cannot starve PowerDNS/Infisical
- Stage and prod live in the same breakpilot-app cluster on different
VMs. Stage authenticates via prod Keycloak under tenant.kind = "stage";
no duplicated identity, no duplicated control plane (per §5).
- The existing CERTifAI Keycloak will be repurposed for breakpilot-edge
rather than standing up a fresh one — same realm, same users.
- Multi-VM rollout gated on legal entity being established so we can sign
SysEleven / Hetzner business contracts. Until then, single-VM ops
continues via ~/workspace/orca-infra; this repo is design-only.
Mechanical changes:
- manifests/{vm-edge,vm-control,vm-data,stage}/ → clusters/{breakpilot-edge,breakpilot-control,breakpilot-app/services/{prod,stage}}/services/
- vm-data → vm-app-prod, stage → vm-app-stage in node references and headers
- overlays/{stage,prod}/overlay.toml point at the new cluster paths
- scripts/validate.sh now enforces a per-cluster node whitelist
(breakpilot-edge → vm-edge, breakpilot-control → vm-control,
breakpilot-app → {vm-app-prod, vm-app-stage}) instead of dir-name equality
- New READMEs at clusters/, clusters/breakpilot-edge/,
clusters/breakpilot-control/, clusters/breakpilot-app/ documenting
scope, SLA targets, co-tenant notes, and the future-repo split
- Top README rewritten to lead with the cluster-split decision and the
legal-entity gate; per-milestone fill-in table re-pathed
Validation:
- make validate → 38 files OK (35 manifests + 3 overlays)
- make plan ENV=stage → 11 resolved manifests in .orca-out/stage/
- make plan ENV=prod → 24 resolved manifests in .orca-out/prod/
84 lines
3.3 KiB
Markdown
84 lines
3.3 KiB
Markdown
# 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/`](./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/`](./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.
|