Kortix vs Onyx: open-source search, or the open-source system that runs the work?

Canonical: https://kortix.com/blog/kortix-vs-onyx

Onyx is an open-source, self-hostable search layer for a company's knowledge, and Kortix is the open-source AI Operating System that runs the work that search surfaces. Both index what your team knows and both run on infrastructure you control. The difference is what happens after a search result appears, when someone has to act on it.

What Onyx gets right

Onyx, the project formerly called Danswer, is a serious retrieval product. Most of what a team wants from search over its own knowledge, it already does.

• It is open source and you can self-host it. The Community Edition ships under the MIT license and covers RAG, chat, agents and actions; the Enterprise Edition adds features for larger organizations. Its latest release is v4.9.0, dated October 2026 (checked October 2026). (Onyx on GitHub)
• Search respects your permissions. Onyx syncs access control lists from the source systems and enforces them at query time, so a person only sees answers sourced from documents they can already open.
• 40+ connectors, indexed in the background. OAuth or an API key, no code to write, and permission sync from Confluence, Jira, GitHub, Google Drive, Gmail, Slack, Salesforce and SharePoint. (Onyx connectors)
• Agents on top of the index. You can build agents with a subset of knowledge, custom instructions and actions through MCP or OpenAPI, plus a sandbox for code and generated artifacts.
• Deployment on your terms. Self-host the open-source build, self-host the Enterprise Edition, or use Onyx Cloud, sold at $20 per user per month on annual billing with Enterprise on a custom contract; the docs describe a two-week managed trial. (Onyx pricing, deployment docs)

Where a search layer stops

Onyx's center of gravity is the index. It finds and answers, and the work that follows a good answer happens somewhere else.

• The product is retrieval. Onyx is built to put the right document in front of a person or a model, fast and cheaply. Its agents retrieve and reason over that context; they do not run a queue of jobs across the company.
• Actions are per-call wiring. Making an agent take a real action means adding an MCP or OpenAPI action and the retrieval that feeds it. No machine stands up for one task, finishes the job and hands back a reviewed change.
• Configuration lives in a product. Connectors, agents and permissions are set in a deployed instance and its admin console. You operate a running app, and there is no single diff to review, branch to cut or repo to fork.
• There is no merge gate for the work. A cross-department job runs through a chat and its actions. Nothing collects the result as a change request that a person reads before it lands.

A search product is not expected to close the ticket. Those four limits only bite once the job changes from finding the answer to acting on it.

What Kortix does differently

Kortix takes the same request and runs it as a job, with agents on machines they hold for the length of the task.

• One repo is the operating layer. Agents, skills, company memory, connectors and triggers are files in one git repo you own, as the Kortix docs describe. kortix.yaml declares the machine image, the connectors and the triggers, so nothing about how the company works hides in a vendor database.
• Every session gets its own cloud computer. One isolated sandbox per session, each on its own branch. Thousands of agents run in parallel on one config, each on its own cloud computer.
• 3,000+ apps through scoped connectors. 3,000+ apps in a click, plus MCP, OpenAPI, Postman, GraphQL and raw HTTP. Connector credentials are brokered server-side and never enter the machine.
• Merge is default-deny for agents. Session work reaches main through a change request, so a person reads the diff before it lands.
• Any model, your keys, your infrastructure. Bring any model provider with your own keys, or the ChatGPT plan you already pay for. Run it on Kortix Cloud, in your VPC, or on your own on-prem network; self-host is free.

An agent and a trigger are ordinary files in the repo:

# kortix.yaml: the company as files
agents:
  support-triage:
    file: agents/support-triage.md
    connectors: all
triggers:
  - slug: daily-digest
    type: cron
    cron: '0 0 9 * * 1-5'
    prompt: Summarize yesterday's tickets and open a change request.

Where Onyx is the stronger pick

If the whole job is index and answer over connected apps, Onyx does it and Kortix does not. Onyx documents a fully air-gapped deployment with no external third parties, the strictest posture a self-hosted product can offer. Kortix runs on-prem, and it is not air-gapped. A team whose only need is a private search layer over its own documents should pick Onyx and stop there.

Side by side

When to pick which

For the closed, vendor-hosted version of this choice, Kortix vs Glean is the counterpart to this one. Two more open-source search-and-chat layers get the same treatment in Kortix vs Open WebUI and Kortix vs LibreChat.

Onyx is a strong open-source search layer, and if finding the answer is the job, it is a good one to keep. When the job is the work that follows the answer, run it on Kortix: one git repo you own, an agent on every task, and a person on every merge. Free to start, free to self-host.