3 min read

Kaphera Digital Twin Registry

A multi-tenant, AAS Part 2-compliant registry for managing digital twin metadata across data space participants. Written in Rust to serve hundreds of participants from a single shared process with strict tenant isolation.

What it is

A multi-tenant, AAS Part 2-compliant registry for managing digital twin metadata across data space participants. Written in Rust. Where existing implementations in the ecosystem are single-tenant (one process per organisation), the Kaphera DTR is built from the ground up to serve many participants from a shared process with strict tenant isolation, fine-grained access control, and Catena-X compliance. It is the infrastructure that Catena-X requires for product-level data exchange.

What it does for the customer

Makes digital twin metadata management viable at scale. Instead of deploying a separate registry instance per organisation, a single DTR process can serve hundreds of participants with full isolation. For Catena-X participants, it satisfies the mandatory registry requirement. For platform operators, it dramatically reduces the per-participant infrastructure cost of offering registry services, a critical factor for making SME participation economically viable.

Who it serves

lars-hoffmann is the builder deploying Catena-X infrastructure for clients. The multi-tenant DTR replaces per-client registry instances with a shared process, reducing infrastructure cost and operational overhead across his project portfolio.

sophie-renard is the governance authority whose consortium operates a Catena-X-compatible data space. The DTR provides the registry infrastructure her participants need for product-level data exchange.

thomas-brandt is the mid-size supplier participating in Catena-X. His connector publishes and discovers submodel descriptors through the DTR to satisfy the OEM supply chain mandate.

Why this licence: GPL

The DTR is infrastructure that the Catena-X ecosystem needs. GPL ensures it stays open: any organisation that deploys it must share their modifications, preventing fragmentation of a compliance-critical component. More protective than Apache 2.0 because the registry is close to the data space protocol layer, where interoperability depends on implementations staying aligned.

How it relates to other artefacts

Deployed alongside the kaphera-edc-operator connectors: a connector publishes and discovers submodel descriptors through the DTR. Managed by the kaphera-edc-enablement-operator in automated deployments. In the managed platform, the kaphera-cloud-managed-server handles DTR provisioning as part of the data space join flow. The [[kaphera-cli|kaphera CLI]] and kaphera-cloud-terraform-provider can manage DTR resources through any backend mode. It is a standalone artefact that can also be used entirely independently of the Kaphera platform.

Multi-tenant request routing

flowchart LR
  T1["Tenant A<br/>connector"]
  T2["Tenant B<br/>connector"]
  T3["Tenant C<br/>connector"]
  AUTH["Auth + tenant<br/>resolution"]
  DTR["Shared DTR<br/>process (Rust)"]
  DB[("Per-tenant<br/>row-level isolation")]
  T1 --> AUTH
  T2 --> AUTH
  T3 --> AUTH
  AUTH --> DTR
  DTR --> DB
  • kaphera-edc-operator: the connector lifecycle operator the DTR sits alongside.
  • kaphera-edc-enablement-operator: the operator that manages DTR deployment in automated setups.
  • kaphera-dsp-data-plane: the other Enablement-tier component; both ship under protective open-source terms.
  • lars-hoffmann: the platform engineer for whom the multi-tenant DTR replaces per-client registry instances.
  • sophie-renard: the governance authority running a Catena-X-compatible data space that requires this registry.

Graph View

Backlinks