Kaphera Cloud Server

An Axum REST API server that exposes authenticated CRUD over the three operators’ Kubernetes custom resources: the deployable backend for BYOC and self-hosted customers.

What it is

An Axum REST API server that provides authenticated CRUD operations over the Kubernetes custom resources managed by the three operators (kaphera-edc-operator, kaphera-edc-enablement-operator, and kaphera-cloud-operator). Stateless: it reads and writes CRDs through the Kubernetes API and authenticates requests via Keycloak OIDC. Written in Rust. This is the deployable product for BYOC customers: Kaphera deploys and manages this server remotely in the customer’s cluster.

What it does for the customer

Gives teams a familiar HTTP API for managing EDC infrastructure and organisational resources without requiring Kubernetes API access or kubectl expertise. It is the backend that powers the kaphera-cloud-console and the server backend mode of the [[kaphera-cli|kaphera CLI]] and kaphera-cloud-terraform-provider. For BYOC deployments, it is the product: the thing Kaphera installs, configures, and operates in the customer’s environment.

Who it serves

lars-hoffmann uses the server backend in the CLI and Terraform provider to manage client deployments through a standard API instead of requiring direct cluster access on every project.

marco-ferretti uses it as the API layer his white-label offering is built on. His engineering team integrates against it to build their own console or client-facing tooling.

dirk-wassermann gets the BYOC product. Kaphera manages this server on his infrastructure, giving his non-platform teams access to connector management through standard HTTP tooling while his engineers retain control of the underlying cluster.

Why this licence: Source-available — Elastic

The server is the product boundary. It encodes how CRDs are exposed as a coherent API, how authentication and authorisation are layered, and how the platform experience is shaped. Source-available so customers can audit exactly what runs in their cluster. Free to run internally; offering it as a commercial service requires a licence agreement.

How it relates to other artefacts

Sits on top of all three operators, providing an HTTP interface to their CRDs. The kaphera-cloud-managed-server extends it with additional capabilities (audit, billing, directory, join flows). The kaphera-cloud-console is its frontend. The [[kaphera-cli|kaphera CLI]] (server backend) and kaphera-cloud-terraform-provider (server backend) consume this API. A GET /capabilities endpoint tells clients what features are available, allowing the same Console and CLI codebase to adapt to either server.

Capabilities negotiation

flowchart TB
  CON["Console"]
  CLI2["kaphera CLI"]
  TF["Terraform provider"]
  CAP["GET /capabilities"]
  BSV["Cloud Server<br/>(BYOC)"]
  MSV["Managed Server<br/>(SaaS)"]
  CON --> CAP
  CLI2 --> CAP
  TF --> CAP
  CAP -->|"BYOC feature set"| BSV
  CAP -->|"SaaS + directory + billing"| MSV

Related

• kaphera-cloud-managed-server: the SaaS extension built on top of this server.
• kaphera-cloud-console: the web UI fronting this API.
• kaphera-cloud-operator: the operator that creates the organisational context this server scopes resources into.
• dirk-wassermann: the BYOC enterprise lead for whom this server is the deployable product.
• marco-ferretti: the white-label partner whose branded offering is built on top of this API.