# Installation process
Source: https://docs.settlemint.com/docs/architecture/self-hosting/installation-process
Overview of the SettleMint-managed installation process for self-hosted
DALP deployments. Covers pre-installation verification, deployment phases,
and post-installation handoff.
DALP self-hosting is installed as a managed deployment. Your team provides the target Kubernetes or OpenShift environment, the infrastructure prerequisites, environment values, and the agreed change window. SettleMint installs the platform charts, wires the blockchain-specific configuration, verifies the deployment, and hands over the endpoint and operating details.
The post-Kubernetes setup stage is performed by SettleMint because it connects deployed services to the target
blockchain network, contract addresses, and indexing configuration.
## Installation model [#installation-model]
The installation has four phases. Each phase has a clear owner so infrastructure teams know what to prepare and what SettleMint validates before handoff.
| Phase | Primary owner | Exit condition |
| ----------------------------- | ------------- | ------------------------------------------------------------------------------ |
| Pre-installation verification | Joint | Cluster access, managed services, DNS, TLS, storage, and approvals are ready |
| Platform deployment | SettleMint | DALP charts and enabled support services are running in the target environment |
| Post-deployment setup | SettleMint | Contract, network, endpoint, and indexing references are configured |
| Verification and handoff | Joint | Routes, authentication, observability, backups, and access details are checked |
## What SettleMint delivers [#what-settlemint-delivers]
| Deliverable | Description |
| -------------------------- | ---------------------------------------------------------------- |
| Helm chart package | Versioned charts for DALP, support, and observability components |
| Image registry credentials | Harbor credentials for harbor.settlemint.com |
| Baseline configuration | Deployment-ready defaults aligned with your environment |
| Deployment plan | Verified install sequence and validation checklist |
## What clients provide [#what-clients-provide]
| Requirement | Description |
| ------------------------------ | ------------------------------------------------------------------------------------------- |
| Kubernetes or OpenShift access | kubeconfig with permissions to install charts, CRDs, and namespace resources |
| Prerequisites | All items from the [prerequisites](/docs/architecture/self-hosting/prerequisites) checklist |
| Environment values | Domains, TLS material, datastore settings, object storage settings, and service credentials |
| Change window | Time window for deployment, verification, and rollback decisions |
| Post-setup access | Network access for contract deployment, chain indexing, and endpoint validation |
## Installation stages [#installation-stages]
### Stage 1: Pre-installation verification [#stage-1-pre-installation-verification]
Purpose: confirm that infrastructure, services, and network access match the prerequisites.
* Validate cluster access, namespaces, and storage classes
* Verify managed service connectivity (PostgreSQL, Redis, object storage)
* Confirm DNS and TLS readiness for enabled routes
* Review CRD approvals and security constraints (SCCs on OpenShift)
### Stage 2: Platform deployment [#stage-2-platform-deployment]
Purpose: install the Helm charts and bring all DALP services online.
* Install operators and supporting charts in the required order
* Deploy DALP services and networking (Ingress on Kubernetes, Routes on OpenShift)
* Apply default labels, annotations, and security settings
Result: all core services are running and reachable inside the cluster.
### Chart groups installed during platform deployment [#chart-groups-installed-during-platform-deployment]
The deployment uses separate chart groups so platform, dependency, and observability concerns can be enabled and upgraded deliberately.
| Chart group | What it installs |
| ------------- | ------------------------------------------------------------------------------------------------------------------- |
| DALP | Asset Console, Unified API, workflow engine, indexer, eRPC, Blockscout, documentation, and Durable Execution Engine |
| Support | Ingress or gateway components, PostgreSQL, Redis, secret reloader, object storage, and backup tooling |
| Observability | Metrics, logs, traces, dashboards, node metrics, and Kubernetes state metrics |
Environment wrapper charts, such as the local and staging charts, compose these groups into one installable release. A wrapper chart can also include an EVM network chart, such as a Besu stack, when the environment needs an in-cluster chain instead of an external network.
SettleMint confirms the final enabled chart set during environment planning. Each chart group has its own enabled flag. Managed PostgreSQL, Redis, object storage, observability, or chain infrastructure can replace the bundled chart where your environment provides that service.
## What can replace bundled services [#what-can-replace-bundled-services]
DALP charts can deploy support services for self-hosted environments. The same charts can connect to managed services supplied by your infrastructure team. Before deployment starts, confirm credentials, network policy, and backup ownership.
| Area | Bundled option in the charts | Client-managed alternative |
| -------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Datastores | PostgreSQL and Redis support charts | Managed PostgreSQL and Redis endpoints |
| Object storage | In-cluster object storage through the support charts | AWS S3, Azure Blob Storage, Google Cloud Storage, or S3-compatible object storage supplied by the environment |
| Ingress | Ingress or gateway components | Existing ingress controller, OpenShift Routes, or gateway |
| Backups | Backup tooling enabled through the support charts | Client backup platform and restore procedures |
| Chain access | Optional in-cluster EVM network chart for test use | External EVM network and RPC endpoints |
When your environment provides one of these services, SettleMint validates the connection details and deploys DALP with the bundled chart disabled for that service.
### Stage 3: Post-deployment setup (SettleMint-owned) [#stage-3-post-deployment-setup-settlemint-owned]
Purpose: connect on-chain assets, validate chain indexing, and finalize application configuration.
* Deploy smart contracts and record addresses
* Validate DIDX connectivity and sync health
* Update application configuration with contract and endpoint references
Result: the platform is fully wired to the blockchain network and ready for use.
### Stage 4: Verification and handoff [#stage-4-verification-and-handoff]
Purpose: confirm health, security, and operational readiness before client handoff.
* Validate ingress routes, TLS, and authentication
* Confirm dashboards and alerts are producing data
* Verify backup configuration and restore readiness
Result: you receive a working platform with verified endpoints and access details.
## If the client must run the platform deployment [#if-the-client-must-run-the-platform-deployment]
SettleMint can support client-led deployment in exceptional cases, but the post-deployment setup remains SettleMint-owned.
### Required tooling and access [#required-tooling-and-access]
* Helm version 3.x and kubectl (or oc CLI on OpenShift) configured for the target cluster
* Ability to install CRDs, IngressClass (or Routes on OpenShift), and namespace-scoped resources
* Harbor credentials and egress access to harbor.settlemint.com
* Access to managed service credentials and TLS certificates
### Required inputs [#required-inputs]
* Final FQDN list for enabled routes
* TLS certificates and private keys for each route
* PostgreSQL, Redis, and object storage connection details
* Approval for any operator CRDs required by the charts
## Handoff package [#handoff-package]
You receive the following after installation:
* Application and API endpoint inventory
* Admin credentials for enabled services
* Deployed contract addresses and network references
* DIDX endpoint information and sync status
* Configuration reference for future upgrades
## Post-installation support [#post-installation-support]
Support response and incident handling depend on your contracted SLA tier. SettleMint provides upgrade guidance and remediation for DALP components within the agreed support scope.
## Timeline expectations [#timeline-expectations]
| Phase | Typical duration |
| ----------------------------- | -------------------- |
| Pre-installation verification | 1 to 2 business days |
| Platform deployment | 1 to 2 business days |
| Post-deployment setup | 4 to 8 hours |
| Verification and handoff | 2 to 4 hours |
| Total | 2 to 4 business days |
Timelines assume prerequisites are complete. Gaps in infrastructure or approvals extend the schedule.
## See also [#see-also]
* [Prerequisites](/docs/architecture/self-hosting/prerequisites) for infrastructure requirements
* [High availability](/docs/architecture/self-hosting/high-availability) for HA and DR configurations
* [DALP Execution Engine](/docs/architecture/components/infrastructure/execution-engine) for component architecture