Skip to main content
When a new tenant is onboarded, the platform provisions everything that tenant needs to operate in isolation — databases, a message broker, credentials, and schema migrations — without manual database administration for each product. This page describes the provisioning lifecycle end to end — from tenant creation to active database connections.
Automatic provisioning runs only when MULTI_TENANT_ENABLED=true. In single-tenant deployments, products use a single pre-configured database and skip this lifecycle entirely.

​
The provisioning lifecycle

Onboarding a tenant moves through five stages. Each stage builds on the previous one, ending with a tenant that is fully isolated and ready to serve traffic.
1

Tenant creation

A tenant is created with its identity and metadata. At this point the tenant exists as an identity only — the value the tenantId JWT claim will resolve to — but has no infrastructure attached yet.
2

Service registration

Each product the tenant will use is registered as a service under that tenant — for example, Midaz Ledger or Tracer. The service registration declares the isolation mode (DATABASE or SCHEMA) and the configuration the platform needs to provision and reach the tenant’s resources.
3

Automatic provisioning of infrastructure

Registering a service triggers provisioning of the isolated infrastructure for that tenant:
  • PostgreSQL — a dedicated database (in DATABASE mode) or a dedicated schema (in SCHEMA mode) for relational data.
  • MongoDB — an isolated database for document data such as metadata.
  • RabbitMQ — isolated messaging resources (virtual host / queues) for the tenant’s asynchronous events.
Credentials for each resource are generated and stored in the credentials vault, never embedded in configuration or shared between tenants.
4

Migrations

Once the infrastructure exists, the platform runs the product’s schema migrations against the tenant’s new database or schema. This brings the tenant’s storage to the exact schema version the product expects, so a freshly provisioned tenant is structurally identical to every other tenant on that product.
5

Start of operation

With infrastructure provisioned, credentials vaulted, and migrations applied, the service is marked ready. The product can now resolve the tenant from its JWT, open an isolated connection, and begin serving requests. From this point the tenant operates exactly as described in Multi-tenancy.

​
What gets provisioned

ResourcePurposeIsolation
PostgreSQLRelational data — organizations, ledgers, accounts, transactions, balances, rules, limits.Dedicated database (DATABASE mode) or dedicated schema (SCHEMA mode).
MongoDBDocument data such as metadata.Dedicated database per tenant.
RabbitMQAsynchronous events and inter-service messaging.Isolated virtual host / queues per tenant.
CredentialsAccess to the resources above.Unique per tenant, stored in the credentials vault.
Credentials are generated per tenant and stored in the vault. They are never reused across tenants and never shared between isolation modes. See Security for rotation and credential-handling guarantees.

​
Why provisioning is centralized

Previously, provisioning logic lived only inside individual product scopes (such as the Matcher). Centralizing it through the platform layer means:
  • Consistency — every product provisions a tenant the same way, with the same isolation guarantees and the same migration discipline.
  • One onboarding path — adding a tenant to a new product is a service registration, not a bespoke database setup.
  • Auditability — tenant and service lifecycle is tracked in one place rather than scattered across products.
Because provisioning is tied to service registration, you can onboard a tenant to additional products over time — each new service registration provisions its own isolated infrastructure without touching the tenant’s existing data.

Use cases

The tenant and service entities that drive provisioning.

Multi-tenancy

How isolation modes and tenant scoping work.

Security

Credential vaulting, rotation, and per-tenant resource limits.

Use cases

Choosing an isolation mode for your deployment.