Prerequisites

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 needs a Kubernetes cluster, network endpoints, datastores, registry access, and generated secrets. The support chart can supply development datastores; production operators must verify availability, security, and recovery for each dependency. Complete this checklist before installing the charts or changing networks, custody, or hosting.

Decide first: bundled services or managed servicesCopy Anchor Link

One decision shapes the rest of this checklist. The support chart bundles PostgreSQL, Redis, an S3-compatible object store, and an ingress controller, each behind its own enable flag, and the dalp chart's default values point at those bundled services. That default installs and runs with nothing external beyond the items marked always yours below.

The bundled datastores are development-shaped: single instances, committed or generated credentials, neither of them yours, and no managed backups. Run them for development and test environments, where losing a volume costs you a rebuild rather than records. Point a production deployment at managed PostgreSQL, Redis, and object storage instead, and keep support only for the pieces you still want in-cluster, such as the ingress or gateway controller. A managed service can provide replication, patching, and backups. Confirm the selected service plan and settings, then include its endpoint and credentials in this checklist. Values and secrets shows how the swap is configured, and Topologies covers the deployment shapes.

Each item below says which side of that decision it sits on: always yours, bundled by default, conditional, or optional.

What you must supplyCopy Anchor Link

An RPC endpoint for every network you enableCopy Anchor Link

Always yours. Every network in the networks configuration needs connection details, and the instance refuses to start an EVM entry that has neither a single RPC URL nor a list of upstreams. More than one upstream buys failover: the platform scores upstream health and shifts traffic away from a lagging endpoint, so a healthy second upstream can provide failover when one fails.

• The RPC URL, or the list of upstreams, for each EVM network you plan to enable.
• An API-key or basic-auth credential for any upstream that requires one.
• Which network is your default. Exactly one enabled EVM network carries the default flag.

A custody provider, when signing leaves the platformCopy Anchor Link

Conditional. The signer.provider setting decides who holds signing keys. The default, local, is the platform's own key store: keys live encrypted inside the platform, protected by the encryption master password below, and nothing external is needed. The keys and their encryption password sit inside the same deployment. This arrangement provides no independent custody boundary or external approval step to prevent a compromised deployment from signing a transaction. A separately governed signing path can add another control boundary through a custody providerA Custody Provider decides who signs for an organization's accounts, a managed custodian or the holder's own wallet, without changing accounts or approvals.Read the concept instead. Choosing dfns, fireblocks, luna, or ripple moves signing to that provider, and the chart then requires that provider's configuration block, filled with its credentials:

• DFNS: an auth token, or a credential ID and private key. An organization ID when your DFNS account is scoped to one.
• Fireblocks: an API key and private key. A webhook URL when Fireblocks should call back into the platform.
• Luna HSM: the PKCS11 library path, a token label, and a PIN reference. Client certificate and key references when your HSM requires mutual TLS.
• Ripple Custody: the user ID, client ID, and private key the integration signs with, plus the vault ID and key strategy for the wallets it manages. Ripple is the one provider this platform ships switched off. Set custody.providers.ripple.enabled: true in your Helm values, or CUSTODY_PROVIDER_RIPPLE_ENABLED=true outside the chart.

Each custody provider has its own switch, custody.providers.<kind>.enabled. A provider that is off leaves the Console catalog and the published capability templates, and the platform refuses a new provider configuration that names it. Configurations stored while that provider was on keep signing, and their credentials can still be rotated, because the switch closes intake and does not revoke live accounts. To stop one existing account from signing, quarantine its provider configuration.

Have ready whichever combination your provider's own authentication flow needs; the provider, not the platform, decides which is sufficient. For inbound custody webhooks, DFNS and Ripple each need a webhook secret you supply. Fireblocks webhook verification works against Fireblocks' published key endpoint out of the box; override it only when your Fireblocks environment publishes keys elsewhere on an https endpoint under fireblocks.io, the only host the platform accepts.

An SMTP relay, because every instance sends emailCopy Anchor Link

Always yours. Invitations and notifications go out over SMTP, and the platform has no relay of its own. Nothing checks the relay at boot, so a missing or wrong relay surfaces as the first invitation that never arrives. Confirm delivery before your first user is waiting on one.

• An SMTP host and port.
• A username and password for that relay. For a relay that accepts mail from your cluster without authentication, leave both empty. If you set only one of them, the platform sends no email.
• The sender name, and optionally the address, the platform sends as.

A PostgreSQL database: bundled by default, yours in productionCopy Anchor Link

The Platform API stores its state in PostgreSQL and does not start without a reachable database. The support chart bundles a single-instance server the default values already point at. For production, provision a managed instance reachable from your cluster and sized for your load, then swap the connection over.

• For production: a managed PostgreSQL instance, reachable from the cluster.
• Its connection details: a URL, or hostname, database name, and credentials.
• A pass over the connection budget when you change replica ceilings; see Values and secrets.

Redis: bundled by default, yours in productionCopy Anchor Link

The deployed chart profile ships the Redis-backed cache enabled, pointed at the bundled Redis. That is not decoration: the Console and the Platform API each run at least two replicas out of the box, and the cache's in-memory fallback lives per pod. Without a shared Redis, which pod answers a request would decide what a reader sees. Keep the cache on, and bring your own endpoint when you drop the bundle.

• For production: a managed Redis endpoint with host, port, and credentials, plus TLS settings when it requires them.

An object storage bucket: bundled by default, yours in productionCopy Anchor Link

Every operation that stores or retrieves a file needs a bucket. The default profile uses the bundled S3-compatible store. For production, pick one provider and have its access ready:

• AWS S3: the bucket's region, plus an access key pair unless you rely on IAM Roles for Service Accounts, the usual workload-identity alternative to a static key.
• Google Cloud Storage: the project ID and a service account key, or inline credentials, unless you rely on Workload Identity, the usual alternative to a static service account key.
• Azure Blob Storage: the storage account name plus an account key, a connection string, a SAS token, or Azure AD Workload Identity as the alternative to a static key.
• Another S3-compatible service: its endpoint, region, access key, and secret key.

A filesystem provider exists for development; its default signing key names itself unsuitable for production.

An encryption master password you generateCopy Anchor Link

Always yours. The platform encrypts sensitive data at rest with a master password you generate, at least 16 characters. The chart ships the value empty, so leaving it unset prevents the affected application pods from starting at boot. Never re-mint it for an existing environment: data encrypted under the old password becomes unreadable. See Values and secrets for the two-step rotation.

• A generated master password, at least 16 characters, stored with the rest of your secrets.

An auth secret you generateCopy Anchor Link

Always yours. auth.secret signs and verifies sessions and must be at least 32 characters, with or without SSO. Unlike the master password, the chart does not ship it empty: the values file commits a placeholder that already passes the length check and boots cleanly. The platform rejects that placeholder only in production, so a non-production install can run indefinitely on a publicly known session-signing secret and never say so.

• A generated secret of at least 32 characters for auth.secret, replacing the chart's committed placeholder.
• Confirm the placeholder is gone before any install a real user reaches, since only the production boot check rejects it.

Pull access to every image registry the charts referenceCopy Anchor Link

Always yours. Either hand the chart registry credentials so it renders the pull secrets for you, or pre-create matching secrets in the target namespace. Without them, pods sit in image-pull errors instead of starting.

• Registry credentials for the chart to render, or pull secrets already present in the namespace.

Optional: a single sign-on identity providerCopy Anchor Link

The Console signs users in locally with email, password, and passkeys by default, and that path needs nothing from you. If you want an external OIDC provider instead, have its issuer URL, client ID, and client secret ready, and read Single sign-on first: a complete provider entry makes the external provider the sole login method the moment it rolls out.

• The OIDC issuer URL, client ID, and client secret, when you configure SSO.
• A plan for who at your identity provider can grant platform admin, when you set an admin claim.

Optional: an application secret-manager providerCopy Anchor Link

By default, secrets reach the platform as environment values you inject. If you would rather the platform fetch them at runtime from AWS, Google Cloud, Azure, or Vault, that is a separate configuration layer; see Values and secrets for what each provider needs.

What your hosting must provideCopy Anchor Link

See Hosting and access for how these choices shape topology and access; this section is the checklist to have ready before you install.

Kubernetes 1.21 or later, or OpenShift with the overlayCopy Anchor Link

The dalp chart, the support chart, and the optional observability chart all declare the same floor: Kubernetes 1.21 or later. OpenShift runs the same chart templates through a separate values overlay rather than a different chart; see Deploy DALP to OpenShift for what the overlay changes.

Before any chart, apply the Gateway API CRD bundle once per cluster: custom resource definitions no Helm release can carry, because Helm cannot upgrade CRDs shipped inside a release and the bundle exceeds what a release's stored secret allows. Skip it and a release that renders an HTTPRoute fails at install time on the unknown resource kind, which a first install on a bare cluster hits by default because the docs site's route renders out of the box. OpenShift is the exception: its overlay renders Routes instead of HTTPRoute resources for every service, so an OpenShift install has no HTTPRoute to fail on and does not need the bundle at all; see Deploy DALP to OpenShift for the overlay. Install covers the bundle's version and where it sits in the order.

• The Gateway API CRD bundle applied to the cluster, before any chart, unless you install on OpenShift, whose overlay renders Routes instead and needs no CRD bundle.
• A Kubernetes cluster at 1.21 or later, or an OpenShift cluster with the overlay applied.
• A default StorageClass that can bind the bundled PostgreSQL's persistent volume, when you run the bundle.
• When you enable the chart's contract-deployment job: a Retain-policy StorageClass for its journal volume, or the cluster's CSI provisioner plus permission to create StorageClass resources so the chart can create the Retain class for you. The job resumes from that journal after a pod restart, and losing the volume forces a fresh deployment at new addresses your running network cannot reconcile.

One exposure mechanism per service, and TLS you bringCopy Anchor Link

The Console ships with ingress enabled. The docs site ships with its own ingress enabled too, routing /docs on the Console's hostname. The Platform API stays internal, reached through the Console's own proxy. The block explorer is off by default and brings its own ingress when you enable it. Choose one intended exposure path per service from Ingress, Gateway API HTTPRoute, and OpenShift Route. If multiple objects render, inspect their hostnames and controller ownership for conflicting routes; the OpenShift troubleshooting section shows what that looks like.

Outside OpenShift, keep the support chart's bundled ingress controller unless you have a reason to swap it: it registers the class the dalp chart's ingresses already name, so the default path works as installed. On OpenShift, skip it, since Routes replace ingress there and the controller has nothing to do. Your own controller works too, outside OpenShift; change the ingress class to match it. Reach for Gateway API HTTPRoute instead when your cluster standardizes on the Envoy Gateway controller support can also bundle, behind its own enable flag.

TLS differs by platform. Outside OpenShift, the chart requests no certificates: add cert-manager annotations or pre-created TLS secrets to the ingress, or HTTPS to your hostnames fails while plain HTTP answers. On OpenShift, Routes terminate TLS at the edge with the router's certificate and redirect plain HTTP. HTTPS therefore works without cert-manager. The optional per-Route cert-manager Certificate is disabled by default; replace its placeholder issuer with your cluster's issuer before enabling it.

• An ingress controller, a Gateway API implementation, or OpenShift Routes: exactly one per exposed service.
• A load balancer the controller can obtain an external address from.
• A certificate source outside OpenShift: cert-manager wiring or pre-created TLS secrets.
• DNS entries for every hostname you plan to expose.

Backups decided and tested before productionCopy Anchor Link

The platform starts without a backup plan; production without one leaves a failure with no recovery path. The bundled datastores carry no managed backups, and the bundled Velero ships disabled. A managed database and object store bring their own backup story, which is one of the reasons production points at them.

• A backup and restore approach for PostgreSQL and object storage, tested before go-live. See Backup and disaster recovery for what a tested approach covers.

Resource sizing starts from the chart defaultsCopy Anchor Link

The charts state defaults for their own components. Treat them as the starting point: production requirements depend on indexed chain volume, participant count, and request rate, none of which the chart can see in advance.

The bundled services add their own footprint when you run them; the bundled PostgreSQL alone requests 500m CPU and 2Gi of memory, with PgBouncer and the metrics exporter both small next to it, 100m CPU each and no more than 256Mi of memory at their limits. The charts run the same way on any conforming cluster. Provider-specific setup covers storage, networking, and credentials. Supply a StorageClass that can bind these volumes and a load balancer that can assign an address to your controller. On managed clouds, workload identity can replace the static keys in the checklists. A self-managed or bare-metal cluster brings its own load balancer and injects every credential as a secret.

How a missing item shows upCopy Anchor Link

You are ready to install when every item above is confirmed and you can name where each credential lives. If something slips through anyway, this is the signal each gap gives:

Once every item is confirmed, continue to Install, which covers the Gateway API CRD prerequisite and the chart install order before you run the Helm charts.

Frequently asked questionsCopy Anchor Link

See alsoCopy Anchor Link

• Install for the chart set, the Gateway API CRD prerequisite, and the install order once every item above is checked.
• Values and secrets for how each credential reaches the chart.
• Deploy DALP to OpenShift for the OpenShift overlay and its own preconditions.
• Networks and Single sign-on for the configuration these prerequisites feed into.