A DALP Instance is one running copy of the platform: the Platform API that handles transactions and workflow orchestration, the Console that operators and issuers sign in to, and the telemetry behind them, all running against datastores you supply. You install it as the dalp Helm release, an optional observability release, and one cluster-level prerequisite, the Gateway API CRD bundle. Apply the CRD bundle first, then install observability if your cluster has no telemetry stack of its own, then dalp.
Installing needs rights to create cluster-scoped resources, because the CRD bundle and the observability chart's collector create them, and network access from the cluster to your PostgreSQL. Both charts come from the SettleMint OCI registry, pkg., and Prerequisites lists the registry access the cluster needs.
Two releases and one prerequisite
The dalp chart is the platform itself: an umbrella release whose subcharts all pin one shared chart version, so one version number describes every subchart of the release. The CRD bundle, the observability release and your datastores have versions of their own. The Platform API, the Console, the docs site that publishes this documentation, PgBouncer connection pooling, and a PostgreSQL metrics exporter install by default. A block explorer and an Investor portal each have an enable flag. Helm charts covers installing it and what a release waits on. It deploys no datastore and no ingress controller, so PostgreSQL, Redis, object storage, and the ingress controller or Gateway API implementation are services you supply, per Prerequisites and Values and secrets.
The observability chart is a second, optional release: an Alloy collector, VictoriaLogs, Tempo and VictoriaMetrics stores, and Grafana with DALP dashboards provisioned and the DALP alert rules ready to switch on. The platform's default telemetry export endpoints name this chart's services in the monitoring namespace, so the two halves connect without per-URL wiring when the chart lands where the defaults expect it. Observability stack covers it.
The Gateway API CRD bundle is the prerequisite for any release that renders an HTTPRoute: custom resource definitions applied once per cluster, before any of the charts. No DALP chart carries them, because Helm cannot upgrade CRDs that ship in a subchart's own crds/ directory, so a chart that carried them would install them once and never refresh them. The dalp chart's docs site renders an HTTPRoute by default, so most installs need the bundle. A cluster that routes everything through ingress can set docs. and skip the bundle. The bundle's version is the one in your CRD command, not the dalp chart version, so a dalp upgrade alone never tells you the CRDs also need one. OpenShift runs a different overlay that renders Routes instead of HTTPRoute resources and does not need this bundle at all. Helm charts covers which subcharts render a route and what the failure looks like.
Install order: the CRD bundle first, then the optional observability chart, then the dalp chart.
What each position in the order protects
The CRD bundle guards the resource kind. Kubernetes validates a resource's kind before storing it, so a release that renders an HTTPRoute on a cluster without the Gateway API CRDs fails at install time. The docs site's HTTPRoute renders by default inside the dalp chart, so a first install on a bare cluster hits this gate unless the CRDs went in first.
The Gateway it attaches to is a separate gate, and it fails without an error. The docs site's HTTPRoute points by default at a Gateway named dalp-gateway in a placeholder namespace, and no chart in this set creates that Gateway. Unless a Gateway with that name exists in that namespace of your cluster, the docs release still installs cleanly: no error, no route, nothing in helm status to flag it. Set docs. and docs. to your own Gateway.
Your PostgreSQL must be reachable when the dalp release's migration job starts. An init container in each attempt of that job waits up to 2 minutes for the database (dapp., 120 seconds by default), and the job retries up to 3 times inside its 600-second dapp.migrator.timeout window. Helm charts covers the migration job's own retry and timeout budget, and what happens to the release when the job never finishes.
Install the observability chart before dalp so the platform's export endpoints resolve from the first pod, instead of failing until the receiver appears. The first hours of a new instance are the hours you later want telemetry from.
Which releases you install
The dalp chart is on every path. You need the CRD bundle when any release renders an HTTPRoute, and the docs site does by default. You need the observability chart when your cluster has no telemetry stack. You supply the datastores and the ingress or Gateway on every path. OpenShift uses Routes instead of the CRD bundle and Gateway routing, as OpenShift describes.
The commands for each step are on Helm charts, for the CRD bundle and dalp, and on Observability stack, for observability.