Self-hosting overview
Deploy the Digital Asset Lifecycle Platform in your own Kubernetes or OpenShift infrastructure. Covers operating responsibilities, required platform services, installation planning, and high availability choices for enterprise deployments.
Overview
Self-hosted DALP is the path for organizations that need the Digital Asset Lifecycle Platform inside their own Kubernetes or OpenShift estate.
Start here when your platform team owns the cluster and provides the surrounding infrastructure. The child pages cover prerequisites, the installation process, cluster-specific configuration, and high availability choices.
DALP ships as Helm charts and container images for Kubernetes or OpenShift. SettleMint supports installation and application-level configuration. Your platform team owns the cluster, data services, ingress, DNS, TLS, registry access, secrets, monitoring, backups, and runbooks.
Controlled-environment deployment model
DALP can run in a bank-controlled Kubernetes or OpenShift cluster when the bank provides registry access, data services, DNS, TLS, storage, network paths, and approved secret-store inputs. The DALP application chart packages the Console, Platform API, Workflow Engine, Ledger Index, Broadcast, and block explorer as containerized workloads. Optional support and monitoring charts can run in the same cluster when the bank does not use approved managed equivalents.
The DALP runtime does not require a shared public SaaS control plane. Core components are not cloud-only. Cloud or externally managed services appear only when the release enables them or when the bank selects an approved managed service over an in-cluster equivalent. Treat each approved external endpoint as a production dependency with its own network policy, credential controls, data residency, logging, and incident-response process.
| 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 route and security-context values specific to that platform. Workloads run non-root with privilege escalation disabled, Linux capabilities dropped, and RuntimeDefault seccomp where configured. OpenShift assigns UIDs dynamically where the restricted Security Context Constraints (SCC) profile requires it. SettleMint-built runtime containers use hardened minimal base images: compiled services run from distroless nonroot images; web runtimes and migration tooling use pinned Alpine Bun images with a non-root user. Third-party support images must clear the bank's registry admission, scanning, and patch controls before the release goes live.
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
DALP workloads run inside the bank-controlled Kubernetes or OpenShift estate. Supporting services, the observability stack, ingress controls, and approved external endpoints surround those workloads. Review each as a production dependency before go-live.
Traffic enters through the bank's ingress controls and reaches DALP workloads in the cluster. From there, the workloads use approved platform, data, observability, and external endpoints. External endpoints are optional dependencies, not a shared DALP control plane.
Deployment option fit
The self-hosting path fits when the organisation controls the target environment and SettleMint installs DALP into it. If the buyer does not want to operate Kubernetes, data services, backups, and observability, the managed or dedicated SettleMint service is the cleaner starting point.
| Option | Where DALP runs | Primary operator | Use when |
|---|---|---|---|
| Managed or dedicated SettleMint service | SettleMint-operated infrastructure | SettleMint | Your team wants DALP available without operating the Kubernetes, data, backup, and observability layer |
| Client cloud | Your approved public cloud Kubernetes estate | Your platform team, with SettleMint installation support | You need cloud residency, network, identity, and audit controls inside your cloud account |
| Private cloud or on-premises | Your Kubernetes or OpenShift estate in a data center | Your platform team, with SettleMint installation support | You need local infrastructure control, private connectivity, or an internal platform standard |
For client-cloud, private-cloud, and on-premises deployments, DALP remains a Helm-based application deployment. Your platform team owns the runtime estate. SettleMint owns the application package, installation support, post-deployment application configuration, and contracted application-level support.
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
| Section | Purpose |
|---|---|
| Prerequisites | Confirm cluster, network, data service, secret, storage, registry, DNS, and TLS inputs |
| Installation process | Understand installation phases, enabled chart groups, validation checks, and handoff |
| OpenShift installation | Check OpenShift route, security context, dynamic UID, and restricted workload behavior |
| High availability | Choose and test the HA or disaster recovery pattern, including RTO, RPO, and runbooks |
| Hot-warm topology | Review standby-region operations when the active environment fails over to a warm region |
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 |
| Broadcast | 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
- Review the self-hosting prerequisites to confirm cluster, network, data service, storage, registry, DNS, TLS, and secret-management inputs.
- Choose the high availability pattern that matches your recovery targets and operating geography.
- Decide whether PostgreSQL, Redis, object storage, backup, and observability run as approved managed services or in-cluster equivalents.
- Prepare DNS entries, TLS certificates, image-pull access, and approved secret-store paths before scheduling installation with SettleMint.
See also
- Self-hosting prerequisites for the required infrastructure, network, data service, and secret inputs
- Installation process for the installation phases, validation checks, and handoff sequence
- OpenShift installation for OpenShift route and security-context planning
- High availability for recovery topology decisions and production readiness checks
- Broadcast for EVM RPC routing and failover responsibilities
- Observability for metrics, logs, traces, dashboards, and alert routing
- Platform overview for the broader DALP system design
Failure Modes
Architecture-level failure-mode reference for DALP deployments, covering how platform components degrade, what operators can detect, and which recovery path applies when dependencies are unavailable.
Prerequisites - Self-hosting infrastructure requirements
Infrastructure, service, network, and credential checklist for teams preparing a self-hosted DALP installation on Kubernetes or OpenShift.