Hosting and access
Where a DALP Instance runs and how involved the vendor stays once it is running are separate decisions, chosen at install and revisited independently after.
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 runs in a Kubernetes environment you select. Choose who operates that environment and which access they need: cluster administration, outbound telemetry, or a chart and image handoff. These choices are independent of who owns the hardware or cloud account.
Four rungs of vendor access, most to least: operator access, telemetry forwarding only, a handed-over chart, and a mirrored registry that removes the need to pull images from the vendor 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 below runs from direct cluster access down to none. That same choice decides who carries the day-to-day operating load.
A DALP Instance on infrastructure you hold typically stays under your team's day-to-day operation, with the vendor supporting the install rather than running it. On infrastructure the vendor holds, the vendor typically runs it instead. Either pairing is the default, not a rule the infrastructure choice enforces. The access ladder below sets the actual operating split for the environment in front of you, and that holds whatever infrastructure it sits on.
A DALP release defines an application boundary. Dedicated hardware, cloud accounts, cluster control planes, and namespace isolation depend on the hosting arrangement; the chart alone does not guarantee them.
The access ladder
Hosting decides whose account runs the cluster. A separate decision decides how involved the vendor stays once it is running, and that single choice covers both how much the vendor can see and who does the operating work. It has four rungs, most involvement to least. Each one trades vendor involvement for work your own team takes on, and each is named below with what it costs you and when it fits.
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, and broad cluster administration can expose application data and database credentials. 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 healthPlatform Health lets a platform admin see in one glance whether the platform is healthy right now, instead of checking a dozen dashboards.Read the concept without ever reaching your cluster directly. Your own team still runs every install and upgrade at this rung; the vendor's reach stops at the telemetry it receives. Turning any of this on opens no inbound path: the cluster only ever calls out, and the collector on the other end never reaches back in to pull anything. Choose this rung when you want the vendor watching for trouble without touching the cluster. Take it only if you can commit to running that collector endpoint yourself: that means standing it up, keeping it reachable, and keeping its credential current.
Operating it:
- Redaction. Logs pass through a reviewed attribute allowlist and text redaction before they leave. Metrics and traces carry no redaction: a span or metric label your own code set leaves exactly as written. The redaction step runs in two passes. An allowlist keeps only reviewed attribute keys and drops everything else on a log record, then the body text itself is rewritten: credential-shaped text such as a password or token becomes a marker, and so does any email address. A forty-to-sixty-four character hex string is masked too, covering a wallet or contract address, a transaction hash, and a storage key on this platform.
- Authentication. Off by default. Set a username and the matching
observability-forwarding-basic-authSecret, and the connection carries it; leave the username unset and it forwards without one, deliberately. The chart does not create that optional Secret. A missing Secret can leave Alloy running with a blank password, while the receiver rejects its pushes. Check delivery errors as well as pod health. - Profiles. A separate switch on the same mode. The platform does not profile itself while running, so nothing is captured unless an operator asks for one deliberately. When they do, and profile forwarding is on, that profile leaves with the rest.
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 vendor's own registry. 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, granting nothing at all is a real, separate option. A shared override points every image at your registry. Include the TCP-check init container used by most components, the kubectl helper, and the Conjur authenticator. These utility images are easy to miss because no product component bears their names. Mirror all three. The TCP-check image is the one a default install always pulls, while the Conjur authenticator only appears on the OpenShift path, so a mirror built from the components you recognize is the mirror that strands the install. Sync every required image into your own registry first, then install entirely from your own copy: the install can pull those images without reaching the vendor registry. Review telemetry, RPC, custody, identity, and other configured endpoints separately before treating an environment as air-gapped. Choose it when even an outbound telemetry connection is unacceptable, or your network genuinely has none to offer. Take it only if you can commit to syncing the registry before every install, not only the first one.
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 actually stuck. Check the failing pod's image reference against what your registry actually 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.
Cluster access means data access
If your data is sensitive enough that vendor access is unacceptable, do not grant cluster access at all. Operate the platform yourself instead, and weigh that against the whole ladder before you commit to a rung.
Infrastructure as code
The Helm charts that stand up a DALP Instance are what you receive; there is no separate infrastructure-as-code layer behind them, no Terraform module, no Pulumi program, no 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
A single environment is not the normal shape. An upgrade typically reaches a lower environment before it reaches production: the same image moves from test to production unchanged, carrying one version through every environment it passes. Deployment topologies lists the chart bundle each environment runs; its deployment identity section covers how global.dalpInstance and global.deploymentEnvironment keep them 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 what that environment actually 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. Under the dalp-local or dalp-staging umbrella, reach it through the observability. prefix instead. 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.
The mirrored registry is not a one-time sync either. Every upgrade after the first ships new image references, so the registry needs a fresh sync before each install, not only before the first one. Skipping that step reproduces the same missed-image failure named above, this time on an upgrade instead of the initial 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.
Do all environments run the same chart, or a different one each?
Not quite either. dalp-local and dalp-staging are umbrella bundles that pin a chain, support, observability, and the dalp chart together for local and pre-production use; production has no umbrella of its own, you install the dalp chart directly against your own values overlay. OpenShift and the dedicated migration release line layer further overlays on top of that, orthogonal to environment. Deployment topologies lists exactly what each bundle changes.
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.
Topologies
See what the DALP Helm charts deploy and how each backend role scales: three Platform API roles, PgBouncer in front of PostgreSQL, and the environment bundles.
Security and compliance posture
The layered control model an operator reviews before accepting a DALP instance, from authentication and authorization through custody, compliance, and networks.