Multi-Tenant
Multi-tenant localization allows you to efficiently manage translations for multiple customers or brands from a single main project, while giving each tenant their own isolated environment. This is ideal for SaaS platforms, white-label solutions, or any scenario where you need to provide customized translations for different clients.
multi-tenant part of showcase/demo
Why use multi-tenant projects?
Previously, multi-tenant needs were handled using extra namespaces or custom locales (like en-x-customer1). Locize now provides a dedicated solution:
- Each customer gets their own project with restricted access — customers cannot see each other's data.
- You control who pays: cover the costs yourself or let customers pay for their own usage.
How does it work?
Navigate to the Multi-Tenant page:
There you can create a new tenant project:
Tenant projects are based on the content of your main project. All existing and future translations are visible in the tenant project.
Users of the tenant project can keep your provided translations or override them as needed.
Overridden values are marked with the overridden state icon and can be filtered:
When translations are published to the CDN (or exported via the UI, CLI, or API), the output combines your main translations with any overridden values from the tenant.
Accessing translations from the CDN
Each tenant project has its own settings, users, API keys, and project ID. To load translations from the CDN, use the tenant project ID found in the settings page.
Pricing
- Costs are the same as any other project: downloads and modifications are usage-based.
- Word count is calculated only on overridden values — text inherited from the main project is not charged twice.
- You can cover tenant costs via your main subscription, or let customers subscribe and pay with their own credit card.
Tenant Project Options
Tenant projects can be configured with two key options that affect how languages and namespaces are managed:
Option 1: can't deviate from parent
- Enabled: Tenant must use the same languages and namespaces as the parent project.
- Disabled: Tenant can have a different set of languages and namespaces than the parent.
Option 2: can edit languages
- Enabled: Tenant administrators can add or remove languages in the tenant project.
- Disabled: Only users who are administrators in both the parent and tenant projects can add or remove languages.
Effects of parent language changes
| Scenario | "can't deviate from parent" | "can edit languages" | When a language is added/removed in parent |
|---|---|---|---|
| 1 | Enabled | (not possible) | Language is also added/removed in tenant |
| 2 | Disabled | Disabled | Language is not added/removed in tenant |
| 3 | Disabled | Enabled | Language is not added/removed in tenant |
Effects of parent namespace changes
| Scenario | "can't deviate from parent" | "can edit languages" | When a namespace is added/removed in parent |
|---|---|---|---|
| 1 | Enabled | (not possible) | Namespace is also added/removed in tenant |
| 2 | Disabled | Disabled | Namespace is not added/removed in tenant |
| 3 | Disabled | Enabled | Namespace is not added/removed in tenant |
Note:
- When "can't deviate from parent" is enabled, the tenant always mirrors the parent for languages and namespaces.
- When "can edit languages" is enabled, tenant admins have full control over languages, and changes in the parent do not automatically propagate to the tenant.