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
- What Atlassian Rovo is
- What Rovo costs
- Rovo and Confluence Data Center
- Where Rovo processes data
- The self-hosted alternative has two layers
- AI features of the wikis compared
- The AI layer: Open WebUI, Onyx or a custom RAG stack
- Permissions decide the choice
- Combinations that work
- Where the language model runs
- Rovo and self-hosted side by side
- Our approach at WZ-IT
- 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).
| Component | Function |
|---|---|
| Search | Search across Atlassian products, connected third-party apps such as Google Drive or Slack, and custom websites |
| Chat | Conversations grounded in company data from Atlassian products and connected apps |
| Agents | AI agents that generate content, answer questions and carry out tasks |
| Studio | Workspace for building automations, agents and company hubs |
| Definitions | Context-aware explanations of internal terms and project names |
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. The following table has applied since 31 August 2026. All allowances within an organization are combined into a single shared pool (Atlassian Support, How Rovo credits work).
| Plan | Jira or Confluence | Service Collection or Teamwork Collection |
|---|---|---|
| Standard | 25 credits per user per month | 250 credits per user per month |
| Premium | 70 credits per user per month | 700 credits per user per month |
| Enterprise | 150 credits per user per month | 1,500 credits per user per month |
| Action | Consumption |
|---|---|
| Rovo Search in Atlassian apps, definitions, summaries | no credits |
| Rovo Chat (quick answers), basic agents without model selection | 10 credits per event |
| Think Deeper, agents with model selection, slides, Jira agents | variable |
| Cross-product queries in the Teamwork Graph | typically 1 to 10 credits per call |
| Extra usage beyond the allowance | USD 0.01 per credit (USD 10 per 1,000), billed from 3 Dec 2026 |
Billing for extra usage starts on 3 December 2026, and it 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).
| Item | As of October 2026 |
|---|---|
| Supported versions | Confluence 9.4 and later, 9.2.6 LTS and later |
| Newer connection (application link with OAuth 2.0) | Confluence 10.2 and later or 9.2.22 and later; versions up to 10.1 use the previous application link setup |
| Indexed content | Pages, blog posts, comments, attachments and metadata such as creators, spaces, labels and view counts |
| Where indexing happens | Atlassian Cloud (Teamwork Graph) |
| Prerequisite | Atlassian Cloud subscription with Rovo |
| Permissions | According to Atlassian, users only see content they can access in the source |
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):
| Date | What happens |
|---|---|
| 15 Feb 2024 | End of support for Confluence Server (noted in the Onyx documentation) |
| 30 Mar 2026 | No new Data Center subscriptions or Marketplace apps for new customers |
| 30 Mar 2028 | Last date for existing customers to buy new subscriptions, apps and expansions |
| 28 Mar 2029 | End of life: subscriptions and Marketplace apps expire, instances become read-only |
Affected are Jira Software, Jira Service Management, Confluence and Crowd Data Center. Bitbucket and Bamboo Data Center are excluded; existing customers receive a Bitbucket Hybrid License covering Bitbucket Data Center, Bamboo Data Center and Bitbucket Cloud. 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:
| Layer | Task | Examples |
|---|---|---|
| Wiki | Create, structure and version content, manage permissions | XWiki, BookStack, Docmost, Wiki.js |
| Identities | Central management of users and groups, SSO | Keycloak or the existing directory |
| Index and retrieval | Split, embed and search content, filter by permissions | built into the wiki, Onyx, or Qdrant with a custom pipeline |
| Interface | Chat with source citations | Open WebUI, Onyx, chat inside the wiki |
| Model | Formulate answers | local with vLLM or Ollama, European model API, both behind LiteLLM |
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:
| Wiki | Built-in AI feature | License of the AI feature | Model connection | Permissions in AI answers |
|---|---|---|---|---|
| XWiki | LLM Application with chat and an index for RAG | LGPL 2.1+, requires XWiki 17.4.0 | any OpenAI-compatible endpoint | rights check at retrieval configurable; index entries themselves are visible to all users according to the forum |
| Docmost | Ask AI in the editor, AI Answers in search | Business and Enterprise editions only | OpenAI, Google Gemini, Ollama | AI Answers only searches content the user can see |
| BookStack | none official | - | - | - |
| Wiki.js | none | - | - | - |
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.
| Criterion | Open WebUI | Onyx | Custom RAG stack |
|---|---|---|---|
| License | Open WebUI License (BSD-3 with a branding clause above 50 users) | MIT, ee directories under the Onyx Enterprise License |
depends on the component, e.g. Qdrant under Apache 2.0 |
| Version (as of October 2026) | v0.12.0 of 10 Oct 2026 | v4.9.0 of 7 Oct 2026 | - |
| Wiki connectors | none built in; filled via upload, API or directory sync | Confluence (Cloud and Data Center), BookStack, MediaWiki, Outline and others | a custom sync service per source |
| Permissions from the source | no, access per knowledge base | Confluence permission sync only in Enterprise Edition or Onyx Cloud | taken over at indexing and applied before search |
| Strength | widely used chat interface, many models | connectors, enterprise search across many sources | permissions, retrieval and quality fully configurable |
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:
| Variant | How permissions are handled | Consequence |
|---|---|---|
| Onyx Community with BookStack connector | visibility follows the API user (Onyx, BookStack Connector) | all users see what the API user sees |
| Onyx Enterprise with Confluence connector | space permissions, page restrictions and inherited restrictions are mirrored | source permissions are preserved |
| Open WebUI knowledge base | access per knowledge base, not per document | areas must be set up as separate knowledge bases |
| XWiki LLM Application | filtering of answers by view rights configurable, index entries visible | check before use with restricted areas |
| Docmost AI Answers | searches only visible spaces and pages | wiki permissions apply, license required |
| Custom RAG stack | permissions per document in the index, groups read from the directory at runtime | implementation work, but verifiable |
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:
| Starting point | Wiki | AI layer | Note |
|---|---|---|---|
| One wiki, same read access for all staff | BookStack or Wiki.js | Open WebUI with one knowledge base | least effort, permissions not a factor |
| Modern editor, AI search inside the wiki | Docmost | Docmost AI Answers | Business or Enterprise license, local model via Ollama possible |
| Large installation, structured data, move from Confluence | XWiki | XWiki LLM Application | check index permission behavior first |
| Confluence Data Center stays until 2029, switch later | Confluence Data Center | Onyx Enterprise or custom RAG stack | permission sync only with Enterprise Edition |
| Wiki plus file storage, tickets and DMS, separate areas | any | custom RAG stack with Open WebUI as interface | permissions per document, multiple sources |
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:
| Operating model | Data leaves your own network | Suitable for |
|---|---|---|
| Local model on your own hardware, such as the AI Cube in your own network | no | confidential content, networks without internet access |
| Managed GPU server from WZ-IT with NVIDIA RTX PRO 4000 Blackwell (24 GB) or RTX PRO 6000 Blackwell (96 GB) | to the operator in Germany, not to a model provider | organizations without their own server room |
| European model API | to the API provider | low request volumes, getting started |
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
| Criterion | Atlassian Rovo | Self-hosted combination |
|---|---|---|
| Operation | Atlassian Cloud only | own infrastructure, data center in Germany or own network |
| Billing | credits in the cloud subscription, extra usage USD 0.01 per credit | operation, hardware or model API; no per-request billing with a local model |
| Models | chosen by Atlassian, including OpenAI, Anthropic, Google | freely selectable, local or European API |
| Sources | Atlassian products and Rovo connectors | whatever is connected via connector or custom sync |
| Permissions | from the connected sources | depends on the variant, see above |
| Agents and automation | Rovo Agents and Studio built in | separate tools, own setup |
| Integration effort | low within the Atlassian ecosystem | assembling and maintaining several components |
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.
Still unsure which tool fits? In the wiki selection you try all candidates as demo instances and receive a decision paper with license costs and migration path. From €3,900 excl. VAT, credited against the rollout.
Our approach at WZ-IT
We start with the content and the permissions, not with the tool.
- Assessment. Which wiki in which version, which spaces with which restrictions, which other sources, which directory for users and groups.
- 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.
- Provide or migrate the wiki. XWiki, BookStack, Docmost or Wiki.js, connected to your existing identities.
- 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.
- 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.
- 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
