Skip to main content
The Midaz Helm Chart has the following dependencies for the project’s default installation. All dependencies are enabled by default.
Production recommendation: By default, the Midaz chart bundles all dependencies. For production deployments, disable bundled dependencies and connect to managed services (AWS RDS, Amazon MQ, etc.) for better reliability, automated backups, and scaling.
The examples below show configurations for both Ledger (recommended) and Onboarding/Transaction (legacy) services. Choose the configuration that matches your deployment.

​
Valkey

  • Version: 2.4.7
  • Repository: Bitnami
  • Disable: valkey.enabled = false
Production: Use managed Redis/Valkey (ElastiCache, Memorystore) for high availability and automatic failover.
If you have an existing Valkey or Redis instance, you can disable this dependency and configure Midaz components to use your external instance.

​
PostgreSQL

  • Version: 16.3.0
  • Repository: Bitnami
  • Disable: postgresql.enabled = false
Production: Use managed PostgreSQL (RDS, CloudSQL, Azure Database) with automated backups and point-in-time recovery.
If you have an existing PostgreSQL instance, you can disable this dependency and configure Midaz components to use your external PostgreSQL.

​
External PostgreSQL Bootstrap Job

When using an external PostgreSQL (postgresql.enabled: false), this chart provides a one-shot bootstrap Job that:
  • Creates the onboarding and transaction databases if they do not exist.
  • Creates the midaz role/user if it does not exist and sets its password.
  • Grants database privileges and public schema permissions so midaz can create tables.
  • Waits for connectivity with a 300s timeout.
  • Is idempotent: if everything already exists, it prints and exits.
Configure in values.yaml: 
postgresql:
  enabled: false  # disable bundled PostgreSQL to use an external one

global:
  externalPostgresDefinitions:
    enabled: true
    connection:
      host: "your-postgres-host"
      port: "5432"
    postgresAdminLogin:
      # Option A: Use an existing Secret (recommended)
      # Required keys: DB_USER_ADMIN, DB_ADMIN_PASSWORD
      useExistingSecret:
        name: "my-postgres-admin-secret"
      # Option B: Inline credentials (not recommended in production)
      # username: "postgres"
      # password: "s3cret"
    midazCredentials:
      # Option A: Use an existing Secret (recommended)
      # Required key: DB_PASSWORD_MIDAZ
      useExistingSecret:
        name: "my-midaz-credentials-secret"
      # Option B: Inline password (not recommended in production)
      # password: "midaz-password"
All secrets must be in the same namespace as the release. The Job has a TTL of 300 seconds after completion.

​
MongoDB

  • Version: 15.4.5
  • Repository: Bitnami
  • Disable: mongodb.enabled = false
Production: Use managed MongoDB (Atlas, DocumentDB) for automatic scaling, backups, and encryption at rest.
If you have an existing MongoDB instance, you can disable this dependency and configure Midaz components to use your external MongoDB.

​
RabbitMQ

  • Version: 16.0.0
  • Repository: Groundhog2k
  • Disable: rabbitmq.enabled = false
Production: Use managed RabbitMQ (Amazon MQ, CloudAMQP) with HA configuration for message durability and automatic failover.
If you’re using an external RabbitMQ instance, you need to load the required load_definitions.json file. Without these queues, exchanges, and bindings in place, Midaz won’t work as expected. You can load the definitions in one of two ways: Automatically Enable the bootstrap job in your values.yaml to automatically apply the RabbitMQ definitions to your external instance: 
global:
  externalRabbitmqDefinitions:
    enabled: true
Manually If you prefer to apply the definitions yourself, use RabbitMQ’s HTTP API: 
curl -u {user}:{pass} -X POST -H "Content-Type: application/json" \
  -d @load_definitions.json http://{host}:{port}/api/definitions
The load_definitions.json file is located at: charts/midaz/files/rabbitmq/load_definitions.json.

​
External RabbitMQ Bootstrap Job

To streamline external RabbitMQ setup, this chart provides a one-shot Job that:
  • Applies the standard definitions file via the HTTP API.
  • Creates/updates the transaction and consumer users with custom passwords.
  • Waits for AMQP connectivity with a 300s timeout.
  • Is idempotent: if users already exist, it skips and exits.
Configure in values.yaml: 
rabbitmq:
  enabled: false  # disable bundled RabbitMQ to use an external one

global:
  externalRabbitmqDefinitions:
    enabled: true
    connection:
      protocol: "http"          # http or https
      host: "your-rabbitmq-host"
      port: "15672"             # HTTP management port
      portAmqp: "5672"          # AMQP port (for connectivity check)
    rabbitmqAdminLogin:
      # Option A: Use an existing Secret (recommended)
      # Required keys: RABBITMQ_ADMIN_USER, RABBITMQ_ADMIN_PASS
      useExistingSecret:
        name: "my-rabbitmq-admin-secret"
      # Option B: Inline credentials (not recommended in production)
      # username: "admin"
      # password: "s3cret"
    appCredentials:
      # Option A: Use an existing Secret (recommended)
      # Required keys: RABBITMQ_DEFAULT_PASS, RABBITMQ_CONSUMER_PASS
      useExistingSecret:
        name: "my-rabbitmq-app-credentials"
      # Option B: Inline passwords (not recommended in production)
      # transactionPassword: "transaction-pass"
      # consumerPassword: "consumer-pass"
All secrets must be in the same namespace as the release. The Job has a TTL of 300 seconds after completion. Users created: midaz (admin), transaction, consumer.

​
RabbitMQ over TLS/SSL

If your RabbitMQ server requires TLS/SSL, update the client environment variables to use secure protocols:

​
Use your own RabbitMQ

If you already have a RabbitMQ instance running, you can disable the built-in dependency and point Midaz components to your external setup.