Skip to main content
CRM and Fees guidance marked legacy on this page applies only to legacy releases that already exist. Midaz v4 deploys the unified Ledger and serves CRM and Fees on /v2.
In Midaz v4, the unified Ledger contains CRM and Fees as modules. Use their /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.
Verify your tools are ready:
In Midaz v4, CRM ships from the same source-available Midaz repository as an embedded Ledger component. It is not a plugin with a separate license. Separately deployed plugins may require an Enterprise license. Contact a Lerian representative if you need one.

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:
Check plugin version compatibility to find a plugin version compatible with your Midaz Core version, and inspect that plugin’s chart metadata before deploying it.

2. Install the chart

Replace <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:
Check the pod status:
All pods should show Running status and READY state.
To install a plugin with custom configuration, create a values.yaml file and pass it with the -f flag:

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.
Keep sensitive values in Kubernetes Secrets. Do not assume a key accepted by one plugin is valid for another.

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:
Replace <plugin> with the plugin’s service key.
For detailed ingress configuration examples with AWS ALB and Traefik, refer to the Midaz Helm deployment guide. The same patterns apply to plugin charts.

Verifying your deployment


After you install a plugin, verify that it runs correctly.

Check pod status

All pods should be in Running state with all containers ready.

Check pod logs

Look for successful startup messages and verify there are no errors related to database connections, license validation, or missing configuration.

Test the health endpoint

Each plugin sets its own probe paths. Read them from the Deployment:
Read the service name and its port with 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.
For detailed upgrade procedures, pre-upgrade checklists, and rollback instructions, see the Helm upgrade guide.

Uninstalling a plugin


To remove a plugin from your cluster:
Uninstalling a plugin removes its Kubernetes resources (deployments, services, configmaps, secrets) but does not delete persistent data stored in databases. If you used the bundled MongoDB, the PersistentVolumeClaims may remain. Delete them manually if you want to fully clean up.