---
title: "Platform, Build & Observability"
description: "How OpenEPCIS is built, deployed, and observed."
canonical_url: "https://openepcis.io/docs/platform-overview/modules/platform"
last_updated: "2026-07-02T20:31:24.258Z"
---

This is the connective tissue — the things that don't ship in any one container but tie every container together. A single Maven Bill of Materials anchors every dependency version, so bumping the BOM defines a platform release and every customer running the same release runs identical conformance behaviour. The build aggregator under `openepcis-build/` produces thirteen Quarkus container images from that one version source: the EPCIS REST and SOAP front-ends, the capture topology, the resolver, the GS1 Germany platform integration, the S3 loader, the files server, the AI assistant, plus variants for Azure Kubernetes, plain-OIDC and Elasticsearch storage.

Deployment is opinionated but optional. Terraform modules and Helm charts cover the Kubernetes path; an Ansible-driven Docker Compose stack is shipped for smaller deployments and local development. Whichever route you pick, the deployment is reproducible — the same release artefacts on the same infrastructure-as-code yield the same running system.

OpenTelemetry is wired through. Traces propagate across REST endpoints, the capture pipeline, and storage calls, so a slow `/capture` request can be traced down to the storage shard that's responding slowly without correlating logs by hand. Drop the traces into whichever observability stack the customer already runs.

## Capabilities by edition

<table>
<thead>
  <tr>
    <th>
      Capability
    </th>
    
    <th>
      OSS
    </th>
    
    <th>
      Business
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Self-host on Kubernetes (Terraform / Helm)
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
  </tr>
  
  <tr>
    <td>
      Self-host on Docker Compose
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
  </tr>
  
  <tr>
    <td>
      OpenTelemetry tracing
    </td>
    
    <td>
      <span className="fm-no">
        —
      </span>
    </td>
    
    <td>
      <span className="fm-yes">
        ✓
      </span>
    </td>
  </tr>
</tbody>
</table>

## DPP sub-platform

A separate but adjacent body of work covers the EU Digital Product Passport regulations: the DPP-Ready JSON-LD context modules (battery, textile, electronics, EUDR, detergents), the Battery DPP reference implementation against EU 2023/1542, and DPP-Quest as an interactive ontology browser. These follow the same GS1 conformance discipline as the rest of the platform — Digital Link identifiers, masterdata on the resolver, no embedded EPCIS masterdata blocks — and they get their own doc set once the underlying ontology pass stabilises.

## See also

- [Architecture](/docs/platform-overview/architecture) — every cross-cutting concern this group enables.
- [Modules → EPCIS Events](/docs/platform-overview/modules/epcis-events) — the biggest consumer of the build variants.
- [Roadmap](/docs/platform-overview/roadmap) — coordinated work across the build and the runtime.