Deploy where no one else can reach
DALP deploys its contracts inside an air-gapped cluster, signing with a key only the customer holds, pulling images from a mirrored registry, and trusting object storage behind a private CA.
The most demanding deployments run where the vendor cannot reach: no inbound access, mirrored registries, private certificate authorities. DALP 3.1 deploys its smart contracts inside that boundary, signing with a key only you hold.
Contracts land inside your boundary
An operator-gated Helm Job deploys the DALP contracts from inside the customer's own cluster. The signing key is fetched from the customer's Conjur secrets manager at runtime, so the vendor never sees it. The Job requests no Kubernetes permissions, and a re-run picks up exactly where the last deployment stopped.
- Deployer key
- Customer-held
- Cluster permissions
- Zero
- Re-runs
- Journal-safe
- Images
- From your mirror
For an architect running a restricted or air-gapped cluster, the hardest question about any platform is the first one: how does it get in? A deployment that assumes outbound internet, a vendor-run deploy step, or a shared signing key fails the security review before anything runs. This release removes each of those assumptions, following the reference architecture for hardened OpenShift environments.
Both capabilities on this page shipped to the 3.0 patch line first, so hardened deployments did not wait for 3.1. They are part of the supported surface from 3.1 onward.
Your cluster deploys, your key signs
Contract deployment ships as a Helm Job, off by default and enabled by the operator through a single chart value. When enabled, the Job runs inside the customer's cluster and deploys the DALP contract suite to the target chain from there. The deployer key never leaves the customer's control: the Job fetches it from the customer's Conjur secrets manager at runtime. The vendor never holds it, never sees it, and cannot deploy without it.
Set the contract-deployment flag in your Helm values. Nothing deploys until an operator turns it on.
Before any transaction is sent, a preflight check inside the image validates the deployer account, so a misconfigured key fails fast instead of half-deploying.
The Job deploys the contract suite and records every completed step in a deployment journal on a retained volume.
A re-run reads the journal and continues from the last completed step. An interrupted deployment resumes; a finished one is a no-op.
The Job's service account carries zero Kubernetes permissions. It reads its secret, talks to the chain, and writes its journal. A cluster security review has nothing to grant and nothing to scope down.
Nothing has to leave the boundary
A hardened cluster controls what comes in as tightly as what goes out. The chart supports both directions.
The global image registry value points every image, including the contract deployer, at your own air-gapped mirror. No pull crosses the boundary.
The chart packages your CA certificate as a secret and documents the wiring that lets the Platform API and the workflow runtime trust S3-compatible storage signed by your private certificate authority. Once wired, uploads, exports, and durable state all work against internal storage; the OpenShift install profile shows the exact values.
Support inside the boundary works the same way. When something needs diagnosis, an administrator exports a redacted debug bundle instead of granting shell access; see debug information export.
Compatibility
Everything on this page is opt-in. The contract-deployment Job is disabled by default, the registry mirror and CA secret are chart values you set only if you need them, and a deployment that uses none of them is unchanged.
Install on OpenShift → · Self-hosting prerequisites → · Security architecture →
Organization custody
Each organization on a DALP deployment now configures its own custody provider, tests the credentials before adopting them, and rotates them from the Console, with secrets masked and never returned.
Platform operations
Archive and restore organizations with an audit trail, reset a user's onboarding, invite people with their on-chain roles pre-assigned, and tighten KYC search and uniqueness.