Files
orca-platform/clusters/breakpilot-control
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-control

Control plane. Single VM (vm-control).

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

Services (7)

Service Purpose
customer-portal.toml Next.js 15 customer-facing portal
erpnext.toml Internal-only ERP (sales, invoices, fulfillment)
frappe-hd.toml Helpdesk on the Frappe stack
mariadb.toml DB for ERPNext + Frappe HD
redis-erpnext.toml ERPNext cache + queue Redis
stalwart.toml Outbound mail relay; per-stage accept-rule blocks real customers from receiving stage mail
tenant-registry.toml Tenant glue: orgs, entitlements, API keys, audit. M7.3's TENANT_REGISTRY_URL resolves here.

SLA targets (per INFRASTRUCTURE.md §6)

Owns:    RPO (tenant)   — tenant registry & compliance schemas RPO ≤ 6h
         RPO (ERPNext)  — sales orders, invoices RPO ≤ 6h
         AUDIT_TRAIL    — all portal actions (invites, IdP changes, impersonations)
         AVAILABILITY   — portal ≥ 99.5%; ERPNext ≥ 99% (internal)
         RTO (portal)   — ≤ 10 min
         RTO (ERPNext)  — ≤ 60 min

Co-tenant note

ERPNext + Portal + Stalwart on one VM. Orca resource limits per §6:

Service Memory cap
customer-portal 1 GB
erpnext 6 GB
mariadb 3 GB
stalwart 1 GB
tenant-registry 500 MB

Stage callers

Stage workloads in breakpilot-app/services/stage/ call the prod tenant-registry here under tenant.kind = "stage" rather than running a duplicate. Isolation is by tenant kind, not by replicating the control plane.