orca-platform/clusters/breakpilot-edge

breakpilot-edge

Identity + Infra plane. Single VM (vm-edge).

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

Services (8)

Service	Purpose
gitea.toml	Source forge — every config change to every cluster lands here
infisical.toml	Secret store. Every other plane's ${secrets.*} resolves here
keycloak.toml	Single tenant of truth for identity. Repurposed from certifai Keycloak — same realm, same users.
orca-proxy.toml	Ingress for vm-edge: TLS termination + Let's Encrypt ACME for *.breakpilot.com
pg-infisical.toml	Infisical's Postgres
pg-keycloak.toml	Keycloak's Postgres
powerdns-auth.toml	Authoritative DNS for breakpilot.com; bound to port 53 on vm-edge
redis-infisical.toml	Cache + session store for Infisical

SLA targets (per INFRASTRUCTURE.md §6)

Owns:    AVAILABILITY ≥ 99.5% (root dep for every other plane)
         RTO ≤ 15 min (Keycloak)
         AUDIT_TRAIL — realm-level audit (logins, token issuance, IdP events)
         DATA_RESIDENCY — Keycloak realm data must stay EU
         STAGE_ISOLATION — rate-limits stage_client_id; rejects stage JWTs in prod audiences

Co-tenant note

Keycloak's JVM heap is pinned to 1.5 GB in keycloak.toml (JAVA_OPTS_APPEND = "-Xms1g -Xmx1500m") so it cannot starve PowerDNS or Infisical. If the heap fight ever shows up in alerts, the escape hatch is to peel Keycloak off onto its own VM inside the same cluster — no schema migration, just a placement.node flip.

Bootstrap exception

Per INFRASTRUCTURE.md §8 rule 3, KC_DB_URL lives in Orca env (not in Infisical), because Infisical runs on the same VM and we'd otherwise have a circular bootstrap dependency.