Ledger service configuration reference
The Ledger service uses module-specific database configurations:
External secrets support
Deployment flags reference
| Flag | Default | Description |
|---|
| ledger.enabled | true | Enables the unified Ledger service |
| onboarding.enabled | — | Legacy split service — removed from current chart versions (migration only) |
| transaction.enabled | — | Legacy split service — removed from current chart versions (migration only) |
| migration.allowAllServices | false | Hidden flag to allow all services simultaneously |
Environment variables reference
Detailed descriptions for variables that aren’t self-explanatory from the YAML block above.
Database connection pools
| Variable | Description | Default |
|---|
DB_ONBOARDING_MAX_OPEN_CONNS | Maximum open connections to the Onboarding PostgreSQL database. | Go default (unlimited) |
DB_ONBOARDING_MAX_IDLE_CONNS | Maximum idle connections kept alive for the Onboarding database. | Go default (2) |
DB_TRANSACTION_MAX_OPEN_CONNS | Maximum open connections to the Transaction PostgreSQL database. | Go default (unlimited) |
DB_TRANSACTION_MAX_IDLE_CONNS | Maximum idle connections kept alive for the Transaction database. | Go default (2) |
For production workloads, set explicit pool limits to prevent connection exhaustion. A common starting point: MAX_OPEN_CONNS=25, MAX_IDLE_CONNS=10 per database module. Tune based on your PostgreSQL max_connections setting and the number of Midaz replicas.
RabbitMQ
| Variable | Description | Default |
|---|
RABBITMQ_VHOST | RabbitMQ virtual host. Useful for isolating Midaz traffic in shared RabbitMQ clusters. | / |
Audit logging
When enabled, Midaz publishes detailed operation-level audit logs to a RabbitMQ exchange after each transaction. The audit payload includes the full operation data (amounts, accounts, balances before/after) serialized as JSON. You consume these events by binding your own queue to the audit exchange.
| Variable | Description | Default |
|---|
AUDIT_LOG_ENABLED | Enable transaction audit logging. | false |
RABBITMQ_AUDIT_EXCHANGE | RabbitMQ exchange name for audit messages. | audit.append_log.exchange |
RABBITMQ_AUDIT_KEY | Routing key for audit messages. | audit.append_log.key |
Transaction events
| Variable | Description | Default |
|---|
RABBITMQ_TRANSACTION_EVENTS_ENABLED | Enable real-time transaction event publishing. See Event publisher for details. | false |
RABBITMQ_TRANSACTION_EVENTS_EXCHANGE | RabbitMQ exchange name for transaction events. | transaction.transaction_events.exchange |
Async transaction processing
When RABBITMQ_TRANSACTION_ASYNC is enabled, Midaz processes transactions asynchronously through RabbitMQ consumers instead of inline during the API request. The bulk recorder further batches database writes for higher throughput.
BULK_RECORDER_* variables only take effect when both RABBITMQ_TRANSACTION_ASYNC=true and BULK_RECORDER_ENABLED=true.
| Variable | Description | Default |
|---|
RABBITMQ_TRANSACTION_ASYNC | Enables asynchronous transaction processing via RabbitMQ consumers. | false |
RABBITMQ_NUMBERS_OF_WORKERS | Number of async consumer worker goroutines. | 5 |
RABBITMQ_NUMBERS_OF_PREFETCH | RabbitMQ prefetch count per worker — controls how many messages each worker buffers at once. | 10 |
BULK_RECORDER_ENABLED | Enables bulk insert mode for operation writes when async processing is active. | true |
BULK_RECORDER_SIZE | Batch size for bulk inserts. Set to 0 for automatic sizing based on load. | 0 (auto) |
BULK_RECORDER_FLUSH_TIMEOUT_MS | Maximum time (in milliseconds) to wait before flushing an incomplete batch. | — |
BULK_RECORDER_MAX_ROWS_PER_INSERT | Maximum number of rows per INSERT statement during bulk writes. | — |
| Variable | Description | Default |
|---|
MAX_PAGINATION_MONTH_DATE_RANGE | Maximum date range (in months) allowed for paginated queries. Limits how far back list endpoints can query. Set to 0 for unlimited range. | 3 |
MAX_PAGINATION_LIMIT | Maximum number of items returned per page in paginated API responses. | 100 |
The pagination date range limit prevents expensive full-table scans on large datasets. If your use case requires querying historical data beyond 3 months, increase this value or set it to 0 — but monitor query performance accordingly.