Onyx Lite cannot index documents, so a Lite trial tells you nothing about retrieval

The one-line install pipes a shell script into bash

The README's deploy tip is a single command, a pipe into a shell:

curl -fsSL https://onyx.app/install_onyx.sh | bash

Deployment is described as supporting Docker, Kubernetes, Helm and Terraform, with guides for major cloud providers, and the detailed guides are linked out to the deployment overview page.

There is a third option that involves no deployment at all: Onyx Cloud, linked from the same page, for trying the product before committing a cluster to it.

The install script is worth thinking about for a second in a security review, because it runs with your user's privileges on the machine it lands on. A team with a policy against unreviewed remote scripts has to read the script first.

Lite is a chat UI, and it cannot index anything

Onyx ships two deployment options and the difference is not a matter of degree. Standard is the complete feature set, recommended for serious users and larger teams. Lite is described as a lightweight AI Chat UI that requires less resources, under 1GB of memory, runs a less complex stack, and is not capable of indexing documents.

The components that Standard adds over Lite are named: a vector plus keyword index for RAG, background containers running job queues and workers for syncing knowledge from connectors, AI model inference servers for the models used during indexing and inference, and performance work for larger scale through an in-memory cache, Redis, and a blob store, MinIO.

So a Lite trial shows you the interface and the agents and tells you nothing about retrieval, because there is no index behind it. The README positions Lite for testing the UI quickly or for teams interested only in the chat UI and agents, which is an honest framing, but it means the evaluation that matters has to happen on Standard.

The argument against MCP search comes from a project that also serves MCP

The mechanism section makes a pointed claim. Compared with MCP-based searches and index-free approaches, Onyx says it provides more reliable, low-latency, low-cost context for a query whether it is a simple keyword query or a complex research task. The reason given is arithmetic: instead of an agent coordinating and iteratively searching dozens of MCP servers and burning many thousands of tokens, Onyx fetches context across its internal representation instantly and filters down to the most relevant ground truth documents.

And yet Onyx offers an MCP server as an access point, alongside a web and desktop app, a Slack and Discord bot, a Chrome extension and an embeddable widget. The backend dependency list includes `fastmcp==3.4.10`.

The two positions are consistent once you separate protocol from strategy. MCP is how an agent reaches Onyx, and Onyx's own retrieval runs against a prebuilt index inside the deployment rather than as a live round trip to each source. If your objection to MCP search was token cost, that objection does not disappear just because the server answering is Onyx.

Air-gapped means a count of services, not a single container

The security section promises an air-gapped, self-hosted deployment in which the document index, the database and the processing all happen within a self-contained set of services. The phrase to notice is set of services.

Read that against the Standard component list and the deployment is a Postgres-backed application, a Celery queue with workers, a vector plus keyword index, Redis, MinIO, and model inference servers. The Secure Sandbox feature that executes code and holds intermediate artifacts has its own sandbox image (the Makefile has a `craft-sandbox-image` target).

You can also choose the embedding model and the LLM provider, and the README states both can run locally, with Ollama, LiteLLM and vLLM given as the self-hosted options and Anthropic, OpenAI and Gemini as the proprietary ones. If any of those is left pointing at a hosted endpoint, the air gap is not closed, and that choice is per deployment rather than a property of the product.

Python 3.13 or newer, and almost every dependency pinned with ==

`pyproject.toml` sets `requires-python = ">=3.13"`, which is a recent floor and narrows the images you can build from. The shared dependency list then pins nearly everything with an exact `==`: `fastapi==0.133.1`, `pydantic==2.12.5`, `uvicorn==0.49.0`, `litellm[google]==1.100.4`, `openai==2.38.0`, `google-genai==2.18.1`, `cohere==7.0.5`, `voyageai==0.2.3`, `aiobotocore==3.8.0`, `huggingface-hub==1.26.0`.

Two of those are ranges rather than pins: `prometheus_client>=0.21.1` and `agent-client-protocol>=0.7.1`. So a rebuild months from now resolves those two differently from the other fifteen, which is worth knowing before you treat two builds of the same tag as equivalent.

The provider story is layered rather than single. LiteLLM, the OpenAI and Google GenAI clients, Cohere and Voyage AI are all present as dependencies, which fits the README's claim that Onyx supports all major LLM providers.

gpt4all is commented out next to a note about a Python 3.11 image

Inside the `backend` dependency group there is a dependency that is not there. Two comment lines explain why: the GPT4All library has issues running on Macs, and `python:3.11.4-slim-bookworm` will reintroduce this when the library version catches up. The pinned line itself, `"gpt4all==2.0.2"`, sits commented out beneath them.

Two things follow. The local-model path through GPT4All is unavailable in this revision, so a plan that assumed it has to name a different runtime. And the note is stale against the rest of the file, because `requires-python` in the same pyproject is `>=3.13` while the comment is still reasoning about a 3.11.4 base image.

A commented dependency with a stated reason is a good practice, and this one also tells you the project's own threshold for re-enabling a feature. The cost is that the reasoning is tied to a specific base image tag, so the condition for reintroduction has to be re-checked by hand rather than read off the file.

The dev loop runs through kind and kubectl, not Compose

The Makefile's targets are all `craft-*` developer-environment targets. `craft-up` runs `deployment/helm/dev/craft-up.sh` and `craft-down` runs `craft-down.sh`, with `CLUSTER_NAME` defaulting to `onyx-dev` and `NAMESPACE` to `onyx`. Other targets such as `craft-sandbox-image`, `craft-backend-image` and `craft-refresh-images` go through `deployment/helm/dev/dev.py`.

`craft-backend-image` rebuilds the image the in-cluster sandbox-proxy and api-server run, then restarts them, according to the Makefile comment. Contributing therefore assumes a Kubernetes cluster and Helm tooling on the machine, and since the release list includes a `helm/onyx-*` tag, the chart is published from this repository too.

Two editions, and the versions in the files are placeholders

Licensing is split. The Community Edition is free under the MIT licence and covers the core features for RAG, AI Chat, Agents and Actions. The Enterprise Edition adds features aimed at larger organisations, and the split is not cosmetic: SSO through Google OAuth, OIDC or SAML, group syncing and user provisioning via SCIM, role based access control over agents and actions, usage analytics by team, LLM or agent, query history for audit, custom code for removing PII or rejecting sensitive queries, and whitelabeling are all named under the enterprise heading.

The repository's own license field does not resolve to a single identifier, so the README is the place to check what you are getting.

The version numbers need the same scepticism. `package.json` reads `0.0.0-private` and `pyproject.toml` reads `0.0.0`, while the recent tags are v4.9.7 and v5.0.3, with a separate `helm/onyx-0.9.30` for the chart. The files in the tree carry placeholder versions, so the manifest tells you nothing about which release you are looking at.

Editorial conclusion

Onyx is for an organisation that already has identity, a document estate spread across many SaaS tools, and the appetite to run Redis, MinIO, a job queue and model inference servers, because that is what the index costs. Lite is for looking at the interface and nothing more. Verify three things before deploying: that the Python floor in pyproject.toml, `requires-python = ">=3.13"`, matches your images, since a dependency comment in the same file still references a `python:3.11.4-slim-bookworm` base; which edition you need, because the Community Edition is the one under the MIT licence and the Enterprise Edition is a separate set of features; and whether the Lite to Standard jump matches your plan, since Lite is stated to be not capable of indexing documents at all.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes