3 min read

kaphera CLI

A purpose-built command-line interface for provisioning EDC connectors, managing data space identities, and monitoring participant status across self-hosted, BYOC, and managed deployments.

What it is

A purpose-built command-line interface for provisioning EDC connectors, managing data space identities, and monitoring participant status. Written in Go with cobra. Supports three backend modes configured per named context: kubernetes (talks directly to CRDs via client-go, no server dependency), server (talks to the kaphera-cloud-server HTTP API), and cloud (talks to the kaphera-cloud-managed-server with organisation scoping, join flows, and billing). Over 95 commands today, covering every resource type across the three operators.

What it does for the customer

Provides full infrastructure-as-code and scripting capability for everything the platform does. A builder managing a self-hosted deployment uses the kubernetes backend to provision infrastructure through CRDs without needing kubectl or YAML knowledge. A systems integrator automating client onboarding uses the server backend against BYOC deployments. A participant on the managed platform uses the cloud backend for join flows and connector management. The named context system lets a single engineer switch between all three modes with kaphera context use.

Who it serves

lars-hoffmann is the builder who lives in the terminal. The kubernetes backend is his primary interface to the kaphera-edc-operator and kaphera-edc-enablement-operator on self-hosted deployments. He uses the server backend against BYOC clients. The CLI fits into his existing delivery toolchain (ArgoCD, Terraform, GitOps) without forcing a context switch to a web console.

leila-brandt is the backend engineer building a Catena-X integration into her SaaS product. She uses the cloud backend to programmatically provision connectors, register data assets, and configure policies via the control plane management API. If the product scales to provisioning connectors for clients’ suppliers, the CLI’s cloud backend is how she automates it.

marco-ferretti’s engineering team uses the CLI to automate client provisioning as part of their white-label offering.

dirk-wassermann’s platform engineers use the CLI for day-two operations on their BYOC deployment, integrated into their existing toolchain.

Why this licence: Apache 2.0

The CLI is an enablement tool. The more engineers who use it, the more natural it becomes to adopt Kaphera’s operators and platform. The kubernetes backend makes it the command-line interface for the open-source EDC operator family; restricting it would undermine the entire open-source strategy. Revenue comes from what the CLI connects to (managed platform, BYOC server), not from the CLI itself.

How it relates to other artefacts

Consumes all three operators’ CRDs directly (kubernetes backend), the kaphera-cloud-server (server backend), and the kaphera-cloud-managed-server (cloud backend). Companion to the kaphera-cloud-terraform-provider: the CLI is for interactive and scripted workflows, Terraform is for declarative state management. Both share the same backend abstraction and context configuration. The kaphera-cloud-console is its graphical counterpart. Command availability varies by backend; join only exists in cloud mode, organisation create only in server/cloud mode.

sequenceDiagram
  actor User
  participant CLI as kaphera CLI
  participant K8s as Kubernetes API (CRDs)
  participant Srv as Cloud Server (BYOC)
  participant Mgd as Managed Server
  Note over CLI: backend = kubernetes
  User->>CLI: kaphera connector create
  CLI->>K8s: apply CRD
  K8s-->>CLI: status
  Note over CLI: backend = server
  User->>CLI: kaphera connector create
  CLI->>Srv: POST /connectors
  Srv->>K8s: apply CRD
  K8s-->>Srv: status
  Srv-->>CLI: response
  Note over CLI: backend = cloud
  User->>CLI: kaphera join <dataspace>
  CLI->>Mgd: POST /joins (org-scoped)
  Mgd-->>CLI: progress events

Graph View

Backlinks