Onyx

Last reviewed Aug 26, 2026 · 875 words

Onyx needs 8 GB of RAM before you have indexed a single document, and about 6 GB of that is Vespa, the search engine underneath it. Hold that number against the alternative: a personal "chat with my documents" tool like AnythingLLM runs in under 2 GB. The difference is the product. Onyx is not a document chat toy; it is a search and assistant platform that continuously syncs 40+ sources (Slack, Google Drive, Confluence, Jira, GitHub, Notion, websites, file uploads), respects who is allowed to see what, and answers questions with citations across all of it. For a team of 10 or more with knowledge scattered across 4 tools, that is the whole job. For one person with a folder of PDFs, it is a data centre for a bookshelf.

The name changed in 2024, the code did not

The project launched in 2023 as Danswer and renamed to Onyx in late 2024, moving the repository to the onyx-dot-app GitHub organisation and the Docker images to the onyxdotapp/ namespace. Everything written about Danswer's architecture still applies; older compose files mostly need image names swapped. The catalogue also carries a legacy Danswer entry for people arriving via the old name. The license is MIT for the core, with a separate ee/ directory of enterprise features (some SSO providers, advanced permission syncing, usage analytics) under a different license, which is what the "some features enterprise-only" note refers to.

What the compose stack actually contains

Onyx is 8 services in the standard deployment/docker_compose setup: a Next.js web frontend, a FastAPI API server, a background worker for indexing, Postgres for metadata, Vespa for hybrid vector and keyword search, Redis for queues, a model inference server for embeddings, and Nginx tying it together on port 80. The hybrid search is the reason for Vespa rather than a lighter vector store: Onyx combines keyword matching with embeddings, which is what makes it find an exact ticket number as reliably as a vague description of a problem. It is also the reason the resource floor is what it is; Vespa is built for billions of documents and does not scale down politely.

Realistic sizing for a small company: 8 GB is the floor to boot, 16 GB is comfortable for a few hundred thousand documents, and the initial indexing of a large Google Drive will run for hours on 4 cores. Plan the first index for an evening.

Connectors are the product, so audit yours first

Before installing, list the 3 sources where your team's real answers live. If two of them are Slack and Google Drive, Onyx is a strong fit; those connectors are mature and incremental, polling for changes on a schedule you set per connector. If one of them is a wiki behind an odd authentication scheme, check the connector list on the Onyx documentation site before committing, because a source Onyx cannot sync is a source your assistant will confidently not know about. The web crawler connector covers many gaps for public or internal docs sites, and the file upload connector handles the one-off PDF pile.

Model choice: hosted API for quality, Ollama for privacy

Onyx talks to any OpenAI-compatible endpoint plus the major hosted providers directly, configured in the admin UI rather than environment files. For answer quality, a hosted frontier model remains noticeably better at synthesising across 10 retrieved chunks. For a "no company data leaves the building" policy, point it at Ollama running a 14B or larger model on a GPU box; the embeddings already run locally by default, so the LLM is the only outbound call to close. The middle path many teams take is local embeddings and search with a hosted model for generation, which means the provider sees the retrieved snippets but never the corpus.

Permissions are the reason to choose it over a chat UI

Open WebUI with a document collection will answer questions over files. What it will not do is remember that the finance folder is visible to 4 people. Onyx models users, groups and document sets, and the enterprise tier syncs source permissions (who can see which Drive folder) so search results honour them. Even on the open core, the role-based access control is enough to keep a shared assistant from leaking a salary spreadsheet to the whole company, and that is the feature that separates a company knowledge tool from a demo. If the search and permission layer is more than you need, the lighter document-chat tools are the better fit.

What I'd do

For a company of 10 to 200 people with knowledge in Slack, Drive and a wiki, I'd run Onyx on a 16 GB VM, connect those 3 sources first, use local embeddings with a hosted model for generation, and give the admin role to exactly one person. I would not install it for personal use or for a team of 3; AnythingLLM or Open WebUI with a documents folder gets there in a tenth of the RAM. Onyx is the most complete open-source answer to Glean, and completeness is what you are paying 8 GB for.