White-label AI platform: where multi-tenancy breaks
A multi-tenant White-Label AI platform promises clear economics: one codebase, one update pipeline, many clients under their own brands. This scheme breaks not on models, but at the boundaries between tenants — and usually in four predictable places.
First — a shared data domain. Tables, vector indexes, and file storages sit in one schema, while a tenant is separated by an ID filter.
With five clients this is tolerable; with the twentieth, any query error exposes someone else's context, tenant offboarding turns into manual cleanup of shared tables, and the backup remains shared — a rollback affects everyone.
Second — manual access provisioning: roles, keys, limits, and quotas are created by a person according to a checklist.
The time to onboard a new tenant grows from days to weeks, and the cost of a permissions error grows along with it: an extra role for a client's contractor is not revoked for months.
Third — custom builds proliferate. “Make the button different” turns into a separate branch, core updates are checked manually for each tenant, and tenant isolation ends along with it.
Fourth — observability: metrics, logs, and limits are shared, so an incident at one client looks like degradation for everyone. Let's break down how these failure points of the SaaS scheme are closed architecturally.
What a multi-tenant domain provides: measurable metrics after launch
Separate installations for each customer provide a predictable cost: a new copy of the core, its own migrations, its own support branch.
Tenant onboarding time is measured in weeks, and a fix found at one client is ported manually to the other domains — hence the class of failures due to version drift and the growing support load.
| Implementation metric | Before | After |
|---|---|---|
| Tenant onboarding time | weeks: core copy, migrations, own branch | days: isolation, quotas, and roles — declaratively |
| Failure class | a fix in one domain diverges from the others | one core, version drift eliminated |
| Support load | manual actions for each client | core update once for all |
| Load isolation | a spike at one slows down neighbors | quotas keep a consumer within its boundaries |
The effect comes from splitting into a common core and thin tenant overrides: limits, permissions, routes, and toggles live as configuration rather than as a separate code branch.
The domain is deployed on Kubernetes — a namespace, quotas, and network policies per tenant, so data and resources do not overlap, and the core update happens once.
Support load shifts from manual edits to platform maintenance, and implementation metrics become equally measurable across all tenants: onboarding time, share of reusable modules, number of incidents per client.
Tenant isolation options: shared, segmented, dedicated
Tenant data isolation is primarily about what is physically separated: database schema, network perimeter, encryption keys, and update branch.
The level of isolation determines whether one customer can move to its own logic and interface without breaking the release cycle for the others.
The trade-off is direct: the stronger the isolation, the greater the freedom for customization — and the more domains have to be updated, tested, and maintained separately.
| Option | When it fits | Constraints of the approach |
|---|---|---|
| Shared domain | Mass segment, differences fit into settings, roles, and permissions | Shared branch: customization for one tenant goes into configuration, not code; data segregation requirements cannot be met |
| Segmented domain | Groups of tenants with similar logic: industries, regions, service levels | There are several branches: updates are rolled out in waves, some changes are duplicated across segments |
| Dedicated domain | A tenant with segregation requirements, its own set of integrations, and its own release cadence | Separate instance and separate branch: updates, regression, and monitoring are independent work; porting improvements to the common core is synchronized manually |
In practice, domains are combined: the core lives in a common branch, segmented domains inherit it and override some layers, and a dedicated domain is given to a specific tenant when segregation and customization requirements outweigh the cost of separate maintenance.
Implementation stages: from data review to platform handover
Implementation proceeds in sequential steps, and each ends with an artifact that shows whether you can move on or need to change the scheme. We do not start role configuration until tenant boundaries are described — otherwise isolation has to be redone under live load.
- Data audit. We review sources, entities, and what is currently labeled by owner implicitly. The output is a data map: what can be combined and what must never be mixed under any circumstances.
- Tenant schema design. We choose the separation — a separate database, a separate schema, or a shared domain with a mandatory tenant key. The decision is fixed in the schema, not in the application code: the policy can be changed without rewriting logic.
- Roles and limits. We delineate access for administrator, operator, and end user, and set quotas for requests, storage volume, and number of tenants. Limits live at the platform level — one client does not affect the others.
- Isolation testing. We run scenarios where a tenant tries to obtain someone else's data through queries, reports, export, and search. We separately review background jobs, intermediate storages, and exports — leaks occur there most often.
- Pilot operation. We connect one or two clients to real tasks and capture metrics: response time, failure rate, platform behavior as the number of tenants grows.
- Platform handover. We hand over configurations, tenant schema, access policies, the procedure for connecting a new client and releasing updates, and train your team on your own domain.
After handover, the platform remains yours, and the documentation describes not only the current state but also the change procedure: a new tenant is connected according to the instructions, without contacting us.
Handover package: configurations, schemas, access policies, regulations
The handover package is not an archive of files, but a set by which the platform can be deployed and operated without us. It includes everything that determines system behavior: configurations, data schemas, access policies, and regulations.
We check completeness at acceptance: we deploy the environment according to the documents and compare the result with the reference.
- Working configurations — parameters of development, testing, and production domains, tenant limits, queue and request priority settings.
- Routing schemes — how a request reaches the model, where moderation and logging are enabled, and which fallback path works if the primary one fails.
- Data schemas — storage structure, relationships between tenants, isolation rules, retention periods, and history storage procedure.
- Access policies — roles and scopes, separation of platform administrator and tenant administrator rights, procedure for issuing and revoking keys.
- Operations regulations — model updates, rollback procedure, response to degradation in answer quality, scheduled maintenance, and notifications.
- Documentation — architecture, integration points, support instructions, responsibility matrix between teams.
- Verification sets — test scenarios and acceptance criteria by which you confirm functionality after changes.
We hand over everything in editable form and with versioning: edits are made without us and do not break compatibility.
Case study: how a service removed manual access provisioning for tenants
What it was like before the transition
The service ran several dozen client domains on one platform, and each new tenant was set up manually.
A support engineer created an administrator, assigned roles, linked a domain, and configured branding according to a multi-page instruction — from four hours to two days per tenant.
Access requests came by email and messengers, got lost in correspondence, and permissions were granted with a margin: approving an extra permission is faster than understanding the role matrix.
The load grew with the number of tenants: up to 40 requests per week, almost half of them identical. Changing a plan or connecting a module required manual editing of each domain, and differences in settings between them accumulated and surfaced on the client side.
What was changed and what the measurements showed
Access provisioning was moved to the Tenant Portal: the administrator creates a tenant environment, selects modules, domain, and branding, and roles are distributed from templates and inherited from the plan.
Edits are applied to all domains in one operation, and the change log records who changed permissions and when.
Metrics before and after during pilot operation: out of 40+ domains, 15 were migrated; access provisioning time decreased from two days to 5–7 minutes; the share of requests resolved by self-service was 92%; the flow of support requests fell from 40 to 7–9 per week; accesses with excessive permissions — from 12% to 0.8%; connecting a new tenant — 15 minutes instead of one or two days.
Measurements were taken in weekly snapshots from access logs and the ticketing system: the same indicators were compared on the same domains for the period before the transition and after two months of operation.
Rolling back any domain to a previous configuration was tested separately — it takes minutes and does not affect other tenants, so the expansion to the entire base proceeded without service downtime.
How does multi-tenancy differ from deployment copies?
Multi-tenancy is one codebase and one deployment domain, within which the data, settings, and permissions of each client are separated at the platform level.
A per-client copy is the opposite approach: a separate product instance is spun up for each customer with its own database, configuration, and update queue. The divergence manifests not at the start, but at the tenth client.
The level of isolation is chosen deliberately: a shared database with row-level access separation, a separate schema per client, or separate storage.
The first two options provide dense packing and shared reference data; the third provides physical isolation where the customer's policy requires it. Copies provide such isolation immediately, but the price is duplicated infrastructure and logic.
Update speed is the main difference. In a unified domain, a fix or new capability is rolled out in one release and reaches all clients synchronously; the rollback is also one.
With copies, every change turns into as many migrations as there are deployments: versions diverge, some customers remain on an old build, and diagnosing an incident requires traversing environments.
Total cost of ownership grows linearly with the number of copies — twice as many clients means twice as many updates, checks, and places where configurations can diverge.
Customization in a multi-tenant scheme goes through tenant settings: permissions, limits, model sets, interface branding. A copy allows editing code directly, but such edits then block common updates.
The working scheme for a white-label platform is a unified domain with separation as the foundation, and dedicated deployment only for clients with strict data isolation requirements.
Technical concerns: data isolation, billing, updates
Engineering objections to a white-label platform come down to three: whether data will leak between tenants, how consumption is calculated, and how customization coexists with shared releases. Let's go through them in order.
How is data isolation between tenants verified?
Every record is marked with a tenant key, access is restricted by database roles and row-level security policies — the application will not return someone else's rows. Files and vectors reside in separate storage spaces with their own encryption keys.
We confirm isolation with tests: a check reads one tenant's data under another tenant's account and must be denied.
How are tenant limits and billing configured?
Metering happens at the ingress gateway: requests, tokens, model runtime, and storage volume are counted with a tenant label. A soft quota warns, a hard quota restricts — one tenant will not consume the shared pool. Invoices are built on the same counters, so billing and limits do not diverge.
Does customization break shared updates?
The core and client customizations are separated: changes live in an extension layer and configurations, not in the shared codebase. Core updates are rolled out canary-style across tenants, migrations are versioned, and rollback goes to the previous release.
A conflict between a customization and the core is visible at build time, not at the customer's side.
Let's discuss the task: we'll assemble a tenant scheme for your product
To discuss the task concretely and not guess at the architecture, we need inputs on the product: how your sales model is structured, how many independent clients are planned in the first year, and how they differ from one another.
With this set, in one call we will remove uncertainties and come back with a tenant scheme, a stage plan, and a work estimate — without intermediate “we'll clarify later.”
What is worth preparing for the conversation:
- A list of tenant scenarios: what roles exist within each, what they can see, and what they are prohibited from doing.
- Isolation requirements: each client's data and settings do not overlap, while the shared product logic remains one.
- A list of customizations: branding, domains, emails, reports, thresholds, and rules that the client changes themselves.
- A pricing and restrictions model: which limits apply at the tenant level and which at the user level.
- Integration points: external systems, data exchange, requirements for access and permission separation.
- Load and growth forecast: how many tenants will be added per quarter and how this affects the infrastructure.
- Constraints on launch timelines and on what already works and must not break.
On the call, we will clarify where the boundary lies between the shared platform and the client part, how to organize onboarding of a new tenant, and how to ensure rollback in case of failure.
Describe the task — we will come back with an estimate and a stage plan showing what we do first and what can be postponed.
