Three Tenancy Models, One Platform: Why Camunda 8.10 Introduces Physical Tenants

If you run process orchestration for more than one team, you know the isolation dilemma. Everyone can share a cluster and a data store, separated only by a tenant ID which is cheap to operate, but you only get one database, one identity provider, and one backup for everyone. The alternative, you give every team its own cluster. You get full isolation and full cost: another deployment to provision, patch, upgrade, and back up, times every team you onboard.

Camunda 8.10 introduces a third multi-tenancy option and takes a clear position: the isolation model should match the risk profile of the workload, not the limits of the tool.

Three models, one platform

All three models run on the same platform, with access to the same BPMN process models and the same tooling. They differ in one dimension: how much they isolate.

• Logical Tenants: lightweight isolation. Many tenants share one cluster and one data store, separated by a tenant ID stamped on every record. Available in SaaS and Self-Managed today.
• Physical Tenants: strong isolation, new in Camunda 8.10 for Self-Managed (SaaS support is on the roadmap). Multiple self-contained tenants inside one cluster, each with its own data store, its own identity provider, and its own backup and restore.
• Multi-Cluster: maximum isolation. Each unit runs on its own dedicated cluster, fully independent end to end. Available in SaaS and Self-Managed today.

Logical tenants and multi-cluster deployments are established patterns. Physical Tenants are the new middle ground and the rest of this post is about when to reach for them.

What a Physical Tenant actually is

A Physical Tenant is a named, isolated unit of execution within a single Orchestration Cluster. Each one behaves like a self-contained mini-cluster:

• Data Store. Each tenant keeps process data in its own secondary storage. No shared database with a tenant-ID column doing the separating.
• Identity. Each tenant connects its own IdP, so authentication and authorization are governed per tenant, not cluster-wide.
• Backup. Restore one tenant to yesterday's state without touching anyone else.
• Operations. Every tenant gets its own operational control room with Operate for real-time visibility and its own audit trail along with Tasklist, and Admin views. Teams see their processes and only their processes.
• Scaling. Dedicated partitions and per-tenant secondary storage let tenants scale independently inside the shared cluster.

Connectors and job workers run shared across tenants or per tenant, whichever fits your operating model. And logical tenants remain available inside a physical tenant, so a team can still subdivide its own workload (for example, separating its application's end customers by tenant ID) without asking the platform team for anything.

Compared to running separate clusters, Physical Tenants deliver the isolation properties that matter for compliance while keeping one deployment to operate: infrastructure savings, simpler updates, and the ability to share Java applications and other resources across tenants.

What this means for your organization

Lower total cost of ownership (TCO): governance without sprawl. Requirements that previously forced dedicated clusters (separate identity providers per domain, independent backup and restore, complete data separation for audit) are now met on shared infrastructure: one platform to license, secure, and upgrade instead of a growing fleet. And when compliance needs change or you acquire a company, you onboard the new entity as a fully isolated physical tenant on day one and consolidate on your timeline. No new infrastructure, no worst-case integration estimate.

Easier operations: one cluster to run, many workloads to serve. Platform and Center of Excellence (CoE) admins operate a single deployment one install, one upgrade cycle, one monitoring setup.. Within it, each team gets a strongly isolated tenant with its own storage, identity, and backup. Operational boundaries stay clean at the API level too. Cluster-wide concerns live under cluster endpoints, tenant concerns under tenant endpoints, so you can delegate tenant administration without giving away the keys to the cluster.

Faster onboarding: a cluster of your own, minus the wait. A new delivery team gets a tenant, not a procurement cycle: their own Operate and Tasklist, their own identity provider, their own data with no other team's process instances in view. And because logical tenants still work inside a physical tenant, teams keep lightweight separation for their own projects and customers without asking the platform team for anything.

How it looks in practice

Physical Tenants are defined in cluster configuration. Each tenant declares its own secondary storage:

camunda:
  physical-tenants:
    payments:
      data:
        secondary-storage:
          type: rdbms
          rdbms:
            url: http://payments.prod
    lending:
      data:
        secondary-storage:
          type: rdbms
          rdbms:
            url: http://lending.prod

The REST API separates tenant-scoped and cluster-scoped operations by path. Per-tenant endpoints are prefixed with the physical tenant ID:

POST /physical-tenants/payments/v2/process-definitions/search
POST /physical-tenants/payments/v2/backups

Cluster-wide operations live under a cluster prefix:

GET  /cluster/v2/topology
GET  /cluster/v2/status
POST /cluster/v2/backups

That split matters architecturally: a tenant admin can manage backups and search process definitions within their tenant, while cluster topology and cluster-wide backup remain a platform-team concern.

Choosing your model: a bank as the worked example

A bank can easily end up using all three models. That’s exactly the point.

• Logical Tenants fit cooperative, low-risk separation on shared infrastructure. A Banking-as-a-Service platform separates fintech partners by tenant ID. Flagship, premium, and budget brands run the same account-opening process, separated logically. Regional branches are segmented for reporting under central governance.
• Physical Tenants fit internal domains that must not blur. Payments runs high-throughput, audit-heavy transaction processes; Lending runs loan origination with its own compliance rules and its own identity provider. Each gets its own data store and independent backup, but the bank operates one platform, saving hardware and operational cost. Post-acquisition onboarding is the other classic case: full isolation first, consolidation later.
• Multi-Cluster fits mandates for complete separation. EU and APAC clusters keep data in-region. Regulatory ring-fencing requires retail operations to be demonstrably independent from investment banking. Separate clusters guarantee no shared processes, storage, or networking, with separation you can show a regulator.

Good to know for 8.10

A few things worth planning for in the first release of Physical Tenants:

• Availability. Physical Tenants ship in Camunda 8.10 for Self-Managed. SaaS support is on the roadmap.
• Adding a tenant requires a rolling restart of the cluster. Plan tenant onboarding as a scheduled operation rather than an on-demand one.
• Compute is shared. CPU, memory, and disk are shared across tenants with no per-tenant quotas in this release, so heavy load in one tenant can affect others. Mitigate with proper resource provisioning; dedicated partitions and per-tenant secondary storage give each tenant independent scaling on the data side.

None of these change the architectural picture: strong isolation where it counts (data, identity, backup, operations) at a fraction of the cost of running separate clusters.

Get started

Camunda 8.10 lands in October. If you want to evaluate Physical Tenants early, the 8.10 alpha releases are available now for Self-Managed.

Ready to orchestrate? Explore the Camunda 8.10 release notes and the multi-tenancy documentation to plan your tenancy architecture.