Webinar overview | Don't book a demo. Start managing your knowledge in Cloud

Technically, IP restriction can be possible, but it depends on the XWiki Cloud offer and setup.

IP allowlisting is an infrastructure-level requirement, so it should be confirmed with the XWiki Support team before choosing or configuring your offer. If your organization cannot expose the instance to the general internet, raise this requirement early so the team can confirm which XWiki Cloud offer is eligible, or whether a custom/private deployment or self-hosted setup would be more appropriate.

The standard XWiki Cloud offer is hosted in France on OVHcloud infrastructure. XWiki also uses Scaleway in France for encrypted backup redundancy and cold storage solutions.

This setup supports GDPR-aligned deployments and European data sovereignty requirements. XWiki Cloud also benefits from a security and compliance framework that includes automated backups, proactive monitoring, antivirus scanning, regular security maintenance, and hosting infrastructure with recognized certifications including ISO 27001.

If your organization requires data residency in Canada, the UK, or another specific country, discuss this with the XWiki team early in the evaluation process. Organizations with stricter internal policies or regulatory requirements can also deploy XWiki on their own infrastructure, which gives them full control over hosting, access management, integrations, and data residency.

XWiki remains open source, and self-hosting remains an important deployment model.

XWiki is a free and open-source platform available for download on xwiki.org. You can install it on your own infrastructure and adapt it to your needs. This includes extensive customization options, collaborative editing, document management, structured content, and granular rights management.

Self-hosting has always been central to XWiki's approach. XWiki SAS, the main sponsor of the XWiki open-source project, has been driving its development for more than 20 years. We continue to support self-hosted deployments because we believe organizations should be free to choose where and how they run their knowledge management platform.

XWiki Cloud is there for teams that want a managed option, with hosting, maintenance, backups, upgrades, and support handled by XWiki. It does not replace the self-hosted version.

The strength of XWiki is that you are not locked into one deployment model, as you can learn from our complete guide on hosting. You can run XWiki in Cloud, on premises, in a private cloud, or on infrastructure chosen by your organization, while still benefiting from professional services provided by XWiki SAS.

Definitely. Starting with XWiki Cloud does not lock you into Cloud forever.

XWiki is open source, and your data can be exported and moved to another XWiki environment if your needs change.

This is one of the key differences between XWiki Cloud and locked-down SaaS tools. XWiki Cloud gives you managed hosting, maintenance, backups, monitoring, security maintenance, and support, but it does not force you to stay on one deployment model permanently.

Yes, XWiki Cloud includes daily automated backups as part of the managed service.

The security and compliance page also mentions proactive monitoring, antivirus scanning, regular security maintenance, continuous infrastructure monitoring, centralized logging, encrypted backup redundancy, cold storage solutions, and tested restoration and disaster recovery procedures.

This is one of the main reasons teams choose XWiki Cloud: They can start using XWiki without managing hosting, backups, upgrades, monitoring, and maintenance themselves.

XWiki gives you granular rights management, so you can create separate areas inside the same wiki and control access through users, groups, and permissions. For example, one section can be restricted to internal users, while another can be opened to a wider community.

The first thing you may want to do is configure an access policy for your wiki. Depending on what you intend to use your wiki for, you have 2 options. The first one is to configure your wiki to be public, so that people can edit and comment without necessarily being registered or logged in. The second one is to limit the access only to registered users, by configuring a private wiki.

If you need stronger separation between internal content, customer-facing content, and public information, subwikis or a dedicated deployment model may be a better fit.

XWiki provides granular rights management at different levels, including wiki-level rights and page-level rights.

You can control what users or groups are allowed to do, such as view, edit, comment, delete, administer, or manage content. Page-level rights can override broader wiki-level permissions, which gives teams flexibility when they need to protect specific sections, pages, or page trees.

In practice, we usually recommend managing permissions through groups rather than assigning rights user by user. It is easier to maintain, especially when your team grows or when people change roles.

Yes. Subwikis can be used to create dedicated spaces for specific audiences, such as customers, partners, departments, or projects.

Access rights can be managed through users and groups. This makes subwikis useful when you need stronger separation than a simple page tree, especially for customer-facing or partner-facing spaces.

Regarding licensing, the number of users is determined by the number of accounts listed in the XWiki user directory. Customer or external users who have accounts in the wiki are therefore counted as XWiki users. If you have a specific external access model in mind, it is best to confirm it with the XWiki team so the plan matches your use case.

While Confluence and XWiki do not have identical structures, the separation provided by spaces can be achieved through trees of parent and child (nested) pages or subwikis. Nested pages are useful when you want to structure related content inside the same wiki. Subwikis are useful when you need stronger separation, for example between business units, customers, or security domains. You can learn more about the difference between subwikis and nested pages in the XWiki documentation.

In Confluence there are page restriction rights at space level. This right is converted to admin rights in XWiki, for the page tree corresponding to the Confluence space in XWiki. This means that all users having page restriction right but not admin rights on Confluence will end up having admin rights for the corresponding page tree in XWiki.

For many teams, page trees are enough. Subwikis should be used when there is a real need for separation, not just because a space existed in Confluence.

XWiki supports nested pages, so child pages can also have child pages.

From a usability point of view, the better question is how deep the structure should go before it becomes hard to browse. A very deep hierarchy can make content harder to find, so it is worth designing the structure around how people actually search, browse, and maintain information. You can learn more about the relations between pages in the XWiki documentation.

A good structure is usually clear, predictable, and not too deep. Users should be able to understand where they are, where to create new content, and where to find existing pages.

Start from how people look for information, and how they navigate through pages.

Manuals and how-tos often work well when grouped by topic, process, product, department, or audience. Templates should usually have their own clearly identified area. For recurring business information, such as accounting principles, procedures, or internal records, structured pages can help keep the content consistent and easier to update.

The goal is not to create the perfect tree from day 1. The goal is to make the first structure clear enough that people know where to create, find, and maintain content.

The XWiki Cloud demo shown during the webinar was preloaded with sample content and pages to help demonstrate XWiki features and capabilities.

When you start a XWiki Cloud trial, however, you receive a blank instance that you can populate directly with your own content and structure. You are also free to install and test any extensions you would like to evaluate during the trial period. Customize your wiki by selecting from our collection of extensions that can be installed on top of XWiki. Mix and match according to your needs and build the perfect platform for your team.

When converting a Cloud demo into a production instance, you can keep all the data and configuration from the trial environment. Or you can start fresh with a clean instance and rebuild your structure from scratch.

This flexibility allows teams to experiment during the evaluation phase. It also gives them time to decide whether to continue with the trial content or start fresh in a new production environment.

Templates are predefined pages that are copied when creating a new page.

This means that changing a template affects future pages created from that template, not the pages that already exist. Existing pages keep the content that was generated when they were created.

If you need structured templates that update everywhere when changed, the App Within Minutes feature is a better approach.

Files stored in SharePoint can be migrated to XWiki using the Batch Import community extension, as demonstrated in this SharePoint migration guide.

Alternatively, you can convert office files into XWiki pages, using the Office import core feature.

For larger migrations, it is important to consider factors such as file volume, metadata, permissions, folder structure, and how users are expected to find and use the content. Depending on your goals, some documents may simply be migrated as files, while others may be converted into wiki pages to make them easier to edit, link, and maintain collaboratively.

The best migration approach depends on whether you want XWiki to serve primarily as a document repository, a knowledge base, or a combination of both.

Yes. During the webinar, we showed how Office documents can be converted into XWiki pages so they become editable wiki content, through the Office import feature.

XWiki can also work with files and documents through extensions and applications, including office-related integrations and PDF viewing. The best approach depends on whether you want to convert a file into a page, keep it as an attachment, or display it inside XWiki.

Yes, Markdown syntax support is available in XWiki.

Markdown content can be imported into wiki pages, and XWiki can also support creating wiki content in Markdown. The best approach depends on whether you want to keep Markdown as the editing format, convert it into XWiki syntax, or store Markdown files as attachments.

There is also support for GitHub-Flavored Markdown syntax through another extension.

Yes. Redirects can help preserve links when content is moved, renamed, merged, or reorganized.

This is especially useful when cleaning up duplicated content. Instead of leaving users with broken links, you can redirect them from the old location to the new consolidated page.

This depends on what you mean by sync, and it should not be treated as a standard Cloud feature.

Syncing pages, attachments, users, configuration, extensions, and full environments are different needs. XWiki has tools and extensions that can support replication or data movement in some scenarios. However, a Cloud-to-self-hosted synchronization setup should be scoped carefully before being used in production.

For example, the Replication Application can help share data between XWiki instances and demonstrates wiki page replication. However, using replication between XWiki Cloud and a self-hosted instance is not something we would present as a standard Cloud capability without technical validation from the XWiki team.

This depends on the replication setup and what you need to replicate.

The XWiki documentation explains that full page replication can include the page content, class, objects, and attachments. However, configuration, extensions, users, environment-specific settings, and infrastructure-level state are separate concerns and may require additional planning.

For production use, especially between Cloud and self-hosted environments, it is important to validate exactly what is replicated, what is not, and what still needs to be managed manually or through another process.

Yes, XWiki can support high-availability deployment scenarios, but this is not part of the standard XWiki Cloud offer. It should be treated as a custom architecture project.

For a self-hosted or custom deployment across 2 data centers, the architecture needs to account for the database, file storage, clustering, Solr, upgrades, backups, monitoring, failover, recovery expectations, and operational maintenance.

For this type of setup, we recommend discussing the architecture with the XWiki team so the deployment matches your performance, resilience, and maintenance requirements.

If you want to test the features of XWiki, you can try XWiki in Cloud. This is by far the simplest to try XWiki since you don't need to install anything.

If you want to explore the features, or test new versions in a non-production environment, the following installation methods are highly recommended:

• Install a standalone (demo) distribution: Provides a built-in XWiki, with a portable database (HSQLDB) and a lightweight Java container (Jetty).
• Use an official XWiki Docker image: Provides an easy solution to test XWiki, without manually installing or configuring a servlet container.

Search works best when the content is well structured.

Clear page titles, consistent templates, useful metadata, tags, and a clean hierarchy all help. XWiki also uses Solr search, which can be configured and extended for more advanced needs, including facets and filtering based on structured data.

In other words, good search is not only a search engine topic. It also depends on how the knowledge base is designed. The more consistent your content is, the easier it becomes for users to find the right information.

Adoption works best when XWiki becomes part of the team's real workflow, as reliable internal or external documentation.

Start with useful templates, clear ownership, practical onboarding, and content people actually need. Avoid launching an empty wiki and expecting users to figure it out alone. Give people a clear reason to come back: procedures, project knowledge, meeting notes, policies, documentation, or answers they need in daily work.

It also helps to define who owns which type of content and when pages should be reviewed. A knowledge base becomes reliable when updating it is part of the work, not an extra task nobody owns.

XWiki can interact with external databases and display the retrieved information inside wiki pages. But this is typically implemented through custom development or extensions rather than as a standard XWiki Cloud feature.

XWiki includes a Query Module that allows developers to execute queries against XWiki's own database and, when properly configured, against additional data sources. Combined with XWiki's scripting capabilities, structured data model, and application framework, this makes it possible to build pages, dashboards, reports, or business applications that display information coming from external systems.

For many use cases, however, XWiki's own structured data model may be a better fit than connecting directly to an external database. XWiki can store structured information through objects and properties, then display it through pages, forms, lists, and custom views without requiring a separate database integration. In fact, many teams use these capabilities to build lightweight business applications such as directories, inventories, project trackers, or knowledge management tools. With XWiki's App Within Minutes, these types of applications can often be created in... minutes.

If you need to read data from MySQL, MS SQL Server, or another external database, this should be treated as a custom integration project. The implementation details matter: read-only versus write access, authentication, network connectivity, hosting model, performance, maintenance, and security all need to be considered. For XWiki Cloud deployments in particular, external database connectivity should be discussed with the XWiki team to validate feasibility and security requirements.

XWiki can model structured information through classes, objects, properties, forms, and views.

This is one of the things that makes XWiki different from a simple document-only wiki. A page can contain text, but it can also carry structured data that can later be displayed, searched, filtered, or reused.

It is not a direct clone of Airtable or Notion, but it can support similar structured knowledge use cases when you need more than plain text pages. For example, you can create AWMs for procedures, contacts, assets, project records, client information, internal directories, or other reusable business records.

Yes, you can choose to create a page through the change request workflow or without it. The Change Request extension allows you to request changes on a page without publishing them right away: People have to approve the changes to publish them.

It can be used where review and approval are needed, while other areas can keep a regular editing workflow. Also, it can be complemented by Change Request Replication, an extension which ensures that all events coming from Change Request are properly replicated whenever the page is subject to changes is itself replicated.

XWiki Pro includes supported business applications, connectors, and professional support on the core product from XWiki SAS (a full support contract).

These applications extend XWiki with features for collaboration, productivity, content creation, organization, file management, diagrams, office integrations, and authentication. They are designed to help teams go further than a standard wiki setup, without having to build every feature from scratch.

Some applications, specifically Pro Apps, can be purchased individually, if you intend to benefit from support only on certain features, such as authentication through Active Directory, Diagrams or many others.

Yes, XWiki can be used as a knowledge source for AI or RAG scenarios, but the integration should be designed carefully so that permissions, data access rules, and hosting constraints are respected.

The LLM Application is currently available as a beta extension and can provide an LLM chat assistant. In combination with the Index for the LLM Application, it can also provide answers based on wiki content or other indexed content.

The Index for the LLM Application supports indexing content from existing wiki spaces when explicitly configured. This is important because AI access to knowledge should not be treated as a general "index everything" shortcut. The setup should reflect what content should be used, who can access it, and where the AI service is hosted.

XWiki will also soon launch an MCP application, separate from the LLM App.

Yes, users can be imported using dedicated authentication applications such as Active Directory (with LDAP user import), Entra ID, or other OIDC providers. This depends on the method and user management setup.

Since user management can involve authentication, groups, rights, subwikis, and provisioning rules, the best approach should be confirmed based on your setup.

If you need to add or manage hundreds of users programmatically, we recommend discussing the exact method with the XWiki team so it matches your authentication and access model.