A DALP Instance runs in a Kubernetes environment you select, and how far the vendor can reach into it is a separate choice from who owns the hardware or cloud account. On this page the vendor is SettleMint, the publisher of DALP. The vendor can hold cluster access, receive outbound telemetry only, hand over the chart and never connect, or be removed from image supply by a mirrored registry. Cluster access is data access: whoever reaches the cluster can read the credentials to the database.
Four rungs of vendor access, from most to least: operator access, telemetry forwarding only, a handed-over chart and a mirrored registry.
Two independent choices
“Whose infrastructure” decides where the cluster physically runs and who holds administrative control over the hardware or cloud account underneath it. How involved the vendor stays once the instance is running is a separate question. The access ladder runs from direct cluster access down to none, and the rung you pick decides who carries the day-to-day operating load.
On infrastructure you hold, your team usually operates the instance and the vendor supports the install. On infrastructure the vendor holds, the vendor usually operates it. The infrastructure choice does not enforce either pairing. The access ladder sets the operating split for each environment.
A DALP release installs the platform workloads and nothing beneath them. Dedicated hardware, cloud accounts, cluster control planes, and namespace isolation depend on the hosting arrangement, and the chart alone does not guarantee them.
A self-hosted instance can install from images you mirror into your own registry, with no route to the vendor. It still needs every endpoint you configure: ledger RPC, SMTP, the datastores, and any custody or identity provider. The chart ships no egress policy, so restrict outbound traffic to those endpoints in your network. A vendor-hosted instance installs the same charts.
Cluster access means data access
If vendor access to your data is unacceptable, choose rung 2, 3 or 4. None of them grants cluster access.
The access ladder
The ladder has four rungs, from most vendor involvement to least. Each rung trades vendor involvement for work your own team takes on.
1. Operator access to the cluster
At the top, you grant the vendor direct access to the cluster: someone who can already see the running system does not need you to reproduce a problem before they can act on it. It is also the most access a vendor can hold. Cluster administration reaches the database credentials and the encryption master password, and with the default local signer and secret manager those two open every signing key the platform holds, so whoever holds this rung can sign as the wallets the platform manages. A custody provider or an external secret manager moves the keys out of that reach. Your own team carries the least operating load at this rung, since the vendor can debug and upgrade directly. Choose it when getting a problem fixed fast matters more than keeping every credential inside your own team.
2. Telemetry forwarding only
One rung down, you grant nothing but an outbound connection. The platform's monitoring stack can run in a forwarding mode that pushes metrics, logs, and traces to an endpoint you configure, so the vendor can watch platform health without ever reaching your cluster directly. Your own team still runs every install and upgrade at this rung, and the vendor's reach stops at the telemetry it receives. Forwarding adds only an outbound OTLP connection from the cluster to the endpoint you configure, and the chart opens no inbound port or route for it. Choose this rung when you want the vendor watching for trouble without touching the cluster. Your team runs the observability release that forwards, and keeps its credential current.
Operating it:
- Redaction. Logs pass through an attribute allow list and text redaction before they leave. The allow list keeps only the attribute keys the chart names and drops everything else on a log record. Then the body text is rewritten: credential-shaped text such as a password or token becomes a marker, and so does any email address. A hex string of 40 to 64 characters is masked too, which covers wallet and contract addresses, transaction hashes and storage keys. Redaction does not remove names, phone numbers, bank account numbers or other personal data in free text. Metrics and traces carry no redaction: a span or metric label your own code set leaves as written. Treat forwarded telemetry as data that can contain personal data.
- Authentication. Off by default. Set a username and the matching
observability-Secret, and the connection carries it. Leave the username unset and it forwards unauthenticated. The chart does not create that optional Secret. A missing Secret can leave the telemetry forwarder, Grafana Alloy, running with a blank password, while the receiver rejects its pushes. Check delivery errors as well as pod health.forwarding- basic- auth - Profiles. A separate switch on the same mode. The platform pushes no profiles itself, so profile forwarding relays only profiles that another agent you run pushes to the collector.
3. No agent, chart handed over
Below that, you can skip an agent entirely. The vendor hands you the chart, and your team runs the install and every upgrade after it, straight from the published registries: pkg. for the charts and ghcr.io for the DALP images. A pod that reschedules onto a node without its image cached pulls again, so a lost route to those registries, or an expired pull credential, surfaces as image-pull errors on the next drain or scale-out. This rung costs you the vendor's outside view. Review enabled telemetry and external integrations to determine what leaves the deployment. Diagnosing a problem starts from what your own team can see. Choose it once you are ready to operate independently, but before you need to control your own image supply too.
4. A mirrored registry
At the bottom, the vendor is out of image supply as well. Copy the charts and every image into your own registry, set global.imageRegistry to it, and install entirely from your copy. Choose it when even an outbound telemetry connection is unacceptable, or your network has none to offer. Take it only if you can sync the registry before every install and upgrade.
Images to mirror. A default install pulls from four registries: ghcr.io for the DALP images and the TCP-check init container that most components use, docker.io for PgBouncer, its metrics exporter and the kubectl helper, quay.io for the PostgreSQL exporter, and registry.k8s.io for the pause placeholder. Mirror all of them. The Conjur authenticator image appears only when global.conjur.enabled is true. A mirror built only from the components you recognise strands the install.
Console origins. By default the Console, the web application operators sign in to, makes no runtime call to a content delivery network, hosted analytics or a third-party embed. It serves its fonts and avatars from its own origin, so it renders with no route to the internet. Two settings make the Console load from another origin. Setting DALP_ in the Console's environment loads Google Analytics and HubSpot, and a theme font with a custom stylesheet address loads that stylesheet. Separately, a configured Ethereum Name Service network and gateway let the platform server fetch the avatar images that wallet names point at. Without them, each address shows a generated mark.
Server calls. Two server-side features call out of the cluster. The exchange-rate refresh fetches rates from a public currency API, cdn.jsdelivr.net with currency-api.pages.dev as fallback, unless EXCHANGE_ and EXCHANGE_ point at a source you control. The Console assistant and the docs site's Ask AI send each question, with the context they gather, to OpenRouter when ASSISTANT_ or an organisation's own assistant key is set. Review these, and the telemetry, RPC, custody and identity endpoints you configure, before you treat an environment as air-gapped.
Operating it. A missing image only fails the one Job or init container that needed it, not the whole release, so a partial rollout can look mostly healthy while it is stuck. Check the failing pod's image reference against what your registry holds. That comparison finds a sync that did not run to completion. See OpenShift for confirming every image reference resolves under an air-gapped install.
Infrastructure as code
The Helm charts that stand up a DALP Instance are what you receive. There is no separate infrastructure-as-code layer: DALP ships no Terraform module, Pulumi program or CloudFormation template. Whichever rung of the access ladder you choose, you can read every value the install sets before you run it, and run the same charts yourself if you decide to operate the platform on your own infrastructure.
Environments
Run at least one lower environment beside production, so an upgrade reaches it first. Promote the same chart version and images from test to production unchanged. Every environment installs the same dalp chart with its own values overlay, as Deployment topologies describes. Its deployment identity section covers how global.dalpInstance and global. keep environments apart in shared observability views.
Keep test data and credentials separate from production. A test deployment follows the networks and datastores you configure. Neither its environment label nor its chart prevents an operator from connecting production services or importing production data.
The access ladder applies per environment, not once for the whole deployment. Granting a vendor cluster access to staging says nothing about production. Each environment carries its own rung, chosen against the data that environment holds.
Consequences and reversibility
Two of the four rungs are values settings, though not on the same chart. Turning telemetry forwarding on or off is alloy.forwardingMode.*, but that key lives in the observability chart, not dalp. The dalp chart does not pull observability in as a dependency. Rung 2 needs the observability chart deployed as its own release. Pointing at a mirrored registry is global.imageRegistry on dalp itself. Either way, moving between rungs again is a redeploy. The other two are not chart settings at all. Operator access to the cluster is a kubeconfig and an RBAC grant you make outside the chart, and handing the chart over instead of running an agent is an operating arrangement between your team and the vendor. Revoking either one means withdrawing the grant or changing who runs the install, not touching a value.
Turning telemetry forwarding off takes effect the next time the chart is applied. Withdrawing cluster access, or handing operational control back to your own team, takes effect as soon as the grant or the handoff itself changes, independent of any redeploy.
Revoking cluster access stops future access through that grant. It does not remove data already read or copied while access was open. Turning off telemetry forwarding also leaves previously forwarded data with its recipient.
Every upgrade ships new image references, so sync a mirrored registry again before each upgrade. A skipped sync fails the same way as a missed image on the first install.
Frequently asked questions
Can you move from a vendor-held cluster to your own hardware later?
Yes. Infrastructure as code covers why the same charts move with you unchanged. Moving means installing that chart set on your own infrastructure and carrying your data across, which Backup and disaster recovery covers.
See also
- Deployment topologies for what deploys and how each backend service is sized.
- Prerequisites for the external endpoints and credentials an install needs ready.
- Install the Helm charts for the install command itself.