Prerequisites
Infrastructure, service, network, and credential checklist for teams preparing a self-hosted DALP installation on Kubernetes or OpenShift.
Overview
Before SettleMint can install DALP, your platform team must provide a production-ready Kubernetes or OpenShift environment. Prepare the approved managed services or in-cluster alternatives, network access, route names, certificates, and credentials before booking the deployment window. Complete inputs let installation move into verification instead of infrastructure repair.
Do not schedule installation until all prerequisites are met. Missing requirements cause delays and may require re-provisioning of infrastructure.
Choose the hosting model first
For AWS, Azure, and GCP deployments, DALP expects managed services for PostgreSQL, Redis, object storage, backups, and observability. In-cluster alternatives are the non-hypercloud path and require additional approval before installation planning.
This decision changes the rest of the checklist:
| Hosting model | Prepare before installation | Operational impact |
|---|---|---|
| Managed cloud baseline | Managed PostgreSQL, Redis, object storage, backup, and observability endpoints | The cloud provider owns the service control plane. DALP connects to approved endpoints. |
| Fully self-hosted | In-cluster PostgreSQL, Redis, RustFS, Velero, and observability resources | Your platform team owns capacity, patching, backups, restore testing, and monitoring for these services. |
If you cannot meet the managed service baseline, review the fully self-hosted section before proceeding.
Kubernetes or OpenShift cluster requirements
DALP supports deployment on both standard Kubernetes distributions and Red Hat OpenShift. The Helm charts automatically detect the platform and configure appropriate resources (Ingress on Kubernetes, Routes on OpenShift).
Cluster specifications
| Requirement | Minimum | Recommended | Notes |
|---|---|---|---|
| Kubernetes version | 1.27+ | 1.29+ | Standard CNI required |
| OpenShift version | 4.14+ | 4.16+ | OCP or OKD supported |
| Node count | 3 | 6+ | Multi-AZ distribution |
| Node size (compute) | 4 vCPU / 16 GB RAM | 8 vCPU / 32 GB RAM | Per node |
| Storage class | ReadWriteOnce | ReadWriteOnce | Default class defined |
Required platform capabilities
Kubernetes:
- RBAC enabled (namespace-scoped access is supported)
- LoadBalancer service type available for Traefik ingress controller
- StorageClass available for stateful workloads
- Metrics server available for HPA (SettleMint can install if not present)
- NetworkPolicy support available in the CNI
OpenShift:
- RBAC enabled (namespace-scoped access is supported)
- OpenShift Router available for Route-based ingress (Traefik is disabled)
- StorageClass available for stateful workloads
- Metrics server built-in
- NetworkPolicy support built-in
- Compatible with OpenShift restricted security context constraints
Multi-AZ distribution
Nodes must be distributed across a minimum of three availability zones. Single-AZ deployments are not supported for production workloads.
- Topology spread constraints rely on standard zone labels
- Pod disruption budgets assume cross-zone scheduling
Networking expectations
- Pod-to-pod communication must be allowed within the deployment namespace
- Service mesh injection is not supported (disable Istio or Linkerd sidecars)
- HTTPS only for external routes; HTTP is allowed only for redirects
Managed PostgreSQL (required in AWS, Azure, GCP)
Cloud provider options
| Provider | Service | Minimum sizing (baseline) | HA requirement |
|---|---|---|---|
| AWS | RDS PostgreSQL | 4 vCPU / 16 GB RAM (db.r6g.large) | Multi-AZ enabled |
| Azure | Azure Database for PostgreSQL Flexible Server | 4 vCPU / 16 GB RAM (Standard_D4ds_v5) | Zone-redundant HA |
| GCP | Cloud SQL for PostgreSQL | 4 vCPU / 16 GB RAM (db-custom-4-16384) | Regional HA |
Database configuration requirements
| Parameter | Requirement | Purpose |
|---|---|---|
| PostgreSQL version | version 17.x (tested on 17.5) | Feature compatibility |
| High availability | Multi-AZ or zone-redundant | Automatic failover |
| Storage | 100 GB minimum | With auto-growth enabled |
| PITR | Enabled, 7-day retention | Point-in-time recovery |
| SSL or TLS | Required | Encrypted connections |
max_connections | 300+ | Connection pool sizing |
shared_buffers | 25 percent of RAM | Memory allocation |
effective_cache_size | 75 percent of RAM | Query planner hint |
work_mem | 64 MB | Per-operation memory |
maintenance_work_mem | 512 MB | Maintenance operations |
| Required extensions | pg_trgm, btree_gist, pg_stat_statements, postgres_fdw | DALP services |
Version flexibility and exceptions: if your cloud provider does not offer PostgreSQL version 17.x, SettleMint can validate PostgreSQL version 16.x only after a formal compatibility review. The review must confirm required extensions, collation options, and performance targets, and it must be approved before scheduling installation.
Required databases
Create the required databases with dedicated owners before installation:
| Database | Owner | Notes |
|---|---|---|
| blockscout | blockscout | Required for the explorer |
| dapp | dapp | Required for the dapp |
Connection details to provide
- Host endpoint and port
- Database names and users
- Passwords for each database user
- SSL mode and CA bundle if using a private CA
Managed Redis (required in AWS, Azure, GCP)
Cloud provider options
| Provider | Service | Minimum sizing (baseline) | HA requirement |
|---|---|---|---|
| AWS | ElastiCache for Redis | 6 GB cache (r6g.large) | Multi-AZ enabled |
| Azure | Azure Cache for Redis | Premium tier, 6 GB cache | Zone redundancy |
| GCP | Memorystore for Redis | Standard tier, 6 GB cache | HA enabled |
Configuration requirements
| Parameter | Requirement | Purpose |
|---|---|---|
| Redis version | version 8.x (tested on 8.4.0) | Feature compatibility |
| Cluster mode | Disabled | Database index support |
| Memory | 6 GB minimum | Session and cache storage |
| High availability | Multi-AZ or zone redundancy | Automatic failover |
| TLS encryption | Required | Encrypted connections |
| AUTH password | Required | Access control |
| Persistence | AOF or snapshots enabled | Data durability |
Version flexibility and exceptions: if your cloud provider does not offer Redis version 8.x, SettleMint can validate Redis version 7.x only after a formal compatibility review. Cluster mode must remain disabled, TLS and AUTH must be supported, and the exception must be approved before scheduling installation.
Connection details to provide
- Primary endpoint and port
- AUTH password
- TLS CA bundle if using a private CA
Object storage (required)
DALP uses object storage for application files, document uploads, and backup targets. Self-hosted environments must provide a managed object storage service or enable the in-cluster RustFS chart. The current storage model is S3-compatible or cloud-provider object storage.
Managed cloud deployments usually disable the in-cluster RustFS chart and connect DALP to S3, Azure Blob Storage, Google Cloud Storage, or another approved managed object storage service. Use RustFS only when object storage must run inside the cluster.
Cloud provider options
| Provider | Service | Configuration baseline |
|---|---|---|
| AWS | S3 | Standard storage class, versioning enabled |
| Azure | Blob Storage | Hot tier, LRS minimum (GRS recommended) |
| GCP | Cloud Storage | Standard class, regional or multi-regional |
Provider configuration values
When you use a managed object storage service, share the selected provider value and credential mode during installation planning. DALP accepts these provider values for application object storage:
| Provider value | Service family | Typical credential inputs |
|---|---|---|
aws | AWS S3 | Region, optional access key pair, optional custom endpoint, and optional path-style setting |
gcp | Google Cloud Storage | Project ID, service account key file, or inline credentials |
azure | Azure Blob Storage | Storage account name with account key, connection string, or SAS token |
s3-compatible | S3-compatible object stores | Endpoint, public endpoint when needed, region, access key, and secret key |
Use s3-compatible for RustFS or another S3-compatible service. Use the filesystem provider only for development or local testing.
Bucket requirements
| Bucket purpose | Example name | When required | Configuration |
|---|---|---|---|
| Application storage | project-dalp-storage | Always | Versioning enabled |
| Velero backups | project-dalp-velero-backups | If using Velero | Versioning and lifecycle policies |
| PostgreSQL WAL and backups | project-dalp-postgres-backups | Only for self-hosted PostgreSQL | Versioning and lifecycle policies |
| Observability backups | project-dalp-observability | Only for self-hosted observability | Versioning and lifecycle policies |
Private application file access
DALP stores application files in object storage, but it does not expose private objects as public bucket URLs.
The application serves a private file only after the user is authenticated. The file key must also match a permitted resource scope.
Private file access follows these rules:
- KYC and compliance files use the
kyc/{participantId}/...key pattern and are available only through the authorized participant flow or to an administrator. - Organisation files use the
org/{orgId}/...key pattern and are available to users in that organisation or to an administrator. - Administrator files use the
admin/...key pattern and are available only to administrators. - Requests with missing keys, unsupported resource scopes, or path traversal segments are rejected.
- Returned file responses use no-cache headers so browsers and shared proxies do not retain private evidence files.
For production planning, keep private application storage behind DALP's authenticated application path. Do not grant direct public read access to the application storage bucket.
Lifecycle policies
- Transition to cold storage after 30 days
- Delete non-current versions after 90 days
- Keep versioning enabled for all buckets
IAM access requirements
| Provider | Recommended approach | Alternative |
|---|---|---|
| AWS EKS | IRSA (IAM Roles for Service Accounts) | Static credentials |
| Azure AKS | Workload Identity | Static credentials |
| GCP GKE | Workload Identity | Static credentials |
Stateful storage sizing and backup capacity
The chart defaults define baseline PVC sizes for stateful workloads. Production networks typically run four Besu validators and two Besu RPC nodes, which increases storage requirements.
Baseline PVC sizing (chart defaults)
| Component | Count | Size | Total |
|---|---|---|---|
| Besu validators | 1 | 10Gi | 10Gi |
| Besu RPC nodes | 2 | 10Gi | 20Gi |
| Base total | 30Gi |
Production environments commonly run four validators. With four validators, the base total becomes 60Gi. Scale this base linearly as validator counts change.
When you run RustFS inside the cluster, size RustFS separately for application objects and backup retention. Staging-style managed deployments set support.rustfs.enabled: false and use external object storage instead of RustFS PVCs.
Backup and retention sizing example
Example with chart defaults (one validator):
30Gi x 59 (retention multiplier) x 0.4 (compression) x 1.2 (headroom) = 850Gi, rounded to 1Ti.
Each RustFS replica gets a 1Ti PVC when RustFS is enabled. With two replicas in distributed mode, total storage is 2Ti with about 1Ti usable capacity after replication.
Example with four validators (typical production):
60Gi x 59 (retention multiplier) x 0.4 (compression) x 1.2 (headroom) = 1,700Gi, rounded to 2Ti.
Each RustFS replica gets a 2Ti PVC when RustFS is enabled. With two replicas in distributed mode, total storage is 4Ti with about 2Ti usable capacity after replication.
Managed observability (required in AWS, Azure, GCP)
DALP requires metrics, logs, traces, and alerting. For hypercloud deployments, this must be delivered by the cloud provider or an approved managed service.
| Provider | Managed service options | Minimum requirement |
|---|---|---|
| AWS | CloudWatch, Managed Prometheus, Managed Grafana | Metrics, logs, traces, alerting, retention |
| Azure | Azure Monitor, Managed Grafana | Metrics, logs, traces, alerting, retention |
| GCP | Cloud Monitoring and Logging | Metrics, logs, traces, alerting, retention |
Provide endpoints and credentials so SettleMint can route telemetry from DALP workloads. If you opt out of managed observability, the in-cluster observability stack must be installed instead.
Managed vs self-hosted configuration matrix
Use this matrix to align the managed baseline with the self-hosted fallback. SettleMint will confirm the final configuration during pre-installation verification.
| Capability | Managed baseline (hypercloud) | Self-hosted in cluster | Helm values and inputs |
|---|---|---|---|
| PostgreSQL | Managed database with PITR and HA | CloudNativePG cluster | Managed: set support.postgresql.mode: external or support.postgresql.enabled: false, and provide global.datastores.*.postgresql connection details or existingSecret. Self-hosted: set support.postgresql.mode: cloudnativepg and enable operators.cloudnativepg.enabled: true, then configure support.postgresql.cloudnativepg.backup if backups are required. |
| Redis | Managed Redis with TLS and AUTH | In-cluster Redis | Managed: set support.redis.enabled: false and provide global.datastores.*.redis connection details or existingSecret. Self-hosted: set support.redis.enabled: true. |
| Object storage | Managed object storage service | RustFS | Managed: set support.rustfs.enabled: false, configure the selected application object storage provider (aws, azure, gcp, or s3-compatible), and update dApp object storage environment values. Self-hosted: set support.rustfs.enabled: true, use the s3-compatible provider, and size PVCs for retention. |
| Observability | Managed metrics, logs, and traces | In-cluster observability stack | Managed: enable observability.endpoints.external.prometheus, observability.endpoints.external.loki, and observability.endpoints.external.otel and disable observability.grafana, observability.loki, observability.tempo, and observability.victoria-metrics-single. Self-hosted: keep internal endpoints enabled. |
| Backups | Provider-managed backups | Velero and CNPG backups | Managed: keep global.backup.enabled: false and disable operators.velero.enabled if not required. Self-hosted: enable operators.velero.enabled, global.backup.enabled, and CloudNativePG scheduled backups when needed. |
DNS configuration (required)
Default enabled routes
These routes are enabled in the standard chart configuration:
| Service | Example FQDN | Notes |
|---|---|---|
| dApp | app.yourcompany.com | Main application |
| Explorer (Blockscout) | explorer.yourcompany.com | Explorer UI and API on a single host |
| Traefik dashboard | traefik.yourcompany.com | Enabled by default; can be disabled |
Optional routes (enable only if needed)
| Service | Example FQDN | When to enable |
|---|---|---|
| RPC | rpc.yourcompany.com | External JSON-RPC access |
| Graph | graph.yourcompany.com | Direct subgraph access |
| Grafana | grafana.yourcompany.com | Only when using in-cluster observability |
| RustFS | rustfs.yourcompany.com | Only when using in-cluster object storage |
| RustFS console | rustfs-console.yourcompany.com | Only when console ingress is enabled |
When managed observability or managed object storage is used, SettleMint disables the Grafana and RustFS routes in the Helm values.
DNS requirements
- All domains must be delegated and resolvable before installation
- Private deployments must use internal DNS that resolves inside the cluster
- Wildcard certificates are supported, but individual certificates are preferred
TLS certificates (required)
DALP only supports HTTPS for external routes. Provide TLS for every enabled FQDN.
Options in order of preference
- Let's Encrypt via Traefik ACME solver
- Existing certificates provided as Kubernetes TLS secrets
- cert-manager with a private CA
Certificate requirements
- One certificate per domain or a wildcard certificate
- Full certificate chain included
- Private key in PKCS8 or PKCS1 format
- Minimum RSA 2048 or ECDSA P-256
Network and outbound access
Outbound access required
| Destination | Port | Purpose |
|---|---|---|
| harbor.settlemint.com | 443 | Container image pulls for all DALP components |
| Let's Encrypt ACME | 443 | Certificate issuance if ACME is used |
| SMTP provider | 587 or 465 | Transactional email if SMTP is enabled |
| Managed PostgreSQL endpoint | 5432 | Database connectivity |
| Managed Redis endpoint | 6379 | Cache and session connectivity |
| Object storage endpoint | 443 | Application storage and backups |
| Observability endpoints | 443 | External metrics, logs, and traces ingestion |
All container images are served through harbor.settlemint.com, which proxies upstream registries. Direct access to ghcr.io or docker.io is not required.
Internal networking
- Namespace-local pod traffic must be unrestricted
- NetworkPolicy resources must be allowed
- Service mesh sidecars are not supported
Ingress requirements
- LoadBalancer must be reachable from intended client networks
- Port 443 must be exposed; port 80 optional for redirects
Image registry access
SettleMint provides Harbor registry credentials for harbor.settlemint.com. No GHCR or Docker Hub credentials are required. If you mirror images into your own registry, provide access to that registry before installation.
Cluster-wide resources, CRDs, and operators
Some components require cluster-scoped CRDs and resources. Ensure your security team approves CRD installation before scheduling deployment.
CRDs required by the Helm charts
| Component | CRDs required | When required |
|---|---|---|
| Traefik | IngressRoute, Middleware, TLSOption, TLSStore | Always |
| CloudNativePG | clusters.postgresql.cnpg.io, poolers.postgresql.cnpg.io, scheduledbackups.postgresql.cnpg.io | Self-hosted PostgreSQL only |
| Velero | backups.velero.io, schedules.velero.io, restores.velero.io | Only if Velero is enabled |
| VolumeSnapshot | snapshot.storage.k8s.io resources | Only if snapshot backups enabled |
Traefik installs CRDs in the traefik.io and hub.traefik.io API groups. Velero installs CRDs in the velero.io API group, and CloudNativePG installs CRDs in the postgresql.cnpg.io API group.
Cluster-scoped resources
Kubernetes:
- IngressClass named dalp is created by the Traefik chart
- Traefik CRDs are installed cluster-wide
- CloudNativePG and Velero CRDs are cluster-wide even when RBAC is namespaced
OpenShift:
- Routes are used instead of Ingress (no IngressClass required)
- Traefik is disabled; OpenShift Router handles ingress
- CloudNativePG and Velero CRDs are cluster-wide even when RBAC is namespaced
- SecurityContextConstraints may require configuration for non-root workloads
Namespace-scoped RBAC
Operators are configured for namespace-scoped RBAC, so ClusterRoleBindings are not required unless you change chart defaults. CRD installation still requires cluster-level permissions. If your organization already operates these components, you can supply them instead as long as they watch the DALP namespace.
On OpenShift, the charts are compatible with restricted security context constraints. All containers run as non-root with arbitrary UID assignment.
Fully self-hosted (non-hypercloud) option
If managed services are not available, DALP can run PostgreSQL, Redis, object storage, observability, and backups inside the cluster. This requires additional capacity and operational ownership.
Additional requirements and impact
- CloudNativePG operator with PostgreSQL version 17.5 image
- Redis version 8.4.0 in-cluster deployment with persistence enabled
- RustFS for S3-compatible object storage with required buckets
- Observability stack (Grafana, Victoria Metrics, Loki, Tempo, Alloy)
- Velero operator for Kubernetes resource backups
- CRD approval for Traefik, CloudNativePG, Velero, and VolumeSnapshot CRDs
- Increased storage, monitoring, and backup verification workload
In this mode, service credentials for PostgreSQL, Redis, and RustFS are generated by the charts, and you do not provide external connection details.
Installation readiness check
Before scheduling installation, confirm that every enabled route, managed service endpoint, credential, certificate, and operator approval is available to the SettleMint installation team. The fastest path is to collect the values in one environment handoff pack:
| Input | Include |
|---|---|
| Cluster access | kubeconfig or OpenShift access, target namespace, storage class, and CRD approval status |
| Routes | Final FQDNs, DNS ownership, ingress exposure, and TLS certificate source |
| Data services | PostgreSQL, Redis, object storage, and observability endpoints with credential references |
| Backup services | PITR, snapshot, Velero, object storage retention, and restore-test owner |
| External dependencies | EVM RPC endpoints, SMTP provider, registry access, and private CA bundles when used |
Missing values should stay open in the checklist below. Do not treat placeholder hostnames or pending approvals as ready inputs.
Prerequisites checklist
Kubernetes or OpenShift infrastructure
- Multi-AZ Kubernetes (1.27+) or OpenShift (4.14+) cluster
- Minimum three nodes across three zones
- LoadBalancer service type available (Kubernetes) or OpenShift Router available (OpenShift)
- Metrics server installed or approved for installation (built-in on OpenShift)
- NetworkPolicy resources allowed
- Service mesh injection disabled
- OpenShift only: restricted security context constraint compatibility verified
Managed PostgreSQL
- PostgreSQL version 17.x
- Multi-AZ or zone-redundant HA enabled
- PITR enabled with seven-day retention
- Required extensions approved and available
- Required databases created with owners
- Connection details documented
- SSL or TLS enabled
Managed Redis
- Redis version 8.x with cluster mode disabled
- Multi-AZ or zone redundancy enabled
- TLS encryption enabled
- AUTH password configured
- Connection details documented
Object storage
- Application bucket created
- Backup buckets created if Velero or CNPG backups are enabled
- Versioning and lifecycle policies configured
- IAM or Workload Identity configured
Managed observability
- Metrics, logs, traces, and alerting service selected
- Retention and export requirements defined
- Endpoints and credentials ready for configuration
DNS and TLS
- Required FQDNs registered and resolvable
- TLS certificates provided for every enabled route
- ACME access verified if Let's Encrypt is used
Network
- Outbound access to harbor.settlemint.com confirmed
- Outbound access to managed services and observability endpoints confirmed
- Ingress LoadBalancer reachable from intended networks
CRD approval
- Traefik CRDs approved (Kubernetes only; not required on OpenShift)
- CloudNativePG CRDs approved if self-hosted PostgreSQL
- Velero CRDs approved if backups are enabled
- VolumeSnapshot CRDs approved if snapshot backups are enabled
See also
- Installation process for deployment phases
- High availability for HA and DR configurations
- DALP Execution Engine for component details
Overview
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.
Installation process
Overview of the SettleMint-managed installation process for self-hosted DALP deployments. Covers pre-installation verification, deployment phases, and post-installation handoff.