Onyx self-hosted: AI search over SharePoint, Teams and Confluence, and the GPUs it needs

Self-hosted enterprise search over the systems you already use

Onyx, the open-source project formerly called Danswer, is an AI search and chat platform that indexes the systems a company already uses, such as SharePoint, Teams, Confluence, Google Drive and Jira, and answers questions with links to the source documents. Self-hosted on premises, the index, the chats and the language model run on your own hardware, with the model served by vLLM or Ollama. A pilot for one department runs on a workstation with one NVIDIA RTX PRO 4500 Blackwell or RTX PRO 5000 Blackwell; a company of a few hundred people needs a server with NVIDIA RTX PRO 6000 Blackwell Server Edition cards.

This guide is for IT teams that have looked at Glean or Copilot for search over SharePoint and Confluence and want the index and the model on their own servers. It covers what each Onyx edition does with document permissions, what the connectors index, what stays on the server, and the hardware from a pilot to 2,000 employees. The concepts behind retrieval and permissions are in our guide to RAG on company data, and a chat-first stack with Open WebUI is in our private ChatGPT alternative.

As of 30 October 2026 the GitHub repository shows 32.9k stars and the project is actively developed; version 5.0.0 of 24 October removed Vespa according to its release notes, so the index now runs on OpenSearch. Of the two deployment modes, Lite is "a lightweight AI Chat UI" that "is not capable of indexing documents". This guide is about Standard, "the complete feature set".

Which Onyx edition carries SharePoint and Confluence permissions

The LICENSE file puts everything outside the ee directories under the MIT (Expat) licence. Content in the ee directories is "licensed under the Onyx Enterprise License". The paid features are switched on with ENABLE_PAID_ENTERPRISE_EDITION_FEATURES, which the Docker Compose template introduces with the line "Enterprise Features, requires a paid plan and licenses".

Onyx README, LICENSE file, Enterprise Edition page, permissions page and MCP server guide, read on 30 October 2026.

The difference matters more than any hardware choice. Onyx's permissions page states that on the Community Edition "a document is visible to its connector's creator and to everyone when the connector is public". The free edition does not carry SharePoint or Confluence permissions over, so it suits content that every Onyx user may read, such as a handbook, product documentation or an intranet. Sources with restricted folders need the paid edition, or a separate installation per audience.

With permission sync, Onyx reads the access rights from the source and applies them at search time, which is where our guide to RAG on company data says they belong. The SharePoint and Teams pages name the "Business and Enterprise tiers on Onyx Cloud" and "the Enterprise Edition when self-hosted" for it; the licence comes from Onyx. We set up the Community Edition as Onyx publishes it, and a paid edition only on a subscription you hold with Onyx. Two details from the documentation matter before a pilot. The matching runs on e-mail addresses, and the Teams page notes that a mismatch leaves threads visible to no one. And since 5.0.0 the documents of a connector with permission sync stay hidden from everyone until its first sync has run, as the release notes put it, "fail closed while a connector waits for its first permission sync".

You can order the server alone, the setup of Onyx, vLLM and the models alone, or both together: the server delivered with everything installed and configured; write to us and we suggest the best solution for your tasks and budget.

What the SharePoint, Teams and Confluence connectors index

Onyx's connector overview lists 56 connectors in eight categories. By default each one refreshes every 30 minutes and is pruned of deleted documents every 7 days. Sixteen connectors support permission sync, among them Google Drive, Confluence, Jira, SharePoint, OneDrive, Teams, Outlook and Slack. The three sources in the title behave as follows.

Onyx connector pages for SharePoint, Teams and Confluence Data Center and the connector overview, read on 30 October 2026.

SharePoint. The connector reads files in document libraries, including images inside them, and published site pages. It does not index SharePoint lists, their items or their attachments, and skips files over 20 MB. The legacy formats .doc, .xls and .ppt "are not supported", so archives from older Office versions need converting first. Indexing needs only the Sites.Read.All permission and a client secret; permission sync needs a certificate. Document permissions sync every 30 minutes and memberships every 5, and self-hosted installations can change both intervals. The page describes a tenant with SharePoint Online and says nothing about SharePoint Server on-premises, so check that with Onyx before you plan on it.

Teams. Each channel thread becomes one document, from standard, private and shared channels. Channel files, meeting transcripts and meeting chats are options; files need certificate authentication, and transcripts need settings in the Teams admin centre. One-to-one chats and other chats outside channels and meetings are not described as indexed, and transcripts and chat days older than six months are skipped.

Confluence Data Center. Onyx signs in with a personal access token, which Data Center and Server 7.9 or later provide. Permission sync reads space permissions and page restrictions, needs the Enterprise Edition and an account with Confluence admin or space admin rights.

File shares. The overview lists no connector for SMB file shares, Nextcloud or WebDAV. Files from a share can still be uploaded with the File Upload connector, but then without the share's permissions. If your documents live in Nextcloud, its own assistant may fit better, as our guide to Nextcloud Assistant with a local LLM explains.

What stays on your server

With a self-hosted embedding model and a language model on your own model server, the OpenSearch index, the document copies Onyx keeps for re-indexing, the chat history and every prompt stay on your hardware. Two settings decide that. Onyx's index settings page says cloud embedding models "run on the provider's servers: Cohere, OpenAI, Google, or Voyage", and that Onyx then sends document text and search queries to that provider. The same applies to the language model: point Onyx at a cloud API and the retrieved passages go with every question.

The source systems do not move. SharePoint Online, Teams and Confluence Cloud stay where they are, and the Onyx server reads them over their APIs, so it needs outbound access to those services. Web search, one of Onyx's features, sends queries to the search provider you configure. The Compose template also has a DISABLE_TELEMETRY variable in its logging and telemetry section; decide on it before the first start, as our article on telemetry in self-hosted AI tools does for vLLM and the rest of the stack. For sites without internet access the README describes Onyx as "air-gappable".

Onyx hardware requirements from a pilot workstation to two servers

An Onyx server carries three loads. The Onyx services and OpenSearch run on the processors. Two model servers, one for indexing and one for queries, run the embedding model, and the index settings page recommends a GPU on the indexing model server for large document sets. The language model runs on its own model server, vLLM or Ollama, and takes most of the GPU memory.

For the language model we use our users-per-card rule, the same as in our guide to how many users one RTX PRO 6000 serves: 90 per cent of the memory the driver reports, minus 3 GiB per card, minus the weights, leaves the KV cache for conversations. That gives 25.7 GiB on a 32 GB RTX PRO 4500, 40.0 GiB on a 48 GB RTX PRO 5000 and 83.0 GiB on a 96 GB RTX PRO 6000. Employees are converted into conversations in flight with the example values of our guide to a private ChatGPT server by company size: 40 per cent active in the busiest hour, six requests each, 30 seconds per request and a peak factor of two.

Our estimates by the users-per-card rule at 32K tokens, gpt-oss with a 16-bit cache, Qwen3.8-27B with an FP8 cache (1.14 GiB per conversation); gpt-oss-20b 12.8 GiB, gpt-oss-120b 60.8 GiB and Qwen3.8-27B FP8 28.7 GiB of weights as in our guides to 30B models on 24 GB cards and Qwen hardware requirements; staff tiers from our sizing guide by company size.

Pilot. gpt-oss-20b, Apache 2.0, has 13.8 GB of weights, about 12.8 GiB, and needs 0.75 GiB of cache per 32K conversation, so the RTX PRO 4500 keeps about 17 at once by our estimate. Qwen3.8-27B in Qwen's FP8 version, a larger dense model, leaves room for about 9 on the 48 GB RTX PRO 5000 with an FP8 cache of 1.14 GiB per conversation. For a pilot with a few sources the embedding model can run on the processor; Onyx's index settings page shows for each model how many documents it embeds per minute on one core.

About 100 employees. gpt-oss-120b, about 65 GB (60.8 GiB) of weights, fits one 96 GB card with room for about 19 conversations of 32K. The second card takes the embedding models and a small task model. Every RTX PRO 6000 edition can be split into up to four 24 GB MIG instances under Linux, as our guide to RTX PRO 6000 MIG profiles explains. A workstation takes two RTX PRO 6000 Workstation Edition or Max-Q cards; for a service the whole company depends on, a rack server with two Server Edition cards is the better place. By our estimate a two-card Max-Q workstation draws about 1.1 kW at the wall and the two-card server about 1.8 kW.

500 and 2,000 employees. These rows follow our sizing guide by company size: two servers, so that either one carries the peak alone, with a small L4 or L40S for the embedding model. At 2,000 employees each server runs two copies of gpt-oss-120b, each split across a pair of cards; the cards have no NVLink, so a split copy should be load-tested at the expected peak before it goes into production.

Processors and RAM follow Onyx's resourcing page. Standard needs at least 4 vCPU, 10 GB of RAM and "32 GB + ~2.5x indexed data" of disk; Onyx prefers 8 or more vCPU, 16 GB or more and 500 GB of disk for organisations under 5,000 users. OpenSearch grows with the documents, from about 2 GB of memory per GB of source documents below 5 GB to 1 GB above 50 GB, and the page's example of 10 GB of text needs about 19 GB of memory and 4.5 CPU for OpenSearch alone. The servers on our AI servers page start at 384 GB of DDR5 for two cards, enough for a large index next to the models.

We build these workstations and servers to order; send us your sources and your headcount and we suggest the best solution for your tasks and budget.

First full index and re-indexing

Onyx publishes no GPU throughput for its model servers, so time the first full run of one source and extrapolate from it. The figures in our guide to embedding and reranker servers, such as about 5.8 hours for 3 million chunks on one L40S, come from NVIDIA's NIM containers and do not transfer to Onyx's own model server.

Three changes trigger a full re-index, according to the index settings page: "A new embedding model, a new vector quantization, and turning on contextual retrieval". The re-index rebuilds from the documents Onyx already stores, without fetching them from the sources again, and on large indexes it can take hours or days. OpenSearch holds the old and the new index during the run, so plan disk space for both; Onyx deletes the old one about a day after the switch. Choose the embedding model for German and the other languages of your documents before the first full run. Onyx accepts a custom Hugging Face embedding model on its model servers, so a multilingual model can be tested on a sample of your own questions first.

Onyx or Open WebUI

Both connect to the same vLLM server, and they solve different problems.

Onyx documentation, read on 30 October 2026; Open WebUI as in our private ChatGPT alternative guide.

Choose Onyx when the knowledge lives in SharePoint, Teams, Confluence and Jira and changes daily, and when people may only see what they can open in the source. Choose Open WebUI when the main use is chat and the documents fall into collections with one audience each. For a scanned paper archive, Paperless-ngx with a local AI is the better tool, and for one team's document chat, AnythingLLM. The two can also work side by side. Onyx's MCP server "is available on all editions", is enabled by default in the bundled Compose files and Helm chart, and offers a search_indexed_documents tool to MCP clients such as Claude Code and Codex, where "document permissions and workspace policies still apply". Our guide to MCP server security covers what to check first.

Installing Onyx and connecting a local model

The documented Docker route: clone the repository, change into deployment/docker_compose, run cp env.template .env, set the variables and start with docker compose up -d; the web interface answers on port 3000. The current permission system needs Onyx 4.7 or later, and because 5.0 changed the index backend, read the release notes before upgrading a 4.x installation.

The language model is added in the admin panel on the OpenAI-Compatible card: the API base URL of your vLLM server, its key, and the models, which Onyx reads from the server's /v1/models route and tests before it saves the provider. vLLM's --api-key protects only some of its routes, so let only the Onyx host reach the vLLM port, as our guide to vLLM security advisories explains. Our Private AI/ML service deploys models on your servers with vLLM or Ollama and builds assistants that cite the source; whether Onyx applies the access rights of the source systems depends on the edition, as described above.

FAQ