Glean vs Onyx: which enterprise search to run

Glean vs Onyx: when each fits

Glean fits when you want the vendor to run the platform and you would rather not carry upgrades, patching and monitoring yourself. Onyx fits when you need the raw logs, the choice of model by cloud or on-premises hardware, or a network that cannot reach a vendor-managed control plane. The decision is less about search quality than about who operates the stack for the next several years. Glean's Hosted model runs on Google Cloud, and its Customer Hosted model, formerly called Cloud-Prem, runs in your own GCP or AWS account. In both, Glean stays responsible for infrastructure and application management, including upgrades, patching and monitoring. If your team values a single party accountable for uptime and version currency, that division of labor is the main reason to stay with Glean, and it should be weighed against the fact that manual changes to Customer Hosted deployments are not supported.

Self-hosted Onyx fits when the operating model is the requirement. Onyx documents an air-gappable deployment in which the document index, database and processing run in a self-contained set of services, deployable with Docker, Kubernetes, Helm or Terraform, and it works with self-hosted models through Ollama, LiteLLM or vLLM. Onyx Community Edition is MIT licensed, but code in the ee directories falls under the Onyx Enterprise License, so confirm which features your team needs before you assume they are open. Your team, or a partner you engage, then controls patch timing, query history and the model endpoints. Confirm with Onyx which audit and query history fields are exposed in your edition, because the answer determines whether your security team can reconstruct who asked what.

Before choosing, decide four things. First, who patches: Glean's vendor or your own engineers, and on what schedule. Second, who can read logs: whether your security team needs raw query and access logs outside the vendor's tooling. Third, which models are required: a specific model in a specific cloud region, or a model running on your own GPUs. Fourth, whether you can staff operations, including Postgres, the index service, Redis and model servers, with on-call coverage. If the first answer is the vendor and the rest are unclear, Glean is the lower-risk choice. If any of the other three is a hard requirement, run a scoped pilot with Onyx before the renewal date.

Which option fits which scenario

This table maps common operating conditions to the option that usually fits better, so you can start from your constraints rather than from either product. Read each row as a condition to test in your own environment, then confirm the fit with your team and the vendor. The main takeaway is that managed delivery favors teams without platform engineers, while self-operated Onyx favors teams that need log access, model control or isolation.

Scenario	Better fit	Condition that drives the choice
No dedicated platform engineers	Glean Hosted or Customer Hosted	Glean remains responsible for infrastructure and application management, including upgrades and patching. Self-hosting Onyx requires someone or a partner to own those tasks.
Regulated bank needing raw logs	Onyx operated by your team or partner	Confirm whether your auditors need raw application and query logs in your own storage. Onyx lists query history auditing, but log retention and export must be designed and verified in your environment.
Specific cloud-hosted model required	Depends on model availability in your cloud	Check which models Glean's Model Hub offers in your cloud region. Onyx connects to Anthropic, OpenAI, Gemini, Ollama, LiteLLM and vLLM, so confirm the model is reachable from your account.
Air-gapped network	Onyx with self-hosted models	Glean's Customer Hosted model still runs in GCP or AWS under Glean's management. Onyx documents an air-gappable deployment, but indexing and update workflows must be tested offline.
Team already runs Kubernetes	Onyx, deployed with Helm or Kubernetes	Onyx is deployable with Docker, Kubernetes, Helm or Terraform. Your team must still own Postgres, the search index, Redis and model servers as stateful services.
Need to control upgrade timing	Onyx operated by your team	Glean schedules upgrades for both hosted models. With Onyx, your team sets the version and the change window, and must track releases and the Helm chart.
Need connectors for Microsoft and Google sources	Compare connector coverage source by source	Onyx lists connectors for SharePoint, OneDrive, Outlook, Teams, Google Drive and Gmail. Confirm each source, its permission sync and any Glean-only connectors you rely on.

Where data lives and who controls the environment

Glean and Onyx differ less in features than in who operates the environment that holds your documents, indexes and logs. The cards below cover location, hosting, identity and compliance evidence, the four places where that difference shows up in daily operations and in audits.

Data location and tenancy

Glean Customer Hosted runs in your own Google Cloud or AWS account, but the data plane is still a Glean-managed application. Glean Hosted runs on Google Cloud under Glean's account. With Onyx, the index, database and processing services run wherever you deploy them, including an air-gappable network. Ask Glean which account, region and key management service hold each data store, and confirm whether the index and any cached content leave the region you choose.

Operational control and changes

In both Glean models, Glean is responsible for infrastructure and application management, including upgrades, patching and monitoring, and manual changes to Customer Hosted are not supported. With Onyx, your team or your partner decides when to upgrade, which configuration to change and how to roll back. That control also means your team carries the on-call and patch burden. Write down who approves an upgrade and who performs the change before you compare the two.

Identity, SSO and permission sync

Onyx supports SSO through Google OAuth, OIDC or SAML, SCIM user provisioning and role-based access control in its Enterprise Edition, and it syncs source permissions so answers only use documents the user can already see. Glean offers its own identity and permission model across its connectors. Map each source system's permissions to your identity provider, test a user who was removed from a group, and confirm that SCIM deprovisioning reaches the search index in both products.

Logs and audit evidence

Glean's logs and audit records are exposed according to its product tier and contract, so confirm with Glean whether you can export raw query, access and admin logs to your own SIEM. Onyx lists query history auditing and usage analytics among its enterprise features, and because the deployment is yours, logs stay in the systems you administer. Compliance evidence for an assessment, such as access reviews and change records, is produced by your team. Independent auditors perform any audit and issue any report.

Glean and Onyx capability comparison

This table compares the capabilities that matter most in a renewal decision, with Glean's documented deployment model on one side and Onyx's documented features on the other. Where Glean's public materials did not settle a point, the cell says to confirm it with Glean before you compare. The main takeaway is that Onyx's controls depend on which edition and deployment you choose, so check those choices against your requirements.

Capability	Glean (Hosted or Customer Hosted)	Onyx (self-hosted)
Who patches and upgrades	Glean remains responsible for upgrades, patching and monitoring in both hosted models	Your team or partner schedules upgrades and patches; releases and the Helm chart are published publicly
Deployment options	Glean Hosted on Google Cloud, or Customer Hosted in your GCP or AWS account	Docker, Kubernetes, Helm or Terraform in your environment, or Onyx Cloud as a managed option
SSO and SCIM provisioning	Confirm with Glean which identity protocols and SCIM provisioning it supports for your directory	Google OAuth, OIDC or SAML for sign-in, plus SCIM user provisioning
Role-based access control	Confirm with Glean how roles and permissions are assigned and whether they match your source systems	RBAC is listed as a Enterprise Edition feature that you run in your own environment
Usage analytics and query history auditing	Confirm with Glean whether analytics, query history and raw log export are available to your team	Listed among enterprise features; confirm the edition and the log export path before relying on it
Connector coverage	Confirm the full connector list and permission sync behavior for each of your sources with Glean	Over 50 applications with permission sync; repository includes SharePoint, Confluence, Jira, Slack and others
Model choice by cloud	Confirm with Glean which models are offered in each cloud and whether you can bring your own	Self-hosted models via Ollama, LiteLLM or vLLM, plus Anthropic, OpenAI and Gemini providers
Air-gapped deployment	Customer Hosted still runs in GCP or AWS under Glean management, so confirm whether any isolated option exists	Documented as air-gappable, with the index, database and processing running in self-contained services
Licensing	Commercial subscription; confirm license terms, seat counting and model usage commitments with Glean	Community Edition is MIT licensed; code in ee directories falls under the Onyx Enterprise License

Who patches and upgrades Glean and Onyx

Under Glean Hosted and Glean-managed Customer Hosted, Glean is responsible for upgrades, patching and monitoring of the application and its infrastructure. Glean's deployment documentation states this for both models, and Customer Hosted, which runs in your own GCP or AWS account, still does not accept manual changes from your team. The practical consequence is that your upgrade calendar follows Glean's release schedule, and your security team's main levers are the timing of cutover conversations, the scope of connectors you enable, and the evidence Glean provides about what changed. Before renewal, ask Glean in writing which release cadence applies to your tenant, how advance notice of upgrades is given, whether you can defer a release, and how security patches are handled outside the normal cycle.

With Onyx, the upgrade decision sits with your team or the partner operating the stack. Onyx publishes its releases on GitHub, and the current release at the time of writing is v4.9.2, released October 15, 2026, with a Helm chart at version 0.9.17 as of October 16, 2026, according to the Onyx releases page. Your operators choose when to move to a new release, pin versions in staging, and rerun the connector tests that matter most to you, such as permission sync for SharePoint, Confluence or Slack, before promoting a change to production. Confirm the current release and chart version directly on the releases page when you plan, because these values change. Keep a named owner for security advisories, a test environment that mirrors production connectors, and a documented rollback path.

The trade is vendor-timed upgrades against your own change windows. Glean removes the operational burden of patching and monitoring, but you accept its timing and have limited ability to test a release against your exact connector mix before it lands. Onyx gives you control over timing and validation, and it also makes your organization responsible for the work that Glean currently performs. Budget for staff who can read release notes, run upgrades on Docker, Kubernetes or Helm, monitor the database, index and model servers, and respond to security patches on a predictable schedule. Many organizations cover part of this with a retainer from a partner, which should be scoped in writing with explicit responsibilities for patch windows, testing, and emergency response.

Raw logs and model choice by operating model

Glean Hosted runs on Google Cloud, and Glean operates the infrastructure and application layers, including upgrades, patching and monitoring. Your team does not hold the underlying servers, so raw logs and query history reach you only through the export or admin reporting that Glean provides under your contract. Review the Glean deployment models page before you set expectations with your security team.

Log access: Confirm with Glean whether query history, admin activity and audit events can be exported in raw form, and in what format and retention window.
Cloud placement: The hosted service runs on Google Cloud, so the region and account boundary follow Glean's deployment, not your own cloud accounts.
Model providers: Confirm which model providers and versions Glean offers under your contract and whether your team can choose among them.
Model changes: Glean schedules model and platform updates as part of the managed service. Ask for the notice period and whether you can test a new model before it reaches production users.

Ask Glean for written answers on log export, model options and change notice before you compare them with the Onyx option.

What drives the cost of each option

Glean and Onyx bill different things. Glean's cost is mostly a contracted subscription and usage commitment, while a self-hosted Onyx cost is spread across infrastructure, models, connector upkeep and people who run the stack. Read each card as a question to put to both vendors and to your own team before comparing totals.

Glean subscription and usage commitments

Glean's cost sits in the contract: the per-user license for its suite and any Model Hub usage commitment. Both are recurring and set at renewal, so the cost moves with headcount, the modules you buy and the usage you commit to. Ask in writing which components are included in Customer Hosted, what the cloud infrastructure charges are and who pays them, and what happens to unused commitment at renewal.

Onyx infrastructure components

Self-hosted Onyx runs on Postgres, Vespa or OpenSearch for the index, Redis, model servers and object storage. These are mostly recurring cloud or hardware costs that scale with document volume, index size and query load. Ask your team or partner to size each component separately and to state which parts are needed for the Onyx Lite or Onyx Standard deployment you choose.

Inference cost on the chosen model

Model usage is a separate line in both options. With Glean, model access is typically tied to the commercial agreement. With Onyx, you pay your model provider per token for hosted models such as Anthropic, OpenAI or Gemini, or you pay for GPUs when you run Ollama, LiteLLM or vLLM yourself. Usage grows with the number of questions and the size of retrieved context, so pilot real query volume before fixing a budget.

Connector setup and maintenance

Each source system needs a connector, its permission sync configured and monitored, and updates when the source changes its API or permission model. Setup is largely one-time effort, while maintenance recurs. With Glean, confirm which connectors are included and who builds custom ones. With Onyx, the connectors directory covers SharePoint, Confluence, Jira, Slack and others, but your team or partner owns configuring, testing and repairing them.

Enterprise Edition licensing

Onyx Community Edition is MIT licensed, but features in the ee directories fall under the Onyx Enterprise License. Features such as RBAC are part of the self-hosted Enterprise Edition, which is a recurring license cost you incur only if you need those features. Ask Onyx for the written license terms, the seat or deployment basis for pricing, and whether support is included.

Operations staff or partner support

Someone must patch, upgrade, back up and monitor a self-hosted Onyx deployment, and that effort is usually the largest recurring cost. It can come from your own platform team, from a managed Onyx Cloud contract, or from a partner under a retainer. Ask any partner for a fixed-scope written proposal covering upgrade cadence, on-call hours, backup testing and who responds to incidents, and compare that with the upgrade and support terms in your Glean contract.

Glean vs Onyx on connectors and permission sync

The first question on connectors is simple: which of your sources must answer queries, and does each one arrive with its permissions intact? Onyx connects to more than 50 applications and syncs their permissions, so an answer only draws on documents the user can already see in the source system. The repository includes connectors for SharePoint, OneDrive, Outlook, Microsoft Teams, Google Drive, Gmail, Confluence, Jira, Slack and Salesforce, among other sources. Build your list from your own estate first, then match each entry against the connectors directory on GitHub rather than assuming coverage from the headline count.

Coverage for Glean has to be checked the same way, against your own source list, in writing. Ask Glean to confirm, for each source, whether the connector syncs document-level permissions, group membership and deletions, how often it re-syncs, and whether any source needs a custom build. Do not treat a vendor's list of supported applications as proof that your specific tenant configuration, nested groups or shared drives will behave as expected. The same question applies to Onyx: a connector listed in the repository still needs to be tested against your tenant, your authentication model and your permission structure.

Verify permission behavior per source before the pilot. Pick a test user in each access group, then confirm with a document that the user can open in the source but has never seen in search, and another that the user should not see. Repeat the check after removing a user from a group and after deleting a document, because sync lag and stale entries are where leaks usually appear. On the Onyx side, connector setup, credential rotation, version pinning and re-indexing after source schema changes are recurring costs that your team or your implementation partner carries, so put them into the staffing estimate alongside inference and hosting.

What a move from Glean to Onyx involves

The sequence turns Glean's managed search into an Onyx deployment your team controls, with permissions, connectors and model choices proven on real queries before the Glean contract is retired. Each phase closes with a written output, so the cutover decision rests on evidence rather than on a demo.

Inventory sources, permissions and Glean usage
List every source Glean indexes today, including the owner, the sync scope and how each source grants access, such as group membership or per-document sharing. Pull the admin configuration and usage reports Glean provides, and record which teams depend on the assistant and which agents or actions they use. Your team does this with the Glean admin and the source system owners. It is done when you have a signed-off source register with a permission model for each entry and a list of agents to recreate.
Design the environment and identity model
Decide where Onyx runs, in your own cloud account or data center, and which deployment shape fits: Onyx Standard with its index, background workers and model servers, or Onyx Lite for a lighter chat and agents footprint without a vector database or background workers. Confirm how users will sign in through Google OAuth, OIDC or SAML, and whether SCIM provisioning will drive group membership. Confirm with Onyx's current deployment documentation which features your edition includes, including role-based access control, which is listed among the Enterprise Edition features. It is done when the architecture, network paths and identity mappings are written down and approved by security.
Select models that meet your residency rules
Choose the model providers for chat and embeddings. Onyx supports self-hosted models through Ollama, LiteLLM and vLLM, and proprietary providers such as Anthropic, OpenAI and Gemini. Where data may not leave your boundary, self-hosted models are the path; where a hosted provider is acceptable, confirm the terms and the region for that provider's data handling. Ask your provider and Glean to confirm what data each model call sends. It is done when each use case has a named model, a hosting location and a data handling statement you can cite.
Build connectors and test permission sync
Stand up the connectors for each source in the register, using the connectors Onyx includes, such as SharePoint, OneDrive, Google Drive, Confluence, Jira, Slack and others, and check whether any Glean source has no equivalent that you would need to build or accept as a gap. For each connector, test with at least one user from each access group that the document-level permissions match what the source system shows. Record failures and fix them before going on. It is done when every connector has a passing permission test log and each gap is recorded with an owner and a decision.
Run a pilot group on real queries
Select a pilot group that uses Glean daily and let it run the same questions on both systems for a fixed period set in your plan. Collect real queries from the Glean query history where your admin settings allow it, and score answers for relevance, source accuracy and whether each result respects the user's access. Include the agents you intend to recreate. Run the pilot before the Glean renewal date, so the results can change the renewal decision. It is done when the team has a scored comparison, a list of failed queries with causes, and a go or no-go recommendation.
Cut over users and agents
Move the pilot group to Onyx first, then the remaining users in groups, with the Glean connectors kept active until the group has confirmed its workflows work. Recreate the agents and actions that the pilot validated, and publish a short guide for users on where to ask questions. Keep the Glean instance readable during this window so users and admins can check old answers. It is done when all user groups are on Onyx and the agent inventory is marked as migrated or retired.
Retire Glean connectors and admin roles
Disable Glean's connectors to each source, revoke the service accounts and tokens that Glean used to read source systems, and remove Glean admin roles. Confirm in writing with Glean how your data is deleted under your contract terms, and keep the admin logs and any evidence your compliance program requires. Your security team removes the access and reviews the source audit logs for the Glean service accounts after removal. It is done when the source systems show no active Glean access and the deletion confirmation from Glean is on file.

Questions buyers ask before choosing Glean or Onyx

Can our team run Onyx without outside help?

Yes, if your engineers can operate containers, a relational database, a search index and model servers. Onyx documents deployment with Docker, Kubernetes, Helm or Terraform, and its standard stack includes Postgres, Vespa or OpenSearch, Redis and model servers. The harder part is not the first install but the ongoing work: upgrades, patching, backups, connector credentials and monitoring fall to your team unless you contract them out. Confirm with the Onyx deployment documentation which components your chosen tier needs, then decide whether your platform team has the time to own them.

What staffing does a self-hosted Onyx stack need?

Staffing depends on how many components you run and how much you want to own. A typical split covers platform engineering for the containers and cluster, a data or search owner for the index and connectors, an identity administrator for SSO and SCIM provisioning, and someone accountable for model endpoints, whether self-hosted through Ollama, LiteLLM or vLLM or a proprietary provider. Smaller deployments may use Onyx Lite, which drops the vector database and background workers. Ask any partner to map each function to a named role in a written scope.

What drives the cost of running Onyx compared with Glean?

Glean's cost is a subscription plus any usage commitments, while self-hosted Onyx replaces the subscription with infrastructure, model inference, connector setup, operations time and any Enterprise Edition license you choose. The main drivers are the number of indexed sources, document volume, query load, the model you choose and whether it runs on your GPUs or a hosted API. Costs recur monthly for compute and staff, and the setup and migration work is one-time. Ask Glean for its written pricing terms, and ask any partner for a quote built from a written scope, not an estimate.

Does Glean Customer Hosted remove the need for operations?

No. Glean's documentation states that in both Glean Hosted and Customer Hosted models, Glean remains responsible for infrastructure and application management, including upgrades, patching and monitoring. Customer Hosted runs in your own GCP or AWS account, so the data location and cloud account are yours, but the operational control sits with Glean. Your team still owns cloud accounts, identity, network access and business decisions. If you want your own team to schedule upgrades and see raw logs, you need to plan for an operated stack like Onyx rather than assume Customer Hosted gives you that control.

Which Onyx features require the Enterprise Edition?

Onyx's README lists SSO through Google OAuth, OIDC or SAML, SCIM user provisioning, role-based access control, usage analytics and query history auditing among its enterprise features. Onyx also describes a self-hosted Enterprise Edition with premium features such as RBAC. Community Edition covers RAG, AI chat, agents and actions under the MIT license. Before you assume a feature is free, check which edition it sits in using the Onyx README and the deployment documentation, since the boundary between editions can change between releases.

How does Onyx Community Edition licensing differ from the Enterprise License?

Community Edition code is MIT licensed, which permits commercial use, modification and redistribution under the MIT terms. Code in the ee directories is governed by the Onyx Enterprise License instead, so you need to read that license before using or modifying those files in production. Legal teams should review the Onyx LICENSE file alongside their own procurement rules, because the split between the two is defined by directory and may matter for audits, forks and internal distribution. This is a licensing question for counsel, not a technical one.

Can Onyx run in an air-gapped network?

Onyx documents an air-gappable, self-hosted deployment in which the document index, database and processing run within a self-contained set of services. It can work with self-hosted models through Ollama, LiteLLM or vLLM, which keeps inference inside your network. Confirm three things before committing: that every container image and model weight can be mirrored into your environment, how connector syncs behave without outside network access, and how updates are imported. Your security team should test these paths in a pilot rather than rely on the README alone.

What should we ask a partner for in a fixed-scope quote?

Ask for a written scope that lists each platform component, each connector with its permission model, the model providers and hosting for inference, identity integration, environments, backup and restore responsibilities, and the acceptance tests for search quality. Ask which items are one-time, such as installation, connector mapping and migration, and which recur, such as support, upgrades and testing retainers. Request the assumptions behind each line, the change process if scope grows, and the named deliverables. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and prepares evidence for compliance assessments but does not issue audit reports or certifications.

How DeployOpen helps you decide and move

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Glean vs Onyx, we start with a written scope that shows which operational responsibilities would move to your team or partner and which would stay with the vendor.

How we scope

Inventory the connectors and permission sources your Glean deployment searches today, source by source
Define which Onyx model host, cloud region and deployment model fits your residency and logging requirements
Agree who patches, upgrades and monitors the stack, and document that split in the written scope before work starts
Engagements are fixed-scope, with deliverables and timelines agreed in writing; ongoing support is available as a retainer

How we build

Deploy Onyx with Docker, Kubernetes, Helm or Terraform in your own account, matching your infrastructure standards
Connect permission-synced sources such as SharePoint, Google Drive, Confluence and Slack, and test that answers respect each user's access
Configure SSO through Google OAuth, OIDC or SAML and provisioning through SCIM, then confirm role-based access control settings
Test answer quality on a sample of real queries from your pilot group and record where results differ from current Glean use

How we hand over

Deliver runbooks covering upgrades, backups, index rebuilds, connector maintenance and access reviews for your operators
Document where query history and usage analytics are stored and how your team exports them for audit
Walk your staff through Onyx Community Edition and any Enterprise Edition components, including license obligations you must track
Provide a written record of configuration, data flows and test results for your internal and external reviewers

How we support

Offer retainers for upgrades, patching, continuous security testing and connector changes after go-live
Run security testing of the deployed application, its APIs and its connectors before users rely on it
Prepare systems, controls and evidence for compliance assessments; independent auditors issue any attestation
Agree support levels and response expectations in the retainer rather than assuming them

Glean vs Onyx