Install DALP
The three Helm charts a DALP deployment composes, the Gateway API CRD bundle that precedes them, and the order to install them in.
A DALP InstanceA DALP Instance is one self-contained copy of the platform, deployed inside a boundary you choose and connected to ledger networks you approve.Read the concept is one running copy of the platform: the Platform API that handles transactions and workflow orchestration, the Console operators and issuers sign in to, and the datastores and telemetry behind them. All of it deploys together inside a boundary you choose, but it is not one Helm release. It composes up to three charts, each installed and upgraded as its own release, plus one cluster-level prerequisite that is not a chart at all. Which of the three you install depends on what your cluster already has, so this page names the set and the order before the pages in this group configure each piece.
Three 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 the whole platform. 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.
The support chart is a separate, optional release for clusters that do not bring their own infrastructure. By default it deploys in-cluster PostgreSQL, Redis, RustFS object storage, an ingress controller, and a config reloader. The Envoy Gateway controller, shared Gateway, and GatewayClass each have a separate flag, disabled by default. Velero backups are also disabled by default. For Gateway API routing, enable all three gateway flags unless another release already provides the cluster's GatewayClass. The controller subchart is the piece the chart's own guidance keeps out of production: install gateway-crds-helm and gateway-helm as separate, out-of-band releases there instead of enabling envoy-gateway, which stays a bare-cluster or non-production choice. The shared Gateway carries no such caveat; it plays the production role the ingress controller's Service plays, provisioning the one cluster-wide LoadBalancer every app chart's HTTPRoute attaches to. Its bundled datastores ship with development credentials, so a production deployment points global.datastores at managed services instead, per Values and secrets, and keeps support for the ingress controller alone, or drops it entirely once every piece has an external replacement.
The observability chart is a third optional release: an Alloy collector, VictoriaLogs, Tempo, and VictoriaMetrics stores, and Grafana with DALP dashboards and alert rules already provisioned. 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 path that ends up rendering an HTTPRoute: custom resource definitions applied once per cluster, before any of the charts. No release you should rely on carries them for the long term. support's gateway-helm dependency can install the bundle behind envoy-gateway.enabled, but Helm cannot upgrade CRDs that ship in a subchart's own crds/ directory, so that path is install-only and never refreshes them again. The dalp chart's docs site renders an HTTPRoute by default, so most installs need the bundle; a cluster that routes everything through ingress instead can turn that default off, docs.httpRoute.enabled: false, and skip the bundle entirely. Wherever the bundle does apply, its version follows the Envoy Gateway controller version the support chart pins, 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 top to bottom by default. Only the CRD bundle's position is fixed; steps 2 and 3 are optional releases, and their order relative to each other is a preference, not a requirement, except on OpenShift's Route-based overlay, which skips the CRD bundle entirely.
What each position in the order protects
The CRD bundle guards the resource kind, and that half fails loudly. 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, not silently later. 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, quiet gate. The docs site's HTTPRoute points by default at a Gateway named dalp-gateway in the support release's namespace, and that Gateway exists only when support's own gateway flag is turned on, off by default. Drop or trim support without turning that flag on, and the docs release still installs cleanly: no error, no route, nothing in helm status to flag it.
The support chart comes before dalp whenever its bundled PostgreSQL backs the platform. An init container in the dalp release's migration job waits on that database first, on its own 2 minute budget (dapp.initContainer.tcpCheck.timeout, 120 seconds by default). Helm charts covers the migration job's own retry and timeout budget, and what happens to the release when the job never finishes.
The observability chart can land any time before you rely on it, but before dalp is the cheap choice. The platform's export endpoints resolve from the first pod onward, instead of failing until the receiver appears, and the first hours of a new instance are exactly the hours you later want telemetry from.
Which of the three you install
The dalp chart is constant across paths. The prerequisite depends on whether any release in your shape renders an HTTPRoute (the docs site does by default), and the other two follow from what your cluster already runs. OpenShift replaces the prerequisite and the routing entirely, and gets its own hub card below.
| Your cluster | Install | Why |
|---|---|---|
| Managed PostgreSQL, Redis, and object storage, and an existing metrics and logging stack. | CRDs, then dalp. Drop support, or keep it for the ingress controller alone. Set docs.httpRoute.enabled to false first and neither the CRDs nor a Gateway apply. | The platform reads its datastores from global.datastores, and its telemetry export endpoints repoint to your own collector. The CRD bundle exists only because the docs site's HTTPRoute renders by default; an ingress-only cluster can turn that off and skip the bundle for good. |
| Managed datastores, no telemetry stack. | CRDs, observability, then dalp, with support trimmed as above. Skip the CRD bundle the same way if ingress covers every route. | The bundled stack arrives with DALP dashboards and alert rules provisioned, which you would otherwise rebuild in your own Grafana. |
| A bare cluster, or a first environment. | All four, in the pictured order, plus the support chart's envoy-gateway, gateway, and gateway.gatewayClass flags if you route through Gateway API instead of its ingress controller. | The support defaults stand up datastores and an ingress controller in-cluster, with development credentials you replace before the environment matters; Gateway API routing needs its controller, shared Gateway, and GatewayClass turned on explicitly, since a first environment has no other release to claim the GatewayClass for the cluster. |