One Platform, Many Tenants, Complete Isolation
Organizations that serve multiple departments, business units, clients, or partners face a recurring infrastructure dilemma: deploy a separate wiki instance for each group and absorb the overhead of managing many installations, or deploy a single shared instance and struggle with access control, data isolation, and the conflicting customization needs of different groups. xWiki's multi-tenancy architecture eliminates this dilemma through sub-wikis, a feature that allows a single xWiki installation to host multiple fully isolated wiki environments that share underlying infrastructure while maintaining complete separation of content, users, configurations, and permissions.
This capability has been refined over more than twenty years of xWiki development and is relied upon by over 800 teams worldwide, including managed service providers, consulting firms, educational institutions, and enterprise IT departments that must serve diverse internal constituencies. The sub-wiki model brings the operational efficiency of shared infrastructure together with the security and autonomy of dedicated instances, a combination that becomes increasingly valuable as the number of tenants grows.
Deploying a multi-tenant xWiki on MassiveGRID's managed hosting infrastructure amplifies these benefits with enterprise-grade reliability and global reach. Our ISO 9001-certified data centers in Frankfurt, London, New York, and Singapore provide the performance foundation that multi-tenant deployments demand, while our 100% uptime SLA ensures that all tenants enjoy uninterrupted access to their wiki environments.
Multi-Tenancy Architecture
xWiki's multi-tenancy is built around the concept of a wiki farm: a single xWiki application server that hosts a main wiki and any number of sub-wikis. Each sub-wiki operates as an independent wiki environment with its own content spaces, user registry, permission model, extension set, and visual theme. From the perspective of users within a sub-wiki, their environment appears and behaves as a standalone wiki. The shared infrastructure that connects the sub-wikis is invisible to non-administrative users.
The architectural separation between sub-wikis extends to the database layer. Each sub-wiki can be configured to use its own database schema or even a separate database instance, ensuring that queries in one tenant's wiki cannot inadvertently access another tenant's data. This database-level isolation provides a strong security boundary that satisfies the requirements of organizations operating under strict data governance mandates, including those in regulated industries where co-mingling of data between business units or clients is prohibited.
The main wiki serves as the administrative control plane for the wiki farm. Farm administrators access the main wiki to create and configure sub-wikis, manage farm-wide settings, deploy shared extensions, and monitor resource utilization across tenants. Individual sub-wikis can have their own local administrators who manage content, users, and settings within their tenant without visibility into other tenants or the farm administration layer. This separation of administrative concerns mirrors the organizational boundaries that multi-tenancy is designed to support.
Each tenant manages its own spaces, which are the top-level organizational containers for wiki pages. A department sub-wiki might contain spaces for projects, policies, meeting notes, and technical documentation, all organized according to that department's specific conventions. The space hierarchy, naming conventions, and content structure within each tenant are entirely independent of other tenants, allowing each group to organize their knowledge in whatever way best suits their workflow.
User management in multi-tenant xWiki follows a federated model. Users can be defined locally within a sub-wiki, inherited from the main wiki, or authenticated through external identity providers like LDAP or SAML. The flexibility of this model accommodates diverse organizational structures. An enterprise deployment might authenticate all users through a corporate LDAP directory at the main wiki level, automatically provisioning them into the appropriate sub-wikis based on their department or role. A managed service provider might maintain separate user directories for each client sub-wiki, with no shared authentication between tenants.
Setting Up Tenant Isolation
Configuring proper tenant isolation requires attention to several interconnected layers: permissions, data residency, content visibility, and shared resource management. Each layer contributes to the overall isolation guarantee, and weaknesses in any layer can compromise the security of the entire multi-tenant deployment.
Per-tenant permissions form the most visible isolation boundary. xWiki's rights management system allows farm administrators to define access rules at the wiki level, ensuring that users assigned to one sub-wiki have no access whatsoever to other sub-wikis unless explicitly granted. Within each sub-wiki, the local administrator configures space-level and page-level permissions according to the tenant's internal access control requirements. The permission inheritance model flows from the farm level through the wiki level to the space and page levels, with each level able to restrict but not expand the rights granted by the level above.
Data residency is a concern for organizations that must comply with geographic data storage requirements. In a multi-tenant xWiki deployment, different sub-wikis can be configured to store their data in different database instances, which can be hosted in different geographic locations. A European department's sub-wiki might store its data in a Frankfurt database while an Asian subsidiary's sub-wiki uses a Singapore database. This configuration ensures that data residency requirements are met at the infrastructure level rather than relying solely on application-level controls.
Content visibility between tenants is controlled through a combination of permission rules and wiki configuration. By default, sub-wikis are isolated, meaning that content in one sub-wiki is invisible to users of other sub-wikis. However, xWiki's architecture also supports controlled sharing when it is desired. Shared resources like corporate templates, common macros, or organization-wide announcements can be defined in the main wiki and inherited by sub-wikis through the wiki inheritance mechanism. This selective sharing provides the efficiency benefits of shared content without compromising the isolation of tenant-specific data.
Wiki inheritance for shared resources is a particularly elegant feature of xWiki's multi-tenancy. When a sub-wiki needs to resolve a reference to a page, macro, or extension, it first searches its own content. If the reference is not found locally, the resolution process falls back to the main wiki. This inheritance chain allows the main wiki to serve as a library of shared resources that all sub-wikis can access without duplication. Common wiki applications, corporate templates, branding assets, and configuration defaults can be maintained once in the main wiki and consumed by all sub-wikis, reducing maintenance overhead and ensuring consistency.
Managing Multi-Tenant Operations
Operating a multi-tenant xWiki deployment introduces administrative responsibilities that go beyond managing a single wiki instance. Farm administrators must balance the operational efficiency of shared infrastructure against the autonomy and service quality expectations of individual tenants.
Centralized administration for billing, provisioning, and backup is one of the primary operational advantages of multi-tenancy. Rather than maintaining separate backup schedules, monitoring configurations, and update procedures for each tenant, the farm administrator manages these concerns once for the entire farm. Sub-wiki creation can be automated through scripts or the xWiki API, enabling self-service provisioning for new departments, projects, or clients. Backup procedures capture the entire farm in a single operation while supporting tenant-level restoration when needed.
Tenant-level service level agreements require monitoring granularity that distinguishes between tenants. While the overall farm may be performing well, an individual tenant might experience degradation due to resource-intensive content, excessive attachment storage, or unusual query patterns. xWiki's administration interface provides per-wiki statistics on page counts, user activity, storage consumption, and other metrics that enable farm administrators to identify and address tenant-specific issues before they affect the broader farm.
Resource monitoring in a multi-tenant environment extends beyond the standard CPU, memory, and disk metrics that single-instance deployments require. Farm administrators must also track per-tenant resource consumption to identify tenants whose usage patterns might affect other tenants. A single department that uploads thousands of large attachments or runs complex search queries could consume disproportionate database and storage resources if left unchecked. xWiki's extension ecosystem includes monitoring tools that provide this per-tenant visibility, enabling proactive resource management.
Preventing resource contention between tenants is ultimately an infrastructure provisioning challenge as much as an application configuration challenge. The xWiki application layer provides the logical isolation between tenants, but the physical resources, including CPU, memory, disk I/O, and network bandwidth, are shared. Adequate provisioning ensures that peak usage by one tenant does not degrade the experience for others. Connection pooling, query optimization, caching configuration, and storage tiering are all infrastructure-level controls that contribute to fair resource distribution across tenants.
Scaling Across Infrastructure
As the number of tenants grows, the infrastructure supporting the multi-tenant xWiki deployment must scale accordingly. The scaling strategy encompasses compute resources, storage capacity, network performance, and geographic distribution, each of which contributes to the overall quality of service that tenants experience.
Deploying on MassiveGRID's infrastructure provides a natural scaling path for multi-tenant xWiki deployments. Our data centers in Frankfurt, London, New York, and Singapore offer geographic proximity for globally distributed tenant bases, ensuring that each tenant's users experience low-latency access to their wiki environment. For organizations with tenants concentrated in specific regions, deploying the xWiki farm in the nearest MassiveGRID data center minimizes the network round-trip time that directly impacts page load performance and real-time collaboration responsiveness.
The 100% uptime SLA that MassiveGRID provides is particularly significant for multi-tenant deployments, where a single outage affects all tenants simultaneously. The reputational and operational impact of downtime is multiplied by the number of tenants served, making infrastructure reliability a business-critical concern rather than a technical detail. Our redundant power, network, and storage infrastructure ensures that the xWiki farm remains available even during component failures, and our proactive monitoring identifies potential issues before they become service-affecting events.
GDPR compliance per tenant is a requirement that many European organizations face when deploying multi-tenant platforms. MassiveGRID's GDPR-compliant infrastructure provides the foundation for meeting these requirements, including data processing agreements, data center certifications, and the technical controls necessary to demonstrate compliance. For multi-tenant deployments where different tenants have different compliance requirements, the ability to configure per-tenant database locations and backup policies ensures that each tenant's data governance needs are met individually.
Our 24/7 support team understands the operational complexity of multi-tenant deployments and can assist with provisioning, performance tuning, backup strategy, and incident response at both the farm level and the individual tenant level. This support is particularly valuable during the initial deployment phase, when the optimal configuration for the expected tenant mix and usage patterns must be determined, and during scaling events when new tenants are onboarded or existing tenants experience significant growth.
For organizations evaluating how xWiki's multi-tenancy compares to the approaches taken by proprietary platforms, our detailed xWiki versus Confluence enterprise comparison provides an in-depth analysis that includes multi-tenancy architecture, licensing implications, and total cost of ownership across different deployment scales. With over 900 extensions, support for more than 40 languages, and the LGPL open-source license, xWiki offers a multi-tenancy solution that scales economically as the number of tenants grows, without the per-user licensing costs that make proprietary alternatives increasingly expensive at scale.
Frequently Asked Questions
Can tenants share content with each other, or is everything completely isolated?
xWiki's multi-tenancy supports both complete isolation and controlled sharing, depending on how the farm is configured. By default, sub-wikis are fully isolated, and users in one sub-wiki cannot see, search, or access content in other sub-wikis. However, the wiki inheritance mechanism allows shared resources to be defined in the main wiki and inherited by all sub-wikis. This is commonly used for corporate templates, shared macros, organization-wide announcements, and common application definitions. Additionally, farm administrators can configure explicit cross-wiki access permissions for specific use cases where controlled sharing between specific tenants is desired. The key principle is that isolation is the default and sharing is always an explicit, administrator-controlled decision.
How are backups handled in a multi-tenant xWiki deployment?
Backup strategies for multi-tenant xWiki deployments operate at two levels. At the farm level, the entire database and file storage system can be backed up as a single unit using standard database backup tools and file system snapshots. This approach is operationally efficient and ensures that all tenants are backed up consistently. At the tenant level, individual sub-wikis can be exported as XAR packages through the xWiki administration interface or the REST API, providing portable backup files that can be used to restore a single tenant without affecting others. On MassiveGRID's infrastructure, automated backup schedules capture the entire farm at regular intervals with configurable retention periods, and our support team can assist with tenant-level restoration when needed. The combination of farm-level and tenant-level backup capabilities ensures both operational efficiency and granular recovery options.
Does adding more tenants affect performance for existing tenants?
Adding tenants to a multi-tenant xWiki deployment increases the overall resource demands on the shared infrastructure, but the impact on existing tenants depends on the infrastructure provisioning and the new tenants' usage patterns. On properly provisioned infrastructure, adding a new tenant with moderate usage has negligible impact on existing tenants because the additional load is absorbed by available capacity. The risk of performance degradation arises when total resource consumption approaches the infrastructure's limits, or when a specific tenant's usage pattern, such as large file uploads, complex search queries, or heavy concurrent editing, creates contention for specific resources. MassiveGRID's monitoring systems track per-tenant resource consumption and overall infrastructure utilization, enabling proactive scaling before capacity limits are reached. Database-level isolation through separate schemas or instances provides an additional safeguard by ensuring that one tenant's heavy queries do not block another tenant's database operations.