For the complete documentation index, see llms.txt.
Skip to main content
Version: 8.10 (unreleased)

Provisioning and lifecycle

This page describes how to provision and operate Physical Tenants in Camunda 8.10.

Provisioning model in 8.10​

Physical Tenants are provisioned through static application configuration.

  • Add or change tenant configuration in application config.
  • Apply the change with a rolling restart.
  • Validate startup status for every affected component.

Dynamic runtime tenant creation and runtime tenant updates are not available in 8.10.

Add a new Physical Tenant​

To add a tenant:

  1. Add a new camunda.physical-tenants.<tenant-key> section in configuration.
  2. Define the tenant-specific initialization and required assignments.
  3. Ensure required storage and identity configuration is valid.
  4. Apply the change through a rolling restart.

Rolling restart expectations​

During a rolling restart for tenant provisioning:

  • Existing tenant traffic should continue according to your rollout strategy.
  • New tenant availability starts after updated components are running and ready.
  • Startup validation failures block readiness for affected components.

Default tenant lifecycle​

In 8.10, the default Physical Tenant is always present and immutable:

  • You cannot delete the default tenant.
  • You cannot rename the default tenant.
  • You cannot disable the default tenant.

If tenant scope is omitted in compatibility paths, requests resolve to the default tenant.

Disable, rename, and delete​

For 8.10:

  • Disabling a Physical Tenant is not supported.
  • Renaming a Physical Tenant is not supported.
  • Deleting a Physical Tenant is not supported.

If you remove a Physical Tenant from configuration, the cluster will no longer process requests for that tenant. The API returns 404 Not Found for requests scoped to a removed tenant. No data is deleted. You can reactivate the tenant by restoring its configuration.

Out of scope for 8.10​

The following capabilities are out of scope for 8.10:

  • Dynamic tenant creation without restart
  • Tenant deletion
  • Runtime tenant updates

Upgrade behavior from 8.9​

For single-tenant 8.9 clusters upgrading to 8.10:

  • Existing root-level configuration becomes the default Physical Tenant behavior.
  • No explicit migration step is required for this default mapping.

Operational guidance​

Before applying provisioning changes:

  • Validate tenant IDs and property paths.
  • Validate identity provider assignments.
  • Validate storage isolation settings per tenant.
  • Plan and execute a rolling restart window.

After rollout:

  • Verify tenant-scoped APIs route to expected tenant context.
  • Verify storage isolation and startup health.
  • Verify authentication behavior for assigned providers.