---
title: "Platform, Build & Observability | OpenEPCIS Docs | OpenEPCIS - an open-core, GS1-compliant EPCIS implementation."
canonical_url: "https://openepcis.io/de/docs/platform-overview/modules/platform"
last_updated: "2026-06-28T23:26:21.717Z"
meta:
  author: "benelog GmbH & Co. KG"
  description: "How OpenEPCIS is built, deployed, and observed."
  "og:description": "How OpenEPCIS is built, deployed, and observed."
  "og:title": "Platform, Build & Observability"
  "twitter:description": "How OpenEPCIS is built, deployed, and observed."
  "twitter:title": "Platform, Build & Observability"
---

</h2>Home

``

# **Platform, Build & Observability** How OpenEPCIS is built, deployed, and observed.2 min read 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 | **Capability** | **OSS** | **Business** |
| --- | --- | --- | | Self-host on Kubernetes (Terraform / Helm) | — | ✓ | | Self-host on Docker Compose | — | ✓ | | OpenTelemetry tracing | — | ✓ | ## 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](https://openepcis.io/docs/platform-overview/architecture) — every cross-cutting concern this group enables. - [Modules → EPCIS Events](https://openepcis.io/docs/platform-overview/modules/epcis-events) — the biggest consumer of the build variants. - [Roadmap](https://openepcis.io/docs/platform-overview/roadmap) — coordinated work across the build and the runtime.