How Tenant Isolation Works in Kestra Enterprise
For the complete documentation index, see llms.txt. For a full content snapshot, see llms-full.txt. Append.mdto anykestra.io/docs/*URL for plain Markdown.
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 the Enterprise Edition.
How does multi-tenancy work in Kestra
Multi-tenancy is enabled by default and required. 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.
End-users can use the tenant selection dropdown menu from the UI to see tenants they have access to. Users can switch between tenants from this dropdown. Each UI page also includes the tenant ID in the URL (e.g., https://demo.kestra.io/ui/yourTenantId/executions/namespace/flow/executionId.)
Most API endpoints also include the tenant identifier. The exception is instance-level endpoints such as /configs, /license-info, or /banners, which require Superadmin access.
For example, the URL of the API operation to list flows of the products namespace is /api/v1/{your_tenant_id}/flows/products. See the Enterprise Edition API Guide for details.
Tenants must be created upfront, and a user needs to be granted access to use a specific tenant.
Was this page helpful?