Skip to main content

​
Production recommendation

We do not recommend using the Midaz Helm chart’s default dependencies (databases, cache, and message broker) in production environments. For production-grade deployments, follow our best practices to operate these dependencies with proper security, observability, backups, disaster recovery, and SLOs.

​
Best practices

​
Upgrade order

Always upgrade in this order:
  1. Infrastructure (if needed)
  2. Midaz Core
  3. Plugins (one at a time)

​
Test first

Always test upgrades in a staging environment that mirrors production before applying to production.

​
Monitor closely

Monitor logs and metrics closely for the first 15-30 minutes after an upgrade.

​
Keep backups

Maintain backups of your Helm values and database before major upgrades.

​
Upgrade checklist summary

StepCommandVerified
Backup valueshelm get values <release> -n midaz > backup.yaml
Check compatibilityReview compatibility table
Upgrade Midazhelm upgrade midaz ...
Verify Midaz podskubectl get pods -n midaz
Upgrade pluginshelm upgrade <plugin> ...
Verify plugin podskubectl get pods -n midaz
Check logskubectl logs -n midaz deployment/<name>

​
Post-upgrade verification

​
1. Check pod status

kubectl get pods -n midaz
All pods should be Running and READY.

​
2. Verify services

kubectl get svc -n midaz

​
3. Check the logs

# If using Ledger service (v5.x)
kubectl logs -n midaz deployment/midaz-ledger

# If using legacy services
kubectl logs -n midaz deployment/midaz-onboarding
kubectl logs -n midaz deployment/midaz-transaction

# Check RabbitMQ logs (important for v4.x+ upgrades)
kubectl logs -n midaz statefulset/midaz-rabbitmq

# Check CRM logs (if enabled)
kubectl logs -n midaz deployment/midaz-crm

​
4. Verify ingress routing (v5.x with Ledger)

kubectl get ingress -n midaz
kubectl describe ingress midaz-onboarding -n midaz
kubectl describe ingress midaz-transaction -n midaz