Katastroma
Source event-driven platform for Kubernetes. Multi-tenant support and tenant isolation through Kubernetes-native RBAC, impersonation, and admission control.
Architecture
GitOps has 5 operations:
- Listen - wait for events
- Multiple source handlers running in the system - each for different source types (GitHub, OCI, S3, etc.)
- Retrieve — given source event, retrieve the source content
- Render — given source content, produce Kubernetes manifests
- Order — given unordered manifests, sort them into a safe apply order
- Provision — given ordered manifests, apply them to the cluster
Components
Interface repos define client-facing gRPC APIs. Clients depend on the interface without importing the implementation. Implementation repos consume the interface and provide the concrete service.
| Component | Role |
|---|---|
| grammateus | Tenant management API server |
| prora | Tenant self-service frontend |
| naukleros | Source handler interface |
| phortizo | Source handler implementation (GitHub) |
| keleustēs | Renderer interface |
| orpheus | Renderer implementation |
| diataxis | Orderer interface |
| stolarches | Orderer implementation |
| akrostolion | Labeler interface |
| parasemon | Labeler implementation |
| katartismos | Provisioner interface |
| histia | Provisioner implementation |
| ekbole | Pruner interface |
| ekboleus | Pruner implementation |
| pharos | Pipeline coordinator |
Deployment
All platform resources run in the platform namespace (default katastroma, configurable). Tenant resources are in namespaces labeled with the tenant identity. The platform namespace is where all platform services, Gatekeeper, and platform Secrets reside.
The platform is deployed as Helm charts via phortion:
- Epibathra — tenant management stack (tenant API server, tenant API frontend, Grafana, gatekeeper, auth/IdP)
- Prymna — pipeline stack (pipeline coordinator, OTel collector, source handler APIs, renderers, orderers, and provisioners)