Multi-tenancy allows you to manage multiple environments (e.g., dev, staging, prod) in a single Kestra instance.
Multi-tenancy is a software architecture in which a single instance of software serves multiple tenants. You can think of it as running multiple virtual instances in a single physical instance. You can use multi-tenancy to separate resources between business units, teams, or customers.
This feature requires a commercial license.
By default, multi-tenancy is disabled. See the multi-tenancy section of the Administrator Guide on how to configure it.
When multi-tenancy is enabled, all resources (such as flows, triggers, executions, RBAC, and more) are isolated by the tenant. This means that you can have a flow with the same identifier and the same namespace in multiple tenants at the same time.
Data stored inside the internal storage is also isolated by tenants.
Multi-tenancy functionality is not visible to end-users from the UI except for the tenant selection dropdown menu. That dropdown menu lists all tenants a user has access to, allowing users to switch between tenants easily. Each UI page will also include the tenant ID in the URL e.g.
The API URLs will also change to include the tenant identifier.
For example, the URL of the API operation to list flows of the
products namespace is
/api/v1/flows/products when multi-tenancy is not enabled, and becomes
/api/v1/production/flows/products for the
production tenant when multi-tenancy is enabled. You can check the Enterprise Edition API Guide for more information.
Tenants must be created upfront, and a user needs to be granted access to use a specific tenant.