Multi-Tenancy

Overview

Multi-tenancy in Webiny allows a single instance to serve multiple tenants (clients/projects), each with completely isolated data and configuration. This architecture enables cost-effective management of multiple projects while maintaining strict data separation and security.

How It Works

Data Isolation

Each tenant in Webiny has:

• Separate content models - No shared schemas between tenants
• Isolated content entries - Complete data separation
• Independent assets - File storage partitioned by tenant
• Tenant-specific settings - Individual configurations

Unlike systems that simulate multi-tenancy with folders or prefixes, Webiny provides true isolation at the database level. Each tenant operates as if it has its own Webiny instance.

Default Hierarchy

Webiny implements a two-level hierarchy by default:

• Root Tenant - Administrative level with oversight capabilities
• Child Tenants - Isolated operational tenants

User Access Patterns

Root Tenant Users:

• Can access and manage child tenants
• Switch between tenants via UI
• Can be restricted to specific child tenants
• Ideal for administrators and support staff

Child Tenant Users:

• Access only their own tenant’s data
• No visibility into other tenants
• Standard content management permissions apply

Implementation

Enabling Multi-Tenancy

Configure in webiny.config.tsx:

Tenant Management API

Create and manage tenants programmatically:

Custom Hierarchies

Extend beyond the default two-level structure:

Common Use Cases

Digital Agencies

Managing multiple client websites:

• Each client is a separate tenant
• Agency staff access via root tenant
• Client users access only their tenant
• Shared templates and components

Enterprise Brands

Large organizations with multiple properties:

• Each brand/division as a tenant
• Central marketing team oversight
• Brand-specific content teams
• Consistent governance across brands

SaaS Platforms

Embedding CMS capabilities:

• Each customer gets a tenant
• Automated provisioning via API
• Tenant-based billing and limits
• White-label customization per tenant

Educational Institutions

Department or course management:

• Departments as tenants
• Central IT administration
• Department-specific content teams
• Shared institutional resources

Advanced Features

Tenant Provisioning

Automate tenant creation:

Access Control

Fine-grained tenant permissions:

Content Sharing

Share content between tenants:

Best Practices

Tenant Naming

Use consistent naming conventions:

• Include identifiers: client-abc-prod
• Add environment: client-abc-staging
• Use tags for categorization

Resource Limits

Implement per-tenant limits:

• Storage quotas
• API rate limiting
• User count restrictions
• Content entry limits

Monitoring

Track tenant-specific metrics:

• API usage per tenant
• Storage consumption
• User activity
• Performance metrics

Data Migration

Plan for tenant lifecycle:

• Tenant cloning for staging
• Data export capabilities
• Tenant archival process
• Cross-tenant migrations

Performance Considerations

Multi-tenancy in Webiny is designed for scale:

• Database partitioning - Tenant data physically separated
• Query optimization - Tenant ID in all queries
• Caching strategies - Per-tenant cache keys
• CDN configuration - Tenant-specific cache rules

The architecture handles thousands of tenants without performance degradation, making it suitable for large-scale deployments.