Helm Deployment

The Helm deployment path lets you install, upgrade, and manage the Institutional Vault on any Kubernetes cluster using standard Helm tooling. Blockdaemon provides Docker images and a versioned Helm chart; you bring the cluster, the cloud identity configuration, and the secrets.

When to use this path

What the chart deploys

A single Helm release installs one Institutional Vault instance. The chart manages the following workloads:

Each component is gated by an enabled flag in the chart values. Production deployments should use a managed database (RDS, Azure Database for PostgreSQL, Cloud SQL) rather than the in-chart postgres option.

The secret model

Secrets are never stored in Helm values or Kubernetes Secrets. The flow is:

1. You populate your cloud secret store (Azure Key Vault, AWS Secrets Manager, or GCP Secret Manager) with the secrets the wallet needs at runtime.
2. Config templates in the chart reference secrets with {{ azureSecret "..." }}, {{ awsSecret "..." }}, or {{ gcpSecret "..." }} placeholders.
3. At pod startup, the configmap-init init container resolves those references using the pod's cloud identity and writes the final config files inside the pod.

This means no secret values appear in Helm releases, ConfigMaps, or version control.

Deployment model

---
config:
  themeVariables:
    fontSize: 16px
    fontFamily: arial
---
flowchart TB
  subgraph cluster["Kubernetes cluster - AKS / EKS / GKE"]
    subgraph ns["Namespace: env-instance"]
      frontend[Wallet Frontend]
      wallet[Wallet API]
      evmTracker[EVM Tracker]
      nats[NATS Message Broker]
      pn0[Policy Node 0]
      pn1[Policy Node 1]
      pn2[Policy Node 2]
    end
  end

  secrets["Cloud secret store<br/> (Key Vault / Secrets Manager)"]

  frontend -->|"HTTP"| wallet
  wallet -->|"NATS TCP 4222"| nats
  evmTracker -->|"TCP 4222"| nats
  nats -->|"NATS TCP 4222 mTLS"| pn0
  nats -->|"NATS TCP 4222 mTLS"| pn1
  nats -->|"NATS TCP 4222 mTLS"| pn2
  wallet -.->|"cloud identity<br/>WI / IRSA"| secrets
  pn0 -.->|"cloud identity"| secrets
  pn1 -.->|"cloud identity"| secrets
  pn2 -.->|"cloud identity"| secrets

Setup overview

The installation has two phases.

Phase 1: Cluster prerequisites (once per cluster)

Install the cluster-scoped operators and the mpc-cluster-prereqs chart. These are shared across all Institutional Vault instances in the cluster and are installed once regardless of how many instances you run.

• Cluster Prerequisites

Phase 2: Per-instance installation (once per instance)

Provision the cloud identity and secrets for the instance, then install the mpc chart. Repeat this phase for each additional instance (environment, namespace).

• Azure AKS
• AWS EKS
• GCP GKE

Also review Network Requirements before opening firewall or NetworkPolicy rules.

Upgrading

See Upgrading for the helm upgrade workflow, automatic DB migration behaviour, and rollback instructions.

Chart and image distribution

Blockdaemon provides:

• The mpc Helm chart from the OCI registry at oci://iv.sepior.net/charts/mpc (contact your Blockdaemon account team for registry credentials).
• Docker images for each component. Mirror these to your own container registry (ACR, ECR, or Artifact Registry) before installing, then set global.imageRegistry to your registry prefix.

Values reference

The chart ships a fully-commented values.yaml and a JSON Schema (values.schema.json) that Helm validates against on every install and upgrade. Start from the cloud-specific example file for your platform and override only the fields you need to change.