5862fcec3b
* feat(catalyst-ui): SMALL_TYPE_THRESHOLD + auto-100% density for small types Item 1 of #348. Small types (total < 20) bypass the global density slider's per-type cap calculation and always render at 100% as long as the chip is active. Threshold is exported from widgets/architecture-graph/types.ts so adapter, page, GraphCanvas, and the test suite all key off the same constant. The per-type popover is already short-circuited for small types (chip click toggles visibility without opening the slider) — semantics confirmed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(catalyst-ui): chip add/remove + full relation cache regardless of active chips Item 2 of #348. The adapter now emits every node type — including PVC, Bucket, Volume (storage block) and reserved Service / Ingress slots — plus every relation type from the spec (contains, member-of, runs-on, routes-to, attached-to, depends-on, used-by, peers-with, flows-to, realizes, triggers, associates). The page-level orchestrator holds an `activeTypes` Set; chips have an explicit "×" remove button and the strip ends with a "+" Popover that lists inactive types with their counts. Removing a chip filters its nodes out of the canvas; re-adding restores them. The data layer is the single source of truth — chip add/remove never re-queries. Verified the founder's example: removing every chip except NodePool + PVC isolates the canvas to those types and the edges between them. Per ADR-0001 §B4 — "full relation cache" aligns with the #321 informer cache foundation; today's adapter is the placeholder until that lands. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(catalyst-ui): relation types in detail panel grouped by relation Item 3 of #348. The right-side detail panel's neighbor list now carries the relation type per neighbor. Neighbors are grouped under sticky per-relation subheaders ordered by ALL_EDGE_TYPES so the panel reads consistently between renders. Each row exposes a stable testid: arch-detail-panel-neighbor-{relation}-{nodeId} (plus a hidden legacy infrastructure-detail-panel-neighbor-{nodeId} for backwards-compat with #309 tests). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(catalyst-ui): ArchiMate edge marker styles + updated legend Item 4 of #348. Each relation type maps to an ArchiMate-derived end decoration: composition (filled diamond at parent end) for `contains`, aggregation (hollow diamond) for `member-of`, assignment (filled dots at both ends) for `runs-on`, triggering (filled triangle) for `routes-to` / `triggers` / `flows-to`, used-by (open triangle) for `depends-on` / `used-by`, realization (hollow triangle) for `realizes`, and association (plain line) for `peers-with` / `associates`. Implementation: SVG `<defs><marker>` patterns rendered into the canvas once per (kind, stroke) pair (`uniqueMarkerDefs`); the marker palette is stable across animation frames so React doesn't re-allocate every tick. Per-edge `markerStart` / `markerEnd` URL refs in the line elements drive the rendering. The legend at the bottom now shows the ArchiMate symbol thumbnail + name + count, with self-contained marker defs scoped to each thumbnail SVG (`-legend` id suffix). `markers.ts` is a separate module so GraphCanvas.tsx satisfies react-refresh/only-export-components. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(catalyst-ui): bounded physics — nodes constrained to canvas Item 5 of #348. A custom d3-force `forceBound(width, height, padding=20)` clamps each node's x/y inside the canvas every tick. The clamp also handles fx/fy when set via drag-pin so a manual drag past the edge instantly snaps inside. Adaptive physics tiers retuned: charge magnitudes lowered slightly so strong repulsion doesn't fight the bound at small canvas sizes (the ≤50-node tier drops from -240 → -160; the ≤200 tier from -180 → -120, etc.). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(catalyst-ui): per-type tabler icons replace plain circles Item 10 of #348. Each architecture-graph node renders with a @tabler/icons-react glyph at its centre plus a type-color stroke ring, replacing the prior plain disc. Locked mapping: Cloud→IconCloud, Region→IconMapPin, Cluster→IconBox, vCluster→IconStack3, NodePool→IconStack2, WorkerNode→IconCpu, LoadBalancer→IconArrowsSplit, Network→IconNetwork, PVC→IconDatabase, Bucket→IconBucketDroplet, Volume→IconDisc, Service→IconWorld, Ingress→IconRouteAltLeft. Icons sized 14-18px scaled to node radius; minimum disc radius NODE_R=14 so the icon always reads against the canvas. The detail panel's neighbor list also picks up the per-type icons. `icons.ts` is a separate module so GraphCanvas.tsx remains a component-only file (react-refresh/only-export-components). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(catalyst-ui): Playwright cases + screenshots for 348 polish Item 7 of #348. Extends e2e/cloud-architecture.spec.ts with eight new cases targeting #348 P1: - type chips carry "×" + the strip ends with "+" - removing every chip except NodePool + PVC isolates only those nodes - "+" Popover re-adds a removed type - detail panel groups neighbors by relation with sticky subheaders - edge legend renders ArchiMate symbol thumbnails for every relation - per-type tabler icons render (`arch-graph-node-icon-{type}` testids) - bounded physics — drag node toward (-100,-100) clamps inside canvas - global density slider does not affect small types (auto-100%) Plus a screenshot suite at 1440x900 capturing default / NodePool+PVC isolated / single-type focus / ArchiMate legend close-up. All graph-node interactions use `force: true` per the established continuous-simulation flake-fix pattern. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: hatiyildiz <hati@openova.io> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .claude | ||
| .github | ||
| .playwright-mcp | ||
| clusters | ||
| core | ||
| docs | ||
| infra/hetzner | ||
| platform | ||
| products | ||
| scripts | ||
| tests | ||
| .gitignore | ||
| CLAUDE.md | ||
| README.md | ||
OpenOva Catalyst
A self-sufficient Kubernetes-native platform. Published as signed OCI Blueprints. Deployable as your own Sovereign.
Catalyst is the open-source platform built by OpenOva. It turns any Kubernetes cluster into a Sovereign: a self-contained control plane that hosts Organizations, Environments, and Applications via GitOps + Crossplane, with a unified UI/Git/API for users.
Documentation
| Document | What it covers |
|---|---|
docs/GLOSSARY.md |
Canonical terminology — read first |
docs/ARCHITECTURE.md |
Catalyst architecture overview |
docs/IMPLEMENTATION-STATUS.md |
What's built today vs what's design-only — read second |
docs/NAMING-CONVENTION.md |
Naming patterns for every resource type |
docs/PERSONAS-AND-JOURNEYS.md |
Personas × journeys matrix; surfaces |
docs/SECURITY.md |
Identity (SPIFFE + Keycloak), secrets (OpenBao + ESO), rotation, multi-region semantics |
docs/SOVEREIGN-PROVISIONING.md |
How to bring a Sovereign online |
docs/BLUEPRINT-AUTHORING.md |
Writing Blueprints (incl. Crossplane Compositions) |
docs/PLATFORM-TECH-STACK.md |
Every component's role in Catalyst |
docs/SRE.md |
Operating a Sovereign |
docs/BUSINESS-STRATEGY.md |
Product strategy and GTM |
docs/TECHNOLOGY-FORECAST-2027-2030.md |
Component forecast 2027–2030 |
docs/VALIDATION-LOG.md |
Trail of doc-integrity validation passes (audit log) |
Heads-up before reading further: the architecture docs in this repo describe Catalyst's target state. Significant portions are not yet implemented — see
docs/IMPLEMENTATION-STATUS.mdfor what exists today vs what is design.
The model in 60 seconds
OpenOva (the company) publishes Catalyst (the platform).
A deployed Catalyst is called a Sovereign.
A Sovereign has:
- Organizations (multi-tenancy unit)
- Environments (org-scoped, env-typed: prod/stg/uat/dev/poc)
- Applications (installed Blueprints)
- Blueprints (the App Store catalog — public + Org-private)
Users install Applications from Blueprints into Environments.
Blueprints can depend on Blueprints (arbitrary depth).
Each Environment is one Gitea repo + one or more vclusters.
Every state change is a Git commit.
Every UI surface reads from a single CQRS projection.
Same code runs in every Sovereign:
- openova (run by us; SaaS Organizations)
- omantel (run by Omantel; SME Organizations across Oman)
- bankdhofar (run by the bank; internal Organizations)
- your-company (run by you, on infrastructure you choose)
See docs/GLOSSARY.md for every term, docs/ARCHITECTURE.md for the full picture.
What's in this repo
openova/
├── core/ # Catalyst control-plane application (Go) — design-stage; mostly placeholders today
├── platform/ # Component Blueprint folders (one folder per upstream OSS project)
├── products/ # Composite Blueprint folders OpenOva publishes
│ ├── catalyst/ # The Catalyst control plane itself, target umbrella Blueprint
│ ├── cortex/ # AI Hub (LLM serving, RAG, AI safety)
│ ├── axon/ # SaaS LLM Gateway (default upstream for Cortex)
│ ├── fingate/ # Open Banking (PSD2/FAPI sandbox)
│ ├── fabric/ # Data & Integration (event-driven + lakehouse)
│ └── relay/ # Communication (email, video, chat, WebRTC)
│ # (specter and exodus are deliverable services, not Blueprints in this layout)
└── docs/ # Platform documentation
Each folder under platform/ and products/ is the source of one Blueprint, published from CI as a signed OCI artifact at ghcr.io/openova-io/bp-<name>:<semver> (the bp- prefix is added to the OCI artifact name; folder names stay short). Per-folder isolation is provided at the OCI artifact layer, not the Git repo layer — this is a monorepo with per-Blueprint fan-out, not a meta-repo of separate Git repositories. See docs/BLUEPRINT-AUTHORING.md §2 for the folder layout contract.
Today, the 12-component bootstrap kit (cilium, cert-manager, flux, crossplane, sealed-secrets, spire, nats-jetstream, openbao, keycloak, gitea, powerdns + the bp-catalyst-platform umbrella under
products/catalyst/) ships with fullchart/+blueprint.yamlperdocs/IMPLEMENTATION-STATUS.md§7, plusproducts/axon/and theexternal-dnsleaf chart. The remaining 45 platform components and thecortex / fabric / fingate / relayproduct folders are design-stage — README only — until each lands its Blueprint manifest, chart, Compositions, and CI fan-out.
Stack at a glance
| Layer | Technology |
|---|---|
| Container runtime | k3s (k8s-conformant), containerd |
| CNI / Service Mesh | Cilium (eBPF mTLS, L7 policies, Gateway API) |
| GitOps | Flux (per-vcluster, lightweight) |
| Git | Gitea (per-Sovereign, hosts Blueprint mirror + per-Environment repos) |
| IaC for non-K8s | Crossplane (the only IaC; not user-facing) |
| Bootstrap IaC | OpenTofu (one-shot, archived after Phase 0) |
| Multi-tenancy | vcluster (one per Organization per host cluster) |
| Identity (workloads) | SPIFFE/SPIRE (5-min rotating SVIDs, mTLS everywhere) |
| Identity (users) | Keycloak (per-Org for SME, per-Sovereign for corporate) |
| Secrets | OpenBao (Apache 2.0; independent Raft per region, no stretched cluster) + External Secrets Operator |
| Event spine | NATS JetStream (Apache 2.0; pub/sub + KV; per-Org accounts) |
| TLS | cert-manager + Let's Encrypt or corporate CA |
| Policy | Kyverno |
| Supply chain | cosign (Sigstore), Syft + Grype SBOM, Trivy scans |
| Runtime security | Falco (eBPF) |
| Observability | OpenTelemetry → Grafana stack (Alloy + Loki + Mimir + Tempo) |
| WAF | Coraza (OWASP CRS) |
| DNS | PowerDNS authoritative per Sovereign zone + DNSSEC + lua-records (ifurlup, pickclosest); pool-domain-manager allocates pool subdomains and flips parent-zone NS via registrar adapters (Cloudflare / Namecheap / GoDaddy / OVH / Dynadot) — see docs/MULTI-REGION-DNS.md, docs/PLATFORM-POWERDNS.md |
| Backup | Velero (to SeaweedFS, which routes the cold tier to cloud archival S3) |
| Container registry | Harbor |
For the full component list and trends see docs/PLATFORM-TECH-STACK.md and docs/TECHNOLOGY-FORECAST-2027-2030.md.
Cloud providers
| Provider | Status |
|---|---|
| Hetzner Cloud | Available (most-tested path) |
| AWS / GCP / Azure | Crossplane providers available; full path coming |
| Oracle Cloud (OCI) | Crossplane provider available; full path coming |
| Huawei Cloud | Crossplane provider available; full path coming |
All providers reach Catalyst via the same Crossplane abstraction; Sovereign provisioning details per provider are in docs/SOVEREIGN-PROVISIONING.md.
Getting started
Try it (managed)
Visit marketplace.openova.io to install Applications on the openova Sovereign without any infrastructure setup. SaaS journey for SMEs and evaluations.
Run your own Sovereign
1. Provision via catalyst-provisioner.openova.io (managed bootstrap), OR
2. Self-host bp-catalyst-provisioner in your own infrastructure (air-gap path).
Then follow the procedure in docs/SOVEREIGN-PROVISIONING.md.
Build a Blueprint
See docs/BLUEPRINT-AUTHORING.md. A Blueprint is a folder under platform/<name>/ (or products/<name>/) in this monorepo containing blueprint.yaml + manifests (Helm chart or Kustomize base) + (optional) Crossplane Compositions. CI signs each folder's contents and publishes to OCI as ghcr.io/openova-io/bp-<name>:<semver>. Catalyst's blueprint-controller picks it up automatically. Org-private Blueprints follow the same shape inside per-Sovereign Gitea repos.
License
All Blueprints and the Catalyst control plane are open source. Each component carries its own upstream license (typically Apache 2.0, MPL 2.0, or BSD-3); see each component's LICENSE file.
OpenOva charges for support, managed operations, and expert services — never for access to code. See docs/BUSINESS-STRATEGY.md §10.
Contributing
PRs welcome. The contribution path for Blueprints (including Crossplane Compositions) is documented in docs/BLUEPRINT-AUTHORING.md §13. Issues and discussions on GitHub.
Cloud-native is the foundation. Catalyst is how you operate it.