/v2 API through the Ledger. They are not separate services, ports, plugins, or Helm releases.
Midaz plugins ship as independent Helm charts and follow the same deployment model as Midaz Core. Each plugin runs as a separate service alongside the platform, with its own configuration, dependencies, and lifecycle.
Before deploying any plugin, make sure you have a running Midaz Core instance. Plugins depend on Midaz Core APIs and cannot operate independently. See the Midaz Helm deployment guide if you haven’t set up Midaz yet.
Prerequisites
Before deploying plugins, make sure you have:
- A running Kubernetes cluster with Midaz Core already deployed. Use a currently supported minor release in production.
- Helm 3.8 or later, for OCI registry support.
- kubectl configured with access to your cluster.
- Cluster admin permissions or appropriate RBAC roles.
- A valid Enterprise license key for the plugin you deploy.
Available plugin charts
Each plugin ships as an OCI-compatible Helm chart.
Every chart is published at
oci://registry-1.docker.io/lerianstudio/<chart-name>.
CRM is a module inside the
midaz-helm chart. You enable it with the crm values block. No CRM chart exists.Installing a plugin
The installation process is the same for all plugins. Replace the chart name, registry, and version for the plugin you want to deploy.
1. Check available versions
Read the current chart version from the registry:2. Install the chart
- Pix
- Indirect Pix (BTG)
<version> with the desired chart version. The --create-namespace flag creates the midaz-plugins namespace if it doesn’t already exist.
3. Verify the installation
After installing, confirm the release is deployed:Running status and READY state.
Configure the selected chart
Plugin charts do not share one license, secret, or persistence contract. Inspect the selected chart’s
values.schema.json and chart-specific documentation before setting values. Do not reuse CRM or Fees examples: in Midaz v4 they are Ledger modules, not plugin charts.
For example, Bank Transfer requires chart-specific encryption keys and uses bankTransfer.secrets.MONGO_URI when its bundled MongoDB is disabled. Its license integration is optional when LICENSE_SERVICE_ADDRESS and TENANT_IDS are unset. Other plugins have different requirements.
Configuring ingress
By default, plugin services use
ClusterIP, so they are only accessible within the cluster. To expose a plugin externally, enable ingress in your values.yaml.
The ingress configuration follows the same pattern as Midaz Core. Here’s an example using NGINX:
<plugin> with the plugin’s service key.
Verifying your deployment
After you install a plugin, verify that it runs correctly.
Check pod status
Running state with all containers ready.
Check pod logs
Test the health endpoint
Each plugin sets its own probe paths. Read them from the Deployment:kubectl get svc -n midaz-plugins. Then port-forward the Service and call the path you read:
Upgrading plugins
To upgrade a plugin to a new version, use
helm upgrade with the target version:
Always upgrade Midaz Core before upgrading plugins. Plugins depend on Midaz Core APIs, so upgrading in the wrong order may cause compatibility issues.
Uninstalling a plugin
To remove a plugin from your cluster:
Related resources
- Deploy Midaz using Helm – Initial Midaz Core installation guide
- Helm upgrade guide – Upgrade procedures and rollback instructions
- Midaz chart version compatibility – Current Midaz chart and application metadata
- Plugin version compatibility – Plugin compatibility with Midaz Core versions
- Our plugins – Plugin catalog and how plugins work
- Helm repository – Source code, charts, and release notes

