Comparison
Gateco vs Onyx
Onyx (formerly Danswer) is an open-source, end-to-end enterprise AI workspace: application, connectors, agents and permission sync in one deployable product. Gateco is the authorization layer for the retrieval stack you build yourself. Different lanes, one overlapping question: who should hold the keys to your knowledge.
Bottom line
If you want an internal assistant out of the box, with connectors and permissions bundled, Onyx is a good one and you should evaluate it. If you have already built your own retrieval, agent or customer-facing product and need to control what it can retrieve from the vector databases you run, you need an authorization layer, and that is Gateco. Policy evaluated on every query, deny-by-default, an audit trail per retrieval, above the vector databases you already run.
| Capability | Gateco | Onyx |
|---|---|---|
| Product category Onyx bundles chat UI, agents and connectors; Gateco is middleware for the stack you build | Authorization layer | AI workspace |
| Works above your own vector databases Onyx retrieves from an index its own connectors populate²; Gateco supports 12 vector and search backends | Yes | No |
| Ships an end-user assistant out of the box Gateco ships no application, by design | No | Yes |
| Open source | No | Yes |
| Access rules evaluated as versioned policy on every query Onyx filters each query against permissions synced into its index, so source-side changes apply after the next sync; Gateco evaluates policies your security team authors and versions | Yes | Synced ACLs, filtered per query |
| Attribute and relationship conditions (ABAC / ReBAC) in retrieval policy Onyx combines permissions synced from sources with group-based access set inside Onyx; Gateco policies are authored and versioned by your security team | Yes (Team plan and up) | Group-based permissions |
| Per-retrieval authorization decision (principal + resource + policy) | Yes | Admin audit log and query history¹ |
| Bring your own embedding model and pipeline Onyx manages indexing inside its deployment | Yes | partial |
| Python + TypeScript SDK for your own application Onyx exposes an HTTP API, a CLI and an OpenAI-compatible gateway for its workspace; Gateco is consumed as a library from code you own | Yes | HTTP API (no first-party SDK) |
| MCP server (Claude Desktop, Cursor) Available on every Gateco plan with a retrieve-scoped API key | Yes | Yes |
| Self-host / on-premises Onyx self-hosting is mature, including offline installs. If self-hosting is a hard requirement today, Onyx fits and we would tell you so | Roadmap, no date | Yes |
| Public pricing Onyx is free to self-host and publishes a per-seat Business price; Enterprise is contact sales | Yes | partial |
OPENSEARCH_HOST and USING_AWS_MANAGED_OPENSEARCH, so the infrastructure can be yours. What the documentation does not describe is pointing retrieval at a vector database you already populated for your own applications, such as Pinecone, Qdrant, Weaviate or pgvector. Source: docs.onyx.app/deployment/local/opensearch, checked 25 September 2026.An application versus an authorization layer
Onyx gives an enterprise a finished thing: a chat interface, agents, connectors into workplace tools, and permission sync, all deployable on infrastructure you control. Its permission-aware retrieval is a feature of that bundled product, and it combines permissions synced from source systems into the Onyx index with group-based access set inside Onyx.
Gateco starts from the opposite assumption: you already have vector databases, an embedding pipeline, and an application of your own. Adopting an assistant does not help you there. What you need is enforcement between your application and your data: policies your security team authors and versions, evaluated on every retrieval against the current principal record, with deny-by-default when nothing grants access and a per-retrieval audit record of who asked, what matched, and which policy decided.
Synced permissions versus live evaluation
The architectural difference with teeth is when access is decided. Permissions synced into an index are correct as of the last sync; identity changes propagate when connectors run again. Gateco decides at retrieval time. A principal deactivated in Gateco, or by SCIM from your identity provider, is refused on the next retrieval, even if the calling application cached its ID. Two carve-outs: an identity provider that Gateco polls is only as current as its last poll, and permissions imported from source systems propagate on sync. Policy changes take effect on activation, and a policy evaluation error denies by default rather than serving content. For regulated data, when the decision happens is as important as what the decision is.
The honest trade in the other direction is deployment. Onyx self-hosting is mature, including offline installs, and Gateco today is a managed service with self-hosting on the roadmap, with no date committed. If running everything inside your own network is a hard requirement right now, Onyx fits that constraint and we would tell you so.
When Onyx is the right answer
- You want an internal assistant your teams can use right away, with connectors and an interface included.
- You need to self-host, including in offline or restricted environments, today.
- You want permissions administered inside the product: group-based permissions, and cloud SSO with domain verification for each tenant.
- You manage infrastructure as code. Onyx ships a Terraform provider, plus AWS and Azure deployment modules.
- You want to see connector health in the product, including stability and credential-capability reporting.
Those are real strengths and we don't pretend otherwise.
Building your own retrieval?
Free plan available. Add a user, define one policy, and see your first denied retrieval. No identity provider sync required on any plan.