Tenant management
Multi-tenancy is on by default - see /help/concepts/multi-tenancy and /help/setup/multi-tenancy.
Tenant lifecycle
A tenant has three states:
| State | Meaning |
|---|---|
INITIAL | Tenant registered, provisioning not finished. |
PROVISIONED | All provisioning steps completed; the tenant is serving. |
PENDING_ACTIVATION | Registered by an external provisioner, which owns the tenant's database user, schema and data source. Invisible to the provisioner below and to executeForEachTenant, so nothing acts on the tenant until that provisioner activates it. See Tenant provisioning API. |
DEPROVISIONING | Being removed by an external provisioner. Invisible to executeForEachTenant like PENDING_ACTIVATION; the row goes when the removal finishes. See Remove a tenant. |
A tenant is registered explicitly, through the tenants API or the Security perspective, and enters INITIAL. The provisioner picks it up on its next pass and moves it to PROVISIONED once every step has run; a step that fails leaves the tenant INITIAL and the next pass retries it. Nothing creates a tenant implicitly, so an unknown tenant is never provisioned by being asked for.
Until a tenant is PROVISIONED it cannot be entered. Under the TOKEN_GROUPS resolution strategy a user who has been granted it sees it on the tenant picker but cannot select it yet; see Tenant resolution.
A tenant may only be deleted while nothing has been materialized for it, which means INITIAL or PENDING_ACTIVATION. Deleting a PROVISIONED tenant would be deprovisioning, and is refused here. A tenant an external provisioner activated is removed through the tenant provisioning API instead.
Provisioning cadence
DIRIGIBLE_TENANTS_PROVISIONING_FREQUENCY_SECONDS=30The provisioner polls the tenant table at this cadence and drives INITIAL tenants through their steps. The default is 900 (15 minutes), so a newly registered tenant may take that long to become usable; lower it if tenants are created interactively.
Provisioning step SPIs
Two SPI hooks let modules plug into the lifecycle:
TenantProvisioningStep- runs while the tenant is stillINITIAL, before it is markedPROVISIONED. Used by data-source provisioning, CMS root setup, etc.TenantPostProvisioningStep- runs after the tenant isPROVISIONED, and is handed the ids of the tenants just provisioned. Used for "after the lights are on" tasks like seed data. The platform's own step applies every multitenant artefact to those tenants only, which is how a new tenant's schema receives its tables, its CSV seeds and its data migrations while the existing tenants are left as they are.
Implementations are discovered as Spring beans. Order via @Order.
Tenant-scoped resources
| Resource | Tenant-isolated? |
|---|---|
| Default data source | yes - tenant-prefixed pool name |
| User data sources | yes |
| CMS root folder | yes |
| Scheduled jobs / listeners | yes |
| OData services | yes |
| BPMN process instances | no - system-level |
| Camel routes | no |
| Extension declarations | no |
| Git repositories / workspaces | no |
Disabling multi-tenancy
For single-org deployments:
DIRIGIBLE_MULTI_TENANT_MODE=falseAll artefacts resolve against the default tenant.