Skip to main content
This page provides a complete, annotated values.yaml reference optimized for production deployments. Copy it, adapt the placeholders to your environment, and deploy.
This is a reference configuration. You must replace all placeholder values (marked with {...}) with your actual infrastructure details before deploying.

How to use


  1. Copy the full configuration below into a file called values-production.yaml
  2. Replace all {...} placeholders with your actual values
  3. Review each section and adjust resource limits for your expected workload
  4. Deploy:

Full production values


The ACCOUNT_TYPE_VALIDATION and TRANSACTION_ROUTE_VALIDATION environment variables have been deprecated and replaced by the Ledger Settings API. Use PATCH /v1/organizations/{org_id}/ledgers/{ledger_id}/settings to configure accounting validation per ledger.
Do not add external, extraEnvs, exporters, or opentelemetry-collector under otel-collector-lerian. The chart schema is strict and helm install/helm upgrade fails with additional properties … not allowed. Collector routing (processors, exporters, API keys) is configured in the collector’s own chart, not here — see Configuring observability.
The chart no longer ships a Grafana stack — those templates were removed in chart v5.0.0. A grafana: block in your values file renders nothing.

Key decisions explained


Why Ledger instead of Onboarding + Transaction?

The unified ledger service is the recommended approach for all new installations. It combines both modules into a single deployment, reducing operational overhead:
  • Fewer pods to manage and monitor
  • Simplified configuration (single configmap/secret)
  • Single ingress endpoint
  • Better resource utilization
  • Will become the only option in future releases

Why external databases?

Production deployments should use managed database services for:
  • Automated backups and point-in-time recovery
  • High availability with automatic failover
  • Monitoring and alerting built-in
  • Scaling without application downtime
  • Security patching managed by the provider
Recommended managed services:

Why use Kubernetes Secrets instead of inline passwords?

Inline passwords in values.yaml are visible in Helm release history and may be committed to version control. Using useExistingSecret: true with pre-created Kubernetes Secrets:
  • Keeps credentials out of Helm values
  • Allows rotation without Helm upgrade
  • Integrates with secret management tools (Vault, External Secrets Operator, Sealed Secrets)

Pod anti-affinity

The podAntiAffinity rule distributes Ledger pods across different nodes, so a single node failure doesn’t bring down the entire service.

Checklist before deploying


1

Create Kubernetes Secrets

Create all required secrets in the midaz namespace before running helm install:
  • midaz-ledger (database and message broker credentials)
  • midaz-crm (encryption keys and MongoDB password)
  • otel-api-key (if using Lerian telemetry)
2

Configure DNS

Point your domains to the ingress controller’s external IP:
  • {your-midaz-api-domain} → ingress IP
  • {your-crm-api-domain} → ingress IP
  • {your-grafana-domain} → ingress IP (only if you run Grafana independently — this chart renders none)
3

Provision TLS certificates

Either use cert-manager for automatic certificate provisioning or manually create TLS secrets for each domain.
4

Verify database connectivity

Ensure your Kubernetes cluster can reach all external databases. Test with:
5

Review resource limits

Adjust CPU and memory limits based on your expected transaction volume. The values in this reference are starting points for moderate workloads.
6

Deploy

7

Verify deployment