XWiki Multi-Tenancy: Sub-Wikis for Departments and Clients

XWiki Multi-Tenancy: Sub-Wikis for Departments and Clients

As organizations grow, a single wiki space becomes difficult to govern. Marketing wants its own content structure, engineering needs isolated documentation areas, and client-facing teams may require entirely separate portals with distinct branding and access controls. XWiki addresses this through its multi-wiki architecture, allowing a single XWiki installation to host multiple independent wikis that share infrastructure while maintaining logical and security boundaries between them.

How Multi-Wiki Architecture Works

XWiki's multi-tenancy model operates through a main wiki and any number of sub-wikis. The main wiki serves as the administrative hub, housing global user accounts, shared extensions, and configuration that propagates to sub-wikis unless explicitly overridden. Each sub-wiki gets its own content space, its own URL path or subdomain, and its own set of permissions. Under the hood, sub-wikis can share the same database with schema-level isolation or use entirely separate databases, depending on your deployment configuration and isolation requirements.

This architecture differs fundamentally from simply creating separate spaces within a single wiki. Spaces share a common permission model and user directory, while sub-wikis can enforce hard boundaries. A contributor in the Engineering sub-wiki has no implicit access to the Legal sub-wiki unless explicitly granted, and an administrator of one sub-wiki cannot modify the configuration of another.

Creating and Managing Sub-Wikis

Sub-wiki creation is handled through the Wiki Manager application, available to global administrators from the main wiki. The process involves defining a wiki identifier, choosing a URL mapping strategy, and optionally selecting a template wiki to pre-populate the new sub-wiki with structure and content. The key configuration decisions at creation time include:

Template wikis are particularly powerful for organizations that spin up sub-wikis frequently. You can create a template pre-loaded with your company's standard page hierarchy, branded theme, default applications, and permission groups. Each new sub-wiki cloned from this template starts in a ready-to-use state rather than as a blank slate.

User and Permission Isolation

The user directory model is the most consequential architectural decision in a multi-wiki deployment. With a global user directory, users authenticate once and can be granted access to any sub-wiki. This suits internal departmental wikis where employees should be able to discover and request access to other departments' knowledge bases. Group memberships defined on the main wiki can be referenced in sub-wiki permission rules, enabling centralized access governance.

Local user directories, by contrast, create entirely separate authentication domains. A user account on one sub-wiki has no relationship to accounts on other sub-wikis, even if the same person uses both. This model is essential for client-facing deployments where tenant isolation is a contractual or regulatory requirement. Each client logs into their wiki through a dedicated URL and sees no evidence that other tenants exist on the same infrastructure.

Permission granularity within each sub-wiki follows XWiki's standard rights model. You can define view, edit, comment, script, and admin rights at the wiki, space, or page level. Sub-wiki administrators manage their own permission trees without needing global administrator privileges, which supports delegation of governance to department leads or client account managers.

Use Cases in Practice

Departmental wikis are the most common multi-tenancy scenario. Engineering, product, sales, and operations each get a sub-wiki with tailored structure and applications. Engineering might deploy structured data applications for tracking technical decisions, while sales maintains a competitive intelligence library. The main wiki serves as a company-wide portal with cross-wiki search that surfaces relevant content regardless of which sub-wiki houses it.

Managed service providers and consulting firms use sub-wikis as client portals. Each client gets a branded sub-wiki with its own logo, domain, and user base. Project documentation, deliverables, and communication live within the client's wiki, while the provider maintains internal wikis for methodology and templates. This model scales to dozens or hundreds of client wikis on a single XWiki installation, assuming adequate server resources.

A third pattern uses sub-wikis as environment stages. A development wiki serves as a sandbox for testing new extensions and configurations, a staging wiki mirrors production for validation, and the production wiki serves end users. Content and configuration can be exported from one wiki and imported to another, creating a promotion pipeline for wiki content.

Resource Allocation and Performance

Multi-wiki deployments place greater demands on infrastructure than single-wiki installations. Each sub-wiki adds overhead to the JVM heap, database connection pool, and Lucene/Solr search index. Memory requirements scale roughly linearly with the number of active sub-wikis, though idle wikis consume minimal resources beyond their index footprint.

For deployments beyond ten sub-wikis, plan for dedicated database servers and ensure your JVM heap is sized generously. Connection pooling configuration in hibernate.cfg.xml should account for the total number of concurrent sub-wikis rather than just the main wiki's load. Search indexing can be configured per-wiki to avoid reindexing the entire installation when a single sub-wiki's content changes.

Monitoring becomes more important in multi-tenant environments because a resource-intensive operation in one sub-wiki, such as a bulk import or large PDF export, can affect performance across all tenants. Rate limiting, JVM thread pool management, and database query timeouts help maintain isolation at the performance level even when logical isolation is already in place.

Administration Delegation

One of the practical strengths of XWiki's multi-wiki model is the ability to delegate administration without granting global privileges. A sub-wiki administrator can install extensions, manage users, configure permissions, and customize the theme within their wiki, but cannot affect other wikis or the main wiki's configuration. This delegation model reduces the bottleneck on central IT teams and empowers department leads to manage their own knowledge infrastructure.

Global administrators retain oversight through the Wiki Manager, which provides a dashboard of all sub-wikis, their sizes, user counts, and activity levels. This visibility supports capacity planning and helps identify sub-wikis that are underutilized or growing faster than expected.

Multi-tenancy transforms XWiki from a team tool into an organizational platform. Whether you are segmenting departments, serving clients, or managing environments, MassiveGRID's managed XWiki hosting provides the compute, memory, and storage headroom that multi-wiki deployments demand. Reach out to our infrastructure team to architect a multi-tenant XWiki environment tailored to your organization.

MassiveGRID delivers scalable cloud infrastructure for XWiki multi-wiki deployments, with dedicated resources, SSD storage, and proactive monitoring to keep every sub-wiki performing at its best.