# Deploy where no one else can reach

Source: https://docs.settlemint.com/docs/changelog/dalp-3-1/air-gapped-deployment
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.**

<Spotlight
  eyebrow="Core Platform"
  title="Contracts land inside your boundary"
  aside="
  <FactList
    items={[
      { label: &#x22;Deployer key&#x22;, value: &#x22;Customer-held&#x22; },
      { label: &#x22;Cluster permissions&#x22;, value: &#x22;Zero&#x22; },
      { label: &#x22;Re-runs&#x22;, value: &#x22;Journal-safe&#x22; },
      { label: &#x22;Images&#x22;, value: &#x22;From your mirror&#x22; },
    ]}
  />
"
>
  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.
</Spotlight>

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 [#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.

<Steps>
  <Step title="Enable the Job">
    Set the contract-deployment flag in your Helm values. Nothing deploys until
    an operator turns it on.
  </Step>

  <Step title="Preflight validates the deployer">
    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.
  </Step>

  <Step title="Deploy, journaled">
    The Job deploys the contract suite and records every completed step in a
    deployment journal on a retained volume.
  </Step>

  <Step title="Re-run safely">
    A re-run reads the journal and continues from the last completed step. An
    interrupted deployment resumes; a finished one is a no-op.
  </Step>
</Steps>

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 [#nothing-has-to-leave-the-boundary]

A hardened cluster controls what comes in as tightly as what goes out. The chart supports both directions.

<LabelCards>
  <LabelCard label="Mirrored images">
    The global image registry value points every image, including the contract
    deployer, at your own air-gapped mirror. No pull crosses the boundary.
  </LabelCard>

  <LabelCard label="Object storage behind a private CA">
    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.
  </LabelCard>
</LabelCards>

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](/docs/api-reference/observability/debug-information-export).

## Compatibility [#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 →](/docs/architects/self-hosting/openshift-installation) · [Self-hosting prerequisites →](/docs/architects/self-hosting/prerequisites) · [Security architecture →](/docs/changelog/dalp-3-0/security)