There's a specific class of problem that keeps coming up for teams I talk to: they want the capabilities of a ChatGPT Enterprise or Glean — deep document search, custom agents, web-connected answers — but they can't send their internal knowledge base to a third-party cloud. Or they want fine-grained control over which LLM backs each workflow. Or they just don't want to pay per-seat for something they could run themselves. Onyx is the most complete open-source answer to that problem I've encountered. It's a self-hosted AI platform — not just a chat UI wrapper — with genuine RAG, agentic retrieval, 50+ knowledge connectors, code execution, deep research, and a full enterprise access control layer, all under an MIT license for the community edition.
What Makes Onyx Different From a "Chat UI"
A lot of projects bill themselves as self-hosted AI platforms but are really just a thin wrapper around the OpenAI API with a nicer interface. Onyx runs a legitimately complex stack that earns the "platform" label. In standard mode, you get:
- Hybrid vector + keyword index — the foundation of its RAG pipeline. Not just semantic search, but a combined index that handles both fuzzy meaning-matching and exact-term retrieval. This is why RAG quality is meaningfully better than naive embedding-only approaches.
- Agentic information retrieval — instead of a single retrieval pass, Onyx can run multi-step agent loops that refine queries, chase references, and synthesize across multiple document passes before returning an answer.
- Background sync workers — connectors to Confluence, Notion, Google Drive, Slack, GitHub, Jira, and 40+ others run as background jobs, keeping your index fresh without manual re-indexing.
- Deep Research mode — a multi-step research flow that topped the project's own published leaderboard benchmark as of February 2026. It produces structured reports, not just chat answers.
- Code execution sandbox — agents can actually run code to analyze data, render charts, or manipulate files — not just generate code snippets.
- MCP support — beyond the built-in connectors, Onyx agents can interact with external applications via MCP, with configurable auth options.
Two Deployment Modes: Lite vs. Standard
Onyx makes a sensible architectural split that I appreciate. Onyx Lite strips out the vector index, background sync workers, and ML inference servers. It runs under 1GB of memory and is genuinely useful as a team chat UI with custom agents — think a self-hosted, LLM-agnostic alternative to Claude.ai for internal use. If you don't need RAG over your own document corpus, Lite gets you running in minutes.
Standard Onyx is the full picture: vector + keyword index, connector sync queues, Redis for in-memory caching, MinIO for blob storage, and AI model inference servers for the deep learning models used during both indexing and inference. It's a real production stack. Deploy it and you have something that genuinely competes with enterprise knowledge management tools — but running on your own infrastructure, against your choice of LLM.
The one-command deploy is real:
curl -fsSL https://onyx.app/install_onyx.sh | bash
That gets you a Docker Compose stack. For production use, Onyx also ships Kubernetes manifests, Helm charts, and Terraform configs with cloud provider guides for AWS, GCP, and Azure. The deployment story is more mature than most open-source projects at this scale.
LLM Flexibility Is a First-Class Citizen
Onyx supports every major LLM provider without locking you in. On the proprietary side: OpenAI, Anthropic, Google Gemini, Cohere, and others. On the self-hosted side: Ollama, LiteLLM, and vLLM. You can route different agents or workflows to different models — a lighter model for quick lookups, a heavier one for deep research — which matters enormously once you're thinking about cost at scale. This is a detail that distinguishes Onyx from tools that claim multi-model support but treat it as an afterthought.
Custom Agents and the Knowledge Connector Ecosystem
The custom agent builder lets you define agents with specific instructions, restricted knowledge sources (so a "Legal" agent only searches the legal document index), and available actions (web search, code execution, MCP tool calls). This is closer to how real teams want to work — not one omniscient AI, but purpose-scoped agents with appropriate access — than a single chat interface with all your docs dumped into it.
The 50+ connectors cover the tools most engineering and knowledge-work teams actually use: Confluence, Notion, Google Drive, Slack, GitHub, Linear, Zendesk, Salesforce, Jira, and many more. Connectors run as background sync jobs, which means your agents query a live index rather than stale snapshot embeddings. There's also a web crawler and Firecrawl/Exa support for indexing external web content.
Enterprise Features in the Community Edition vs. EE
The MIT community edition covers the full core: RAG, agents, actions, connectors, code execution, web search, voice mode, image generation, and artifacts. The enterprise edition adds SSO (Google OAuth, OIDC, SAML), SCIM-based user provisioning, RBAC, usage analytics broken down by team and model, query history auditing, custom code hooks for PII removal or query filtering, and whitelabeling. For a solo developer or small team, the CE is genuinely complete. For an organization that needs audit trails and SSO, the EE tier exists and is priced accordingly.
Rough Edges and Limitations
- Standard mode is not lightweight. Redis, MinIO, background workers, a vector database, and ML inference servers add up. You need real infrastructure — a single-node deploy of standard Onyx on a modest VPS will struggle. Budget at least 8GB RAM and meaningful CPU before expecting smooth performance.
- Connector freshness depends on your sync config. Connectors run on schedules. If your team is making rapid document changes, there's an inherent lag between a new document appearing in Confluence and it being queryable in Onyx. This is a design tradeoff, not a bug, but it matters for use cases where real-time accuracy is critical.
- The web UI is feature-rich, which means there's a learning curve. Custom agents, connector management, index configuration, MCP setup — there's a lot of surface area. Budget time for onboarding your team.
- Deep Research mode quality depends heavily on the LLM you route it to. The benchmark results were presumably achieved with frontier models. Running Deep Research against a small local Ollama model will produce noticeably weaker output. Manage expectations accordingly.
- No native mobile app. Voice mode exists but it's browser-based. For teams that want a native mobile experience, this is a gap.
The Practical Case for Self-Hosting This
The argument for running Onyx yourself comes down to three things: data sovereignty (your documents never leave your infrastructure), LLM flexibility (swap models without migrating to a new platform), and cost structure (pay for compute, not per-seat SaaS). For a 20-person engineering team that wants agents trained on their internal Confluence, Slack, and GitHub — and doesn't want that data processed through a third-party cloud — Onyx is the most production-ready open-source path I know of. The fact that you can start with Onyx Cloud to evaluate it without deploying anything, then move to self-hosted when you're ready, makes the adoption path reasonable.
Internal link suggestion: link "RAG pipeline" or "hybrid vector + keyword index" to a future DevTools post covering a dedicated vector database or embedding tool — a post on Qdrant, Weaviate, or pgvector would pair naturally here.