Atlassian Rovo Alternative, Self-Hosted: Wiki and AI Search You Run Yourself

AI search across your own wiki, without Atlassian Cloud? WZ-IT builds internal AI assistants with source citations and permission checks on top of XWiki, BookStack, Docmost or Wiki.js and runs them on request as part of Managed Open Source. Book a meeting

Atlassian Rovo combines search, chat and agents across Confluence, Jira and connected third-party applications. Rovo exists only in Atlassian Cloud. For organizations that run Confluence on their own servers, this raises two questions at once: Confluence Data Center ends on 28 March 2029, and the AI feature Atlassian positions as the successor to classic search requires a move to the cloud.

Keeping knowledge and documents in your own operation therefore takes two things: a wiki that replaces Confluence, and an AI layer that searches and answers across that wiki without bypassing permissions. The wikis themselves are compared in the posts on open-source Confluence alternatives and BookStack, Wiki.js, XWiki and Docmost. This post covers the AI layer: what Rovo does and costs, which wikis ship their own AI features, and which combinations actually respect permissions. As of September 2026.

Table of Contents

1. What Atlassian Rovo is
2. What Rovo costs
3. Rovo and Confluence Data Center
4. Where Rovo processes data
5. The self-hosted alternative has two layers
6. AI features of the wikis compared
7. The AI layer: Open WebUI, Onyx or a custom RAG stack
8. Permissions decide the choice
9. Combinations that work
10. Where the language model runs
11. Rovo and self-hosted side by side
12. Our approach at WZ-IT
13. Further guides

What Atlassian Rovo is

Rovo is the AI layer of Atlassian Cloud. It builds on the Teamwork Graph, which links content, people and work items from Atlassian products and connected third-party applications (Atlassian Support, What is Rovo).

According to Atlassian, Rovo only shows content the user can already access in the source. Rovo rolled out to Premium and Enterprise plans from April 2025, and Standard plans followed during 2025 (Atlassian Community, rollout for Standard).

What Rovo costs

Rovo is not licensed as a separate per-user product. Usage is billed in credits included in paid cloud subscriptions. All allowances within an organization are combined into a single shared pool (Atlassian Support, How Rovo credits work).

Extra usage is enabled by default. Admins can set a spending cap or turn it off, in which case billable interactions pause once the pool is empty. With 25 credits per user, a Confluence Standard plan covers two chat answers per user per month, search excluded. Organizations that introduce Rovo as a daily tool should budget for extra usage from the start.

Rovo and Confluence Data Center

There is no Rovo for Data Center. There is a connector that transfers content from Confluence Data Center into the Teamwork Graph in the cloud (Atlassian Support, Connect Confluence Data Center).

The connector is therefore not an on-premises Rovo but a bridge to the cloud. Organizations that run Confluence Data Center precisely so that content stays in their own data center achieve the opposite with it.

On top of that comes the timeline for Data Center itself (Atlassian, Data Center End of Life):

Affected are Jira Software, Jira Service Management, Confluence, Bamboo and Crowd Data Center. Bitbucket Data Center is excluded and receives a hybrid license. Atlassian offers extended maintenance beyond 2029 only by exception.

Where Rovo processes data

According to Atlassian, Rovo uses open models, including from the Gemma, GPT-oss, Llama and Nemotron series, as well as third-party hosted models from OpenAI, Anthropic and Google (Atlassian, Rovo security, privacy and data use). Atlassian states that the third-party providers do not retain inputs and outputs or use them to improve their services.

Rovo data residency lets you store Rovo data in the same region as your Jira or Confluence data. It governs storage location. The page does not disclose in which region the models process a request. For organizations with requirements on data processing agreements and third-country transfers, this remains an item to assess, one that does not arise with a self-operated model.

The self-hosted alternative has two layers

Rovo is wiki search, chat and agent platform in one product. In your own operation, this splits into separate building blocks:

The separation has a cost: someone has to assemble the parts and keep permissions consistent across all layers. It has an advantage: each layer is replaceable, and the model can be swapped without touching the wiki. How retrieval-augmented generation works technically is explained in the knowledge article What is RAG?.

AI features of the wikis compared

Two of the four widely used open-source wikis ship their own AI feature. As of September 2026:

XWiki. The LLM Application is developed in the xwiki-contrib project; the version in the repository is 0.10 (tag dated 18 Sep 2026). The index for the LLM Application is marked as beta. A thread in the XWiki forum from September 2025 describes that answers can be filtered by view rights, but that the indexed collections and their entries are visible to all users. This should be checked before use with differently restricted areas. Setup is covered in Setting up XWiki with AI.

Docmost. The AI features require a valid Business or Enterprise license (Docmost, AI). Which other features sit behind the license boundary is shown in Docmost Community vs. Enterprise Edition.

BookStack. The BookStack developer provides BookStack Query, an extension for asking questions of the content, using Chroma as the vector database and an OpenAI-compatible model. It is explicitly labelled as an unofficial customization and, according to its documentation, does not yet enforce permission control: results may include content the user is not allowed to see. For production use with permissions, this is not an option.

Wiki.js has no AI feature. The AI layer always comes from outside.

The AI layer: Open WebUI, Onyx or a custom RAG stack

Where the wiki has no suitable AI feature, or several sources need to be searched together, a separate AI layer is added. Three approaches are common.

Open WebUI is the most widely used self-hosted chat interface. Knowledge bases are filled via upload, the API or by mirroring a directory; for remote sources such as Confluence, the documentation points to the separate tool oikb. The branding clause of the license prohibits removing the name and logo once more than 50 end users access it within 30 days, unless an enterprise license is in place. The comparison with AnythingLLM is covered in Open WebUI vs. AnythingLLM, the connection to Nextcloud with permissions in the knowledge article Connect Open WebUI to Nextcloud.

Onyx (formerly Danswer) comes closest to the Rovo approach: search and chat across many connected sources. The license separates an MIT part from enterprise directories. The Confluence connector supports Data Center and Server; mirroring space permissions and page restrictions, however, requires Enterprise Edition or Onyx Cloud (Onyx, Confluence Connector). Installation and positioning are covered in Onyx self-hosted.

A custom RAG stack consists of sync, vector database, retrieval, model gateway and interface. It is the more demanding route and the only one in which permission checks, search methods and quality measurement are entirely in your own hands. For German-language or technical documents, this includes hybrid search and reranking and a sound chunking strategy.

Permissions decide the choice

A Confluence instance with space permissions and page restrictions usually has areas that not everyone may see: HR, management, contracts, customer projects. An AI search that ignores these boundaries will, within the first month, quote something it should not. The variants differ precisely here:

The principles are described in the knowledge article RAG with permissions: permissions are applied before search, not as a filter on the result, and group memberships come from the directory service rather than from a copy taken at indexing time.

Combinations that work

Wiki, AI layer and permission model yield a small number of sensible combinations:

The last row is the situation Rovo is built for: one search entry point across several systems. In your own operation, it is also the most demanding. Connecting further sources such as Nextcloud, SharePoint or a DMS is covered in the knowledge article RAG with Nextcloud, SharePoint, and DMS. Whether guided access to curated content fits better than an open chat is discussed in Chatbot or knowledge navigator?.

Where the language model runs

The wiki content stays in your own operation. What remains open is where a request, together with the retrieved text passages, goes to have the answer written. Three operating models:

Which European APIs exist and how they differ in location, contract and model selection is compared in European LLM APIs compared. How much GPU memory a model needs is explained in the article on VRAM sizing for LLMs. A model gateway such as LiteLLM allows switching between these routes without changing the interface.

Rovo and self-hosted side by side

For an organization that works entirely in Atlassian Cloud, Rovo is the obvious route. The self-hosted combination is the route for organizations that run Confluence on-premises precisely because of data location and do not want to reverse that decision for AI search.

Our approach at WZ-IT

We start with the content and the permissions, not with the tool.

1. Assessment. Which wiki in which version, which spaces with which restrictions, which other sources, which directory for users and groups.
2. Target design. Does the wiki stay or is it replaced, and which AI layer fits the permission model. Are the required features in a free or a licensed edition.
3. Provide or migrate the wiki. XWiki, BookStack, Docmost or Wiki.js, connected to your existing identities.
4. Build the AI layer. As an internal AI assistant with Qdrant, LiteLLM and Open WebUI, permissions applied before search, every answer with document and passage.
5. Measure quality. With test questions from your own content before the assistant is released. The process is described in RAG evaluation. For a bounded first knowledge area there is the RAG Proof of Value.
6. Operation. Updates, backups and monitoring of wiki, index and model, on your hardware, on the AI Cube or on a managed GPU server. Support, consulting and implementation by WZ-IT.

Further guides

• Open-source Confluence alternatives, Docmost, BookStack and Wiki.js as a replacement for the wiki itself.
• BookStack, Wiki.js, XWiki or Docmost, licenses, structure and feature limits compared.
• Setting up XWiki with AI, connecting the LLM Application to a local model.
• Onyx self-hosted, installation and comparison with Open WebUI.
• European LLM APIs compared, when the model should not run locally.
• AI solutions from WZ-IT, hardware, model operation and assistants at a glance.

Confluence on-premises and AI search anyway? We assess wiki, AI layer and permission model and build the combination on your infrastructure or in our operation. Book a meeting

Sources

• Atlassian, Data Center End of Life
• Atlassian Support, How Rovo credits work
• Atlassian Support, What is Rovo
• Atlassian Support, Connect Confluence Data Center to Teamwork Graph
• Atlassian, Rovo security, privacy and data use
• Atlassian Community, Rovo is now rolling out for Standard customers
• XWiki LLM Application on GitHub
• XWiki forum, permissions of LLM Application index entries
• Docmost, AI
• BookStack Query on Codeberg
• Open WebUI, Knowledge
• Open WebUI, License
• Onyx, License
• Onyx, Confluence Connector
• Onyx, BookStack Connector