Why Glean Customer Hosted may not give you the control you need
If your goal is to keep search data and day-to-day operations under your own control, the main alternative to Glean's Customer Hosted model is a self-hosted Onyx deployment that your team or a partner operates. Customer Hosted runs in your own GCP or AWS account, but Glean remains responsible for infrastructure and application management, including upgrades, patching and monitoring, and manual changes are not supported. This page compares the two on four decisions: data residency, log access, upgrade timing and staffing. Every comparison rests on documented facts, and where a fact is missing we say what to confirm with Glean or in your own environment.
Start by mapping what you need from each decision. For residency, confirm where the index, the database and the model calls run, and whether any of those components leave your account or region. For logs, ask Glean exactly which query logs, access logs and administrative events you can export, and in what format. For upgrade timing, ask who chooses the version and when, and what your change window looks like. For staffing, list who would patch, monitor and restore the stack if Glean were not doing it. Onyx Community Edition is MIT licensed and covers RAG, AI chat, agents and actions, but code in the ee directories falls under the separate Onyx Enterprise License, so check which features your requirements depend on before you plan around them.
The rest of this page works through these decisions in order, using only the facts we can source. Treat any answer you cannot verify in writing as an open item in your evaluation, not as a yes.
What the control requirement actually demands
Control over a Glean Customer Hosted deployment is shared with Glean, while an Onyx deployment your team operates keeps those decisions inside your own change process. The six requirements below cover where data lives, who changes the system, what logs you can reach, who patches it, and how permissions travel into answers.
Where data is stored and processed
Customer Hosted runs in your own GCP or AWS account, so the storage location is your cloud account, but the operating control sits with Glean. Confirm which regions and services hold the index, model calls and logs, and which of those Glean's managed operations can reach. With Onyx, the document index, database and processing run inside services you deploy, and you choose whether model inference is a hosted API or a self-hosted model through Ollama, LiteLLM or vLLM.
Who can change the running system
Glean's documentation states that it remains responsible for infrastructure and application management in both of its models. Glean's Customer Hosted model does not support manual changes to the running environment, so any tuning, network rule or custom integration has to go through Glean. An Onyx deployment is changed by your team through its Docker, Kubernetes, Helm or Terraform definitions, which means your change tickets and code reviews are the record of what changed.
Access to logs and query history
Ask Glean in writing which audit logs, query records and infrastructure logs are delivered to your account, in what format, and how long they are retained. Onyx lists usage analytics and query history auditing among its enterprise features, and the Enterprise Edition is needed for the premium controls, so confirm which of these your chosen edition includes before you rely on them for investigations. Both paths should be tested with a sample incident before the renewal decision.
Who applies patches and upgrades
Under Glean's Customer Hosted model, Glean applies upgrades, patches and monitoring, which removes the work from your team but also sets the timing. Ask for the notice period, the rollback path and whether you can defer a release for a regulated change window. Onyx publishes its own release cadence and Helm chart versions, so your team picks when to move to a new version. Onyx v4.9.2, released October 15, 2026, is one example of a version your staff would test and adopt on their own schedule.
Keeping user permissions in answers
An assistant is only safe for a regulated group if an answer draws only on documents the asking user can already open in the source system. Onyx connects to more than 50 applications and syncs their permissions, and it supports SSO through Google OAuth, OIDC or SAML with SCIM provisioning. Test this with a restricted document in each connected source, and confirm with Glean how its permission sync handles group changes and deleted users.
Who holds the operating knowledge
Customer Hosted reduces the number of platform engineers you need, but the people who understand the environment sit with Glean's operations team. Onyx moves that knowledge to your staff or to a partner you contract, which means you need someone who can run its Postgres, index, Redis and model server components. Ask who would be on call for an outage, how runbooks are shared, and what happens to the environment if the service relationship ends.
What Customer Hosted does and does not change
Glean's Customer Hosted model, formerly called Cloud-Prem, changes where the stack runs, but not who runs it. The services run in your own GCP or AWS account, which can meet residency requirements at the account and region level. Glean, however, stays responsible for infrastructure and application management, including upgrades, patching and monitoring, as described in Glean's deployment model documentation. Before you rely on residency as the main reason to stay on this model, confirm with Glean exactly which data stores, indexes, caches and logs sit inside your account and which, if any, are handled by Glean-managed components.
Manual changes are not supported, and that single rule shapes everything else. Your team cannot hand-tune the infrastructure, patch a service ahead of Glean's schedule or edit running configuration and expect it to survive. Change control therefore becomes a request process: you ask for a change, Glean schedules it, and your internal approvals follow Glean's release calendar. Upgrade timing is set by Glean's release cadence. Ask for the maintenance window structure, how security patches are classified and scheduled, whether you can defer a release, and how long a version remains supported for your deployment.
Logs and incident response are where the vendor-held control shows up most. Ask which logs land in your account, whether they can be forwarded to your SIEM in real time, what retention applies, and whether Glean's operators can access the environment and under what approval. Ask how an emergency change is made and recorded. With a self-hosted Onyx deployment, your team sets the change calendar, holds the administrative keys and decides retention, but it also owns the patching, monitoring and upgrade testing that Glean performs today. Weigh that staffing load honestly against the control you gain.
Which open-source options fit a customer-operated search deployment
This table compares Onyx Community Edition, Onyx Enterprise Edition, Onyx Cloud, Open WebUI, LibreChat and AnythingLLM against the control, residency, licensing and connector needs that drive a Glean Customer Hosted decision. Read each row against your own permission model and connector list, since the main takeaway is that only Onyx covers permission-aware enterprise search across company sources.
| Option | Residency, control and licensing | Connector coverage and trade-offs |
|---|---|---|
| Onyx Community Edition | Self-hosted with Docker, Kubernetes, Helm or Terraform inside your own accounts or air-gapped network. MIT licensed for the core, covering RAG, AI chat, agents and actions. | Connectors for SharePoint, OneDrive, Outlook, Teams, Google Drive, Gmail, Confluence, Jira, Slack and Salesforce are in the repository. Confirm which sources you need against the connectors directory and whether permission sync is included for each. |
| Onyx Enterprise Edition | Self-hosted with code under ee directories licensed under the Onyx Enterprise License. Adds premium features such as RBAC, per the deployment docs. | Enterprise features listed include SSO through Google OAuth, OIDC or SAML, SCIM provisioning, role-based access control, usage analytics and query history auditing. Confirm the exact feature set for your version before relying on it for audit evidence. |
| Onyx Cloud | Managed service run by Onyx, so data and operations sit outside your own infrastructure. Not a fit where residency or customer-operated control is the requirement. | Connector coverage matches the product, but you do not control patching, upgrade timing or raw logs. Use it only as a comparison point during evaluation. |
| Open WebUI | Self-hosted and can run fully offline with Ollama or OpenAI-compatible APIs. The Open WebUI License is BSD-3-Clause style but forbids removing or altering branding unless user, permission or enterprise license conditions are met. | Focused on chat and model access rather than indexing company content. Branding clause applies to deployments above 50 users in a rolling 30-day period, so confirm with counsel before rebranding. |
| LibreChat | Self-hosted with Docker and MIT licensed. Supports many model providers and multi-user authentication with OAuth2, LDAP and email. | Strong for chat, agents and MCP tools. Connector coverage for company repositories is weaker than Onyx, so permission-aware search across Confluence, SharePoint or Slack would need custom build work. |
| AnythingLLM | Self-hosted via Docker or desktop app and MIT licensed, with multi-user support and local or cloud LLMs. | Good for ingesting documents and running agents with built-in vector databases. Connector breadth and per-source permission mirroring are weaker than Onyx, so confirm the sources and access rules you need. |
Who sees the logs and who sets upgrade timing
In Glean's Customer Hosted model, the operating model sets both answers. The deployment runs in your own GCP or AWS account, but Glean remains responsible for infrastructure and application management, including upgrades, patching and monitoring, and manual changes are not supported. Your team therefore depends on Glean for when a change lands and for how much visibility you get into the system's behavior. Before renewal, ask Glean in writing what query and audit records you can access directly, how long they are retained, whether you can export them to your own SIEM, and what notice period applies before an upgrade window. Treat the answers as contract terms, not assumptions.
With a self-hosted Onyx deployment, your operator sets both. Onyx lists usage analytics and query history auditing among its enterprise features, so the evaluation of logs and retention becomes a configuration and architecture decision for your team, with the Enterprise Edition needed for the features that sit under the ee directories. Upgrade timing also moves to your side of the table. Onyx publishes releases such as v4.9.2, released on October 15, 2026, and a Helm chart at version 0.9.17 as of October 16, 2026, according to the project's GitHub releases page. You can pin a version, run it in a staging environment against your own connectors and permission sync, and schedule the rollout to match your change calendar. Confirm with Onyx which release line receives security fixes and how long older versions are supported.
Whichever way you go, confirm the log retention periods, export formats and access roles in writing before you rely on them for an audit or an incident. Ask who in your organization needs read access to query history, whether those records contain user prompts and document excerpts, and how they are protected at rest. In a self-hosted deployment, the retention and export settings belong to your team, so write them into your runbook and test an export before you need it. Reviewing the Onyx deployment overview helps you map which services hold logs and which hold the index.
Choosing models when data must stay in your account
Onyx can call proprietary providers such as Anthropic, OpenAI and Gemini, so answers can come from a hosted frontier model while the index, database and permission sync stay in your environment. In this setup, each query and the retrieved passages sent with it leave your network for the provider, so the residency question moves to the provider's terms. OpenAI documents that it does not train on ChatGPT Enterprise, Business or Edu business data by default, and that its data residency option stores in-scope content at rest in a selected region, with inference residency offered in some regions on top. Those terms apply to OpenAI's products and eligible API customers, so confirm the exact controls for the API account and model you plan to use with each provider.
- Data leaves your boundary per request: prompts and retrieved snippets are sent to the provider, which makes this option unsuitable for content your rules keep inside your own network.
- Residency is contractual and regional: storage region and inference region can differ, so ask each provider which of them it guarantees for your account.
- Retention is set by the provider account: confirm default retention, deletion timing and whether logs are kept for abuse monitoring.
- Cost recurs per token: usage charges grow with the number of users and the size of the context sent with each answer.
- Key management stays with you: store provider keys in your secrets manager and rotate them on a schedule.
Before approving this path, check the provider's data processing terms for the specific API product and write the answers into your data classification record.
Ollama and LiteLLM let Onyx call models that run inside your environment, so prompts and retrieved passages do not need to reach an external model provider. Onyx's documented self-hosted paths include Ollama, LiteLLM and vLLM, and its air-gappable deployment runs the document index, database and processing in a self-contained set of services. Ollama suits smaller teams and modest concurrency, while LiteLLM can sit in front of several backends and provide one routing layer for Onyx. Both options move the operating burden onto your team: you choose the model weights, size the hardware, and own updates and access control for the model endpoint.
- Model choice is yours: you can use open-weight models that your legal team has approved, and you can swap them without changing the Onyx data layer.
- Hardware sizing is the main cost: memory and accelerator capacity determine which models are practical and how many users one host can serve.
- LiteLLM adds a routing layer: use it when several model backends need one interface, and treat that gateway as a service that needs its own authentication and logging.
- Patching is your responsibility: track releases of Ollama, LiteLLM and the model files, and test each change against your search quality checks.
- Quality varies by model: answer accuracy on your own documents can differ sharply between models, so run a pilot on real queries before you commit.
Confirm with the Onyx and Ollama documentation which versions your deployment supports, and confirm that model endpoints are unreachable from outside the cluster or network segment.
vLLM is an open-source inference and serving engine for large language models, licensed under Apache-2.0, and it has no paid edition. Its server, started with vllm serve, exposes OpenAI-compatible endpoints including /v1/chat/completions, /v1/completions, /v1/responses and /v1/embeddings, so applications written for the OpenAI API can point at it. The cost of running vLLM comes from GPU or other accelerator capacity, the surrounding infrastructure, implementation and the staff who operate it. vLLM ships minor releases about every two weeks, so plan a regular upgrade cycle. It runs on NVIDIA CUDA, AMD ROCm and Intel XPU GPUs, and on several CPU architectures.
- Accelerator capacity drives cost: the GPUs you buy or rent, and the tensor parallelism needed to fit a model, set the largest cost line.
- Staff time recurs: someone must own upgrades, capacity planning, monitoring and incident response for the serving layer.
- Put a reverse proxy in front: the
--api-keyoption does not cover every endpoint, including/metrics,/healthand/invocations, so allowlist only the endpoints users need and do not rely on the key alone. - Isolate multi-node traffic: vLLM's security documentation states that communication between nodes is insecure by default, without authorization or encryption, so place nodes on an isolated network.
- Monitor through Prometheus: the
/metricsendpoint exposes request counts, token throughput, latency and KV cache use for your operations dashboards.
Ask your infrastructure and security teams to confirm the GPU vendor, node layout and proxy configuration against the vLLM security and installation pages before you size the environment.
How to deploy Onyx under a customer-controlled residency requirement
This sequence moves Onyx into your own cloud account or data center in an order that keeps indexed content, logs and model traffic under your control, and ends with a pilot that proves permissions and search quality before cutover.
Confirm scope, residency boundary and data sources
Your security, compliance and business owners agree which systems of record feed the index (for example SharePoint, Confluence, Jira, Slack or Google Drive), which regions and accounts hold the data, and whether inference must stay inside that boundary. Your team also confirms which Onyx connectors exist for each source in the Onyx connectors directory and which ones need custom work. The output is a signed scope document listing each source, its owner and its permitted location, so every later step can be checked against it.
Choose Onyx Standard or Onyx Lite
Onyx Standard includes vector and keyword indexing, background sync workers, model inference servers, object storage and Redis, which fits broad connector coverage and full search. Onyx Lite offers chat and agents without a vector database or background workers, which suits smaller source sets or chat-first use. Your architects compare the choice against the scope from the previous step and the expected index size, then record the decision and its reasons. Confirm with the Onyx team which edition's features, including SSO, SCIM and RBAC, your requirements need, since those enterprise features sit in the Enterprise Edition.
Deploy the stack inside your account
Your platform engineers deploy Onyx with Docker, Kubernetes, Helm or Terraform into the cloud account, data center or isolated network that the residency rule names. The deployment provisions Postgres, the index engine (Vespa or OpenSearch), Redis and model servers, with object storage in the same boundary. Done means every service runs inside the approved network, no component calls an endpoint outside it, and the team has a documented inventory of storage locations and egress rules that a security reviewer can check.
Configure SSO, SCIM and role-based access
Your identity team connects Onyx to the corporate identity provider through Google OAuth, OIDC or SAML, then enables SCIM so joiners, movers and leavers flow from the directory. Role assignments map to your existing groups and access reviews. The check is a test set of accounts that log in through the identity provider, receive the expected roles, and lose access when disabled in the directory. Confirm with Onyx which enterprise features apply to your edition before relying on them in an audit.
Sync connectors and verify permission mirroring
Your team creates one connector per approved source and runs an initial sync. Onyx is designed to carry source permissions into search, so the team tests with accounts that hold different rights in each system, confirming that restricted documents do not appear in answers or citations for users who cannot open them in the source. Record each test, the account used and the result. Repeat the test after any permission change in the source. Do not treat a clean sync alone as proof of access control.
Select and secure the model endpoint
Your AI platform owner chooses the model path: a self-hosted model served through Ollama, LiteLLM or vLLM inside the boundary, or a proprietary provider such as Anthropic, OpenAI or Gemini if the residency rule allows external inference. If you use vLLM, place it on an isolated network, since its documentation states that inter-node traffic is unauthenticated and unencrypted by default. Its --api-key option does not cover every endpoint, so put a reverse proxy in front that exposes only the paths users need. Done means a test request confirms the endpoint answers only from approved clients and that metrics at /metrics are reachable only by your monitoring system.
Set log, backup and retention controls
Your compliance and operations leads set retention periods for query history, chat logs, index data and database backups, then write them into your records schedule. Backups go to storage inside the residency boundary, with restore tested at least once before go-live. Confirm with Onyx how query history auditing and usage analytics are exported, since your team, not the vendor, will hold the raw logs. The output is a retention matrix and one completed restore test, both filed with the compliance evidence.
Run a pilot group before cutover
A defined group of users runs real queries against the same sources for an agreed period, and the team compares answers, citations and permission behavior with the current assistant. Failures are logged by source and fixed before expansion. Cutover proceeds only when the pilot exit criteria, signed by the business owner and security lead, are met. Under a fixed-scope agreement, a partner can carry out steps 3 to 7 and produce the evidence pack, while your staff own the scope decisions, identity approvals, model choice and sign-off in step 8.
Evidence to collect for residency and access reviews
Residency and access reviews of either model come down to a short set of records: how data flows, who can reach what, and how changes were made. Collect them before the review starts, because the evidence you can produce determines how much of the review you can answer yourself. DeployOpen prepares these artifacts for your environment, but independent auditors issue any assessment or attestation.
Architecture and data flow diagrams
Draw where content is ingested, indexed, stored, embedded and sent to a model, with the account, region and network boundary for each hop. For Glean Customer Hosted, ask Glean to document which components run in your GCP or AWS account and which run under its management. For Onyx, the diagram should show the document index, Postgres, Redis, object storage and any model server, and whether any hop leaves your network. Mark every external model endpoint explicitly.
Connector list with permission sync settings
List every source connector, the account that authorizes it, the scope it reads, the sync schedule and whether document permissions are synced rather than flattened. Reviewers will ask whether a user who cannot open a document in SharePoint or Confluence can retrieve its contents through the assistant. Record the test you ran for that case and keep the result with the list.
SSO and SCIM configuration
Export the identity provider settings for Google OAuth, OIDC or SAML, plus the SCIM provisioning configuration that creates and removes users and groups. Show who can assign admin and role-based access rights, and how a leaver's access is revoked within the assistant. Ask Glean for the equivalent configuration of its Customer Hosted deployment, since its identity integration may be operated by Glean rather than by you.
Log and query history exports
Establish which logs you own, where they are stored and how long they are kept. For Onyx, define an export of usage analytics and query history from your own database, and confirm retention with your security team. For Glean, confirm in writing whether raw logs are accessible to you, which is a point on which the two models differ. Test one export end to end before the review, so the sample is not the first time anyone has run it.
Change and upgrade records
Keep a dated record of every version deployed, the Helm chart version, the image tags, configuration changes and the approver for each. Onyx publishes releases on GitHub and a Helm chart, so a change log can show when a version was adopted and tested. For Glean Customer Hosted, request the upgrade and patch history it applied on your behalf, since manual changes are not supported and the record will sit with Glean.
Vendor terms for proprietary model providers
When a model call goes to OpenAI, Anthropic, Gemini or another hosted provider, the residency and retention promise is set by that provider's terms, not by your deployment. Collect the current data processing terms, retention settings and any regional commitments for each provider you have enabled. Where residency matters, route those calls to a self-hosted model through Ollama, LiteLLM or vLLM and keep the provider terms out of scope.
Questions buyers ask before comparing Glean and Onyx
Can self-hosted Onyx match Glean's connector coverage?
For many common sources, yes, but you need to verify your own list. The Onyx repository includes connectors for SharePoint, OneDrive, Outlook, Microsoft Teams, Google Drive, Gmail, Confluence, Jira, Slack, Salesforce and other sources, and the README describes more than 50 applications. Glean's catalog is its own product, so build a table of every source your users rely on, check each one against the Onyx connectors directory, and mark gaps. Gaps may need a custom connector, which is scoped work. Ask whether each connector syncs the permissions your organization depends on, not just the content.
What staffing does an Onyx deployment need?
Plan for people who own the platform after go-live, not only the initial build. The work falls into four areas: infrastructure operations (Kubernetes or Docker hosts, databases, object storage), the search index and background sync workers, model serving, and identity integration with SSO and SCIM. Onyx documents Postgres, Vespa or OpenSearch, Redis and model servers as core infrastructure, so someone must patch and monitor those components. Under Glean's Customer Hosted model, Glean carries upgrades, patching and monitoring. With Onyx, that work moves to your team or to a partner you retain, so decide who answers the pager before you commit.
What drives the cost of self-hosted Onyx up or down?
The main drivers are model inference, index and database hosting, connector and integration work, optional Enterprise Edition licensing, and operations staffing. Inference cost depends on whether you use a proprietary API or self-hosted models through Ollama, LiteLLM or vLLM, and vLLM itself has no paid edition, so its cost comes from accelerator capacity, surrounding infrastructure, implementation and operators. Index size, sync frequency and the number of users also move the infrastructure bill. Ask any quote to itemize these components separately, state which items are one-time (build, connector setup, hardening) and which recur (hosting, model usage, support retainers), and name the licensing terms that apply to each feature you need.
How long does a migration from Glean to Onyx take?
The duration depends on the number of sources, how much permission mapping each one needs, the number of agents or workflows to recreate, the model choice, and how long a pilot runs before renewal. No fixed timeline applies across organizations, so treat any number you see as an assumption to test. A practical sequence is to inventory sources and permissions, stand up a non-production Onyx instance, connect a pilot group's sources, compare search results on real queries, then expand. DeployOpen plans and implements these phases under a written, fixed scope, and a quote follows from that scope. Ask for the timeline in writing with its assumptions listed.
Can our own team run an Onyx migration without outside help?
A capable platform team can, provided it has time, Kubernetes or Docker experience, and ownership of identity integration. Onyx publishes Docker, Kubernetes, Helm and Terraform deployment paths and a Helm chart, so the technical entry point is documented. The harder parts are permission mapping across each source, validating search quality, hardening the stack and writing the operating runbook. Teams that lack bandwidth for those tasks often bring in a partner for a fixed-scope piece, such as the connector set or the security review, and keep operations in-house. DeployOpen implements, hardens, backs up, upgrades and documents self-hosted platforms in your environment, and it can take on a defined part of the work.
How does Onyx preserve document permissions from source systems?
Onyx connects to the source applications and syncs their permissions, so answers draw only on documents the user can already see in the source application, according to the Onyx README. Verify this for each connector you deploy, because permission models differ between SharePoint, Google Drive, Confluence, Slack and other systems. Test with accounts at several access levels, confirm that revoked access disappears from answers after the next sync, and check how groups and inherited permissions are represented. Identity also matters: SSO through Google OAuth, OIDC or SAML and SCIM provisioning keep user accounts aligned with your directory.
Do Onyx Enterprise features require a separate license?
Yes, features in the ee directories fall under the Onyx Enterprise License rather than the MIT license that covers the Community Edition. The Onyx README lists SSO, SCIM provisioning, role-based access control, usage analytics and query history auditing among enterprise features, and the deployment docs describe a self-hosted Enterprise Edition with premium features such as RBAC. Confirm which features your requirements need, read the license terms that apply to them, and ask whether your residency, audit or access needs can be met without the Enterprise tier. Keep this question in the written scope so licensing is settled before go-live.
How DeployOpen deploys Onyx in your environment
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks, so an Onyx deployment would run where your team already controls identity, networking and storage. For a Glean comparison, that means the Onyx services (the document index, Postgres, Redis, model servers and object storage described in the deployment overview) sit in your AWS, GCP, Azure or on-premises environment, and your staff or a partner you choose holds the administrator access. Engagements are usually fixed-scope, with deliverables, timelines and responsibilities agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers, which matters because an Onyx deployment needs someone to watch releases and apply them.
Before scoping, confirm the decisions that shape the work: which connectors you need (for example SharePoint, Confluence, Jira or Slack), how the Onyx permission sync will map to your identity provider through SSO and SCIM provisioning, which model provider or self-hosted model server will handle inference, and whether you will run Onyx Community Edition or the Enterprise Edition for role-based access control. Ask DeployOpen to document each of these choices, along with backup scope, restore testing and the upgrade procedure, so your team can operate the system after handover. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments.
DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move cost are the number of connectors, the number of environments, the hosting topology, the depth of hardening and testing, and whether ongoing retainer support is included. Ask each proposal to separate one-time implementation from recurring support, and to state which items are your cloud or hardware spend and which are services. Infrastructure, GPU capacity and your own staff time are paid by you regardless of who implements the stack.
