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.
1.8 KiB
1.8 KiB
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.