Prerequisites
Exhaustive checklist of infrastructure, services, and credentials required before SettleMint can begin DALP installation. Review and complete all requirements to prevent deployment delays.
Overview
This page documents everything required before SettleMint engineers can begin installation. Requirements are intentionally strict to prevent deployment failures and ensure reliable operation.
Do not schedule installation until all prerequisites are met. Missing requirements cause delays and may require re-provisioning of infrastructure.
Managed cloud baseline (required)
For AWS, Azure, and GCP deployments, DALP requires managed services for PostgreSQL, Redis, object storage, backups, and observability. In-cluster alternatives are only supported for non-hypercloud environments and require additional approvals.
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
- Security Context Constraints (restricted-v2 SCC) compatible
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 three 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)
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 |
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 |
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 |
|---|---|---|---|
| IPFS cluster | 1 | 1Gi | 1Gi |
| IPFS | 1 | 1Gi | 1Gi |
| Besu validators | 1 | 10Gi | 10Gi |
| Besu RPC nodes | 2 | 10Gi | 20Gi |
| Base total | 32Gi |
We typically run four validators in production. With four validators, the base total becomes 62Gi. Scale this base linearly as validator counts change.
Backup and retention sizing example
Example with chart defaults (one validator):
32Gi x 59 (retention multiplier) x 0.4 (compression) x 1.2 (headroom) = 906Gi, rounded to 1Ti.
Each RustFS replica gets a 1Ti PVC. With two replicas in distributed mode, total storage is 2Ti with about 1Ti usable capacity after replication.
Example with four validators (typical production):
62Gi x 59 (retention multiplier) x 0.4 (compression) x 1.2 (headroom) = 1,756Gi, rounded to 2Ti.
Each RustFS replica gets a 2Ti PVC. 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 S3-compatible service | RustFS | Managed: set support.rustfs.enabled: false, configure global.backup.s3, and update dApp object storage env values. Self-hosted: set support.rustfs.enabled: true 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 |
| IPFS | ipfs.yourcompany.com | External IPFS 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 the restricted-v2 Security Context Constraint. 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.
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-v2 SCC 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
- Three 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
Complete guide to deploying the Digital Asset Lifecycle Platform in your own Kubernetes or OpenShift infrastructure. Covers prerequisites, installation process, and high availability configurations 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.