# Overview

Source: https://docs.settlemint.com/docs/architecture/self-hosting
Deploy the Digital Asset Lifecycle Platform in your own Kubernetes or OpenShift
infrastructure. Covers operating boundaries, required platform services,
installation planning, and high availability choices for enterprise deployments.




## Overview [#overview]

Self-hosted DALP deployments place the Digital Asset Lifecycle Platform inside infrastructure controlled by your organization. DALP is packaged as Helm charts and container images for Kubernetes or OpenShift, with SettleMint support for installation and application-level configuration. Your platform team owns the cluster, data services, ingress, DNS, TLS, registry access, secrets, monitoring, backups, and production runbooks.

<Callout type="info">
  Self-hosting requires experienced Kubernetes or OpenShift operators. Organizations without dedicated platform
  engineering teams should consider SettleMint's managed deployment options.
</Callout>

## Controlled-environment deployment model [#controlled-environment-deployment-model]

DALP can run in a bank-controlled Kubernetes or OpenShift environment when the bank provides the cluster, registry access, data services, DNS, TLS, storage, network paths, and approved secret-management inputs. The DALP application chart packages the Asset Console, API, workflow service, indexer, chain gateway, and block explorer as containerized workloads. Optional support and observability charts can run in the same controlled environment when the bank does not use approved managed equivalents.

The DALP application runtime does not require a shared public SaaS control plane. Core application components are not cloud-only. Cloud or externally managed services appear only when the deployment enables them or when the bank chooses an approved managed service instead of an in-cluster equivalent. Treat each approved external endpoint as a deployment dependency with its own network, credential, residency, logging, and incident-response controls.

| Dependency                                                            | When it is used                                                                                                                  | Security implication                                                                                                                         |
| --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| EVM RPC upstreams or custody and signing providers                    | When the environment connects to an external network or external signer instead of an in-cluster network and local signing model | Restrict egress, isolate credentials, and review provider logs, key-control model, residency, and incident process before production         |
| PostgreSQL, Redis, object storage, backup, or observability services  | When the bank uses managed data or monitoring services instead of bundled or in-cluster services                                 | Treat the service as a data processor. Review encryption, network path, retention, backup access, telemetry export, and administrator access |
| SMTP, identity providers, DNS, TLS issuance, and container registries | When the deployment integrates with the bank's mail, identity, certificate, DNS, or image-distribution controls                  | Approve domains and certificates, pin registry access, rotate credentials, and audit authentication and image-pull activity                  |

For OpenShift, DALP charts include OpenShift-specific route and security-context values. Workloads run with non-root settings, privilege escalation disabled, dropped Linux capabilities, RuntimeDefault seccomp where configured, and OpenShift-assigned UIDs where the restricted Security Context Constraints profile requires dynamic IDs. SettleMint-built runtime containers use hardened minimal base images: compiled services run from distroless nonroot images, and web runtimes and migration tooling use pinned Alpine Bun images with a non-root application user. Third-party support images, such as block explorer and observability chart images, must pass the bank's registry admission, image-scanning, and patch-management controls before deployment.

Runtime credentials are injected at startup rather than baked into images or static configuration. DALP supports HashiCorp Vault as a secret-manager provider using the Vault address, token, mount path, and secret prefix configured for the environment. The Helm chart can also map environment variables to enterprise secret-store paths through the Conjur and summon integration before the application process starts. The bank owns Vault policy, token lifecycle, namespace access, audit logging, and rotation; DALP consumes only the runtime values approved for the deployment.

## One-view topology [#one-view-topology]

The deployment boundary is the bank-controlled Kubernetes or OpenShift estate. DALP application workloads run inside that boundary. The platform services, observability stack, ingress controls, and approved external endpoints sit around the workloads and must be reviewed as production dependencies before go-live.

<Mermaid
  chart="`flowchart TB
  users[&#x22;Operators and integrators&#x22;] --> ingress[&#x22;Ingress, DNS, and TLS&#x22;]

  subgraph boundary[&#x22;Bank-controlled infrastructure boundary&#x22;]
    ingress --> apps

    subgraph cluster[&#x22;Kubernetes or OpenShift cluster&#x22;]
      subgraph apps[&#x22;DALP application workloads&#x22;]
        console[&#x22;Asset Console&#x22;]
        api[&#x22;Unified API&#x22;]
        workflow[&#x22;Workflow service&#x22;]
        indexer[&#x22;Chain indexer&#x22;]
        gateway[&#x22;Chain Gateway&#x22;]
        explorer[&#x22;Block explorer&#x22;]
      end

      subgraph platform[&#x22;Platform services&#x22;]
        secrets[&#x22;Secret store integration&#x22;]
        config[&#x22;Config and Helm values&#x22;]
        telemetry[&#x22;Telemetry agents&#x22;]
      end
    end

    subgraph data[&#x22;Approved data and observability services&#x22;]
      postgres[&#x22;PostgreSQL&#x22;]
      redis[&#x22;Redis&#x22;]
      storage[&#x22;Object storage and backups&#x22;]
      obs[&#x22;Metrics, logs, traces, and dashboards&#x22;]
    end

    apps --> postgres
    apps --> redis
    apps --> storage
    apps --> secrets
    apps --> telemetry
    telemetry --> obs
    config --> apps
  end

  apps --> external[&#x22;Approved EVM RPC, custody, SMTP, identity, and registry endpoints&#x22;]
`"
/>

Read the diagram from left to right: traffic enters through the bank's ingress controls, reaches DALP workloads in the cluster, then uses approved platform, data, observability, and external endpoints. External endpoints are optional dependencies, not a shared DALP control plane.

## Planning decisions [#planning-decisions]

SettleMint delivers a tested, versioned Helm chart package. Your team provides the infrastructure and prerequisites. SettleMint engineers perform the initial installation and post-deployment configuration, including smart contract deployment and indexer validation.

Self-hosting has three decisions that shape the rest of the deployment:

| Decision             | Default path                                                                                             | When to choose another path                                                                                                                                                         |
| -------------------- | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Runtime platform     | Kubernetes or OpenShift across multiple availability zones                                               | Use OpenShift when your platform team standardizes on Routes, restricted security context constraints, and OpenShift operations.                                                    |
| Data services        | Managed PostgreSQL, Redis, object storage, backup, and observability services in hypercloud environments | Use in-cluster PostgreSQL, Redis, RustFS, or observability only when managed services are unavailable or not approved. Object storage uses cloud-provider or S3-compatible storage. |
| Availability pattern | Cloud-native multi-zone deployment                                                                       | Use hot-warm, hot-cold, or hot-hot when recovery targets, geography, or consortium operations require a different operating model.                                                  |

The platform team should make these decisions before installation planning. These choices determine the prerequisites, enabled chart groups, handoff checks, and recovery pattern that operators must test before production.

## Documentation sections [#documentation-sections]

| Section                                                                          | Purpose                                                                                  |
| -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| [Prerequisites](/docs/architecture/self-hosting/prerequisites)                   | Confirm cluster, network, data service, secret, storage, registry, DNS, and TLS inputs   |
| [Installation process](/docs/architecture/self-hosting/installation-process)     | Understand installation phases, enabled chart groups, validation checks, and handoff     |
| [OpenShift installation](/docs/architecture/self-hosting/openshift-installation) | Check OpenShift route, security context, dynamic UID, and restricted workload behavior   |
| [High availability](/docs/architecture/self-hosting/high-availability)           | Choose and test the HA or disaster recovery pattern, including RTO, RPO, and runbooks    |
| [Hot-warm topology](/docs/architecture/self-hosting/high-availability/hot-warm)  | Review standby-region operations when the active environment fails over to a warm region |

## Responsibility matrix [#responsibility-matrix]

| Area                 | SettleMint                                     | Client                         |
| -------------------- | ---------------------------------------------- | ------------------------------ |
| Helm charts          | Development, testing, versioning               | Deployment, configuration      |
| Container images     | Building, security scanning                    | Registry access, pulling       |
| Installation         | Initial deployment, verification               | Infrastructure provisioning    |
| Smart contracts      | Deployment, verification                       | Network access                 |
| Chain indexer        | Deployment, validation, readiness checks       | Runtime hosting and operations |
| Chain gateway        | Configuration guidance and chart defaults      | RPC upstreams, exposure policy |
| Kubernetes/OpenShift | Architecture guidance                          | Provisioning, maintenance      |
| Managed services     | Configuration recommendations                  | Provisioning, credentials      |
| Monitoring           | Dashboard templates, alert rules               | Grafana hosting, alert routing |
| Upgrades             | Chart updates, migration guides                | Execution, testing             |
| Incident response    | Application-level response (dependent on SLAs) | Infrastructure-level response  |

SettleMint incident response is dependent on the contracted SLA tier.

## Getting started [#getting-started]

1. Review the [self-hosting prerequisites](/docs/architecture/self-hosting/prerequisites) to confirm cluster, network, data service, storage, registry, DNS, TLS, and secret-management inputs.
2. Choose the [high availability pattern](/docs/architecture/self-hosting/high-availability) that matches your recovery targets and operating geography.
3. Decide whether PostgreSQL, Redis, object storage, backup, and observability run as approved managed services or in-cluster equivalents.
4. Prepare DNS entries, TLS certificates, image-pull access, and approved secret-store paths before scheduling installation with SettleMint.

<Callout type="warn">
  Do not proceed with infrastructure provisioning until you have reviewed the complete prerequisites checklist. Missing
  requirements delay installation and may require re-provisioning.
</Callout>

## See also [#see-also]

* [Self-hosting prerequisites](/docs/architecture/self-hosting/prerequisites) for the required infrastructure, network, data service, and secret inputs
* [Installation process](/docs/architecture/self-hosting/installation-process) for the installation phases, validation checks, and handoff sequence
* [OpenShift installation](/docs/architecture/self-hosting/openshift-installation) for OpenShift route and security-context planning
* [High availability](/docs/architecture/self-hosting/high-availability) for recovery topology decisions and production readiness checks
* [Chain Gateway](/docs/architecture/components/infrastructure/chain-gateway) for EVM RPC routing and failover boundaries
* [Observability](/docs/architecture/operability/observability) for metrics, logs, traces, dashboards, and alert routing
* [Platform overview](/docs/architecture/start-here) for the broader DALP system design