ChatGPT Enterprise vs Onyx: which to choose

When ChatGPT Enterprise or Onyx fits a team asking questions over company knowledge

This decision usually starts with one of three situations: a ChatGPT Enterprise renewal that prompts a fresh look at cost and control, a data control requirement that the current workspace cannot meet, or staff who have been pasting internal documents into chat because the company's knowledge is scattered across SharePoint, Google Drive, Confluence and Slack. ChatGPT Enterprise fits teams that accept an OpenAI-hosted service. Its documented controls are SAML SSO, admin retention settings, regional data residency and SOC 2 Type 2 audits, and admins can view, export and delete end user conversations through the Enterprise Compliance API. If your policy accepts those controls and you do not need to run the application yourself, the hosted model is a reasonable fit.

Onyx fits a different need: search and question answering over company sources where each answer respects what the asking user can already see in the source application. Onyx syncs permissions from its 50+ connectors, and it can run in your own infrastructure with Docker, Kubernetes, Helm or Terraform, including in an air-gapped setup. The MIT-licensed Community Edition covers RAG, chat, agents and actions, while SCIM provisioning, RBAC, usage analytics and query history auditing sit in the enterprise features. Onyx Cloud is available if you want a managed service, but that changes where the data is hosted, so it should be evaluated as a separate option.

The decision turns on five questions. Which sources must be connected, and do their permission models map cleanly into Onyx? Where must the data and the model endpoints sit? Which identity provider and provisioning model will you use? Which models are acceptable, hosted or self-hosted through Ollama, LiteLLM or vLLM? And who will patch, upgrade and monitor the platform? Confirm the enterprise feature list and the Community Edition boundary in writing with Onyx before you plan around them, and confirm the current connector list for your specific sources in the repository.

Which option fits which scenario

This table matches common ChatGPT Enterprise and Onyx scenarios to the option that fits better and explains the condition that drives each choice. Read each row against your own source count, residency rules and platform staffing, since the better fit often depends on one constraint rather than overall preference.

Scenario	Better fit	Why
Mostly ad hoc chat with few document sources	ChatGPT Enterprise	A hosted workspace with admin retention controls and no infrastructure to run suits teams that mainly draft and brainstorm and only occasionally upload files.
Document-grounded Q&A across many internal sources	Onyx	Its connectors sync SharePoint, Confluence, Slack and other sources with their permissions, so answers draw only on content each user can already see.
Strict need for customer-hosted data	Onyx	The index, database and processing can run in your own cloud account or data center, whereas ChatGPT Enterprise runs only as an OpenAI-hosted service.
Air-gapped or isolated networks	Onyx	Its documented self-contained services can be deployed without internet access, which ChatGPT Enterprise cannot offer because it has no customer-hosted option. Confirm offline model and update procedures for your environment.
Teams that need OpenAI models only	ChatGPT Enterprise	If OpenAI is the sole approved model vendor and its data controls satisfy your review, the hosted service avoids running model servers. Onyx can also call OpenAI, so this factor matters mainly when you want no self-hosted models at all.
Teams needing SCIM and RBAC under their own IdP	Onyx	Onyx lists SCIM provisioning and role-based access control among enterprise features, which lets your identity provider drive access, though the Enterprise Edition licence applies to those features. Confirm the exact mapping with your IdP before committing.
Teams with no platform operations capacity	ChatGPT Enterprise	OpenAI runs upgrades, patching and availability, while a self-hosted Onyx stack needs staff for Postgres, the search index, Redis, model servers and sync workers. Onyx Cloud is an alternative if you want managed Onyx.

How Onyx indexes sources and keeps permissions in place

Onyx connects to more than 50 applications and syncs their permissions, so an answer only draws on documents the asking user can already see in the source system. The connectors in the repository cover SharePoint, OneDrive, Outlook, Microsoft Teams, Google Drive, Gmail, Confluence, Jira, Slack and Salesforce, among other sources. In practice, the assistant inherits access from where the content lives, not from a separate set of rules rebuilt inside a chat tool. ChatGPT Enterprise works differently. The workspace holds the conversations, and admins control retention and export for them, but grounding in company documents depends on what users upload or connect. Nothing in the workspace itself mirrors your file share permissions, so the answer quality and the access boundary are two separate questions you need to answer.

Before cutover, run a permission test against your own systems rather than trusting the connector list. Pick a sample of restricted SharePoint sites, Confluence spaces, Google Drive folders and Slack channels, and confirm with test accounts at different access levels that a question returns only what that account can open in the source application. Include a document whose permission was removed recently, and check how long it takes the change to stop appearing in answers. Confirm with Onyx, in writing, how each connector handles group membership, nested groups and external sharing, because those are the cases where permission sync most often differs from what administrators expect.

Confirm connector coverage for each source in your environment before you commit to the migration plan. The connector directory lists what the repository supports, but your tenant configuration, authentication method and edition (Community or Enterprise) decide what you can actually run. Ask which sources need a service account or app registration, which require admin consent, and which are only available in the enterprise features. Record the gaps as explicit decisions: either a source is connected, or users keep a documented manual process for it during the transition. Deciding this early also shapes the sync workload and the index size you will need to host.

Where data lives and who controls it under each model

ChatGPT Enterprise keeps conversations in OpenAI's hosted service, with retention set by your workspace admins and regional residency for eligible customers. Onyx places the index, database and processing inside your own environment, so the control questions shift to your team. The cards below set out each condition so you can match them to your own requirements.

OpenAI-hosted service only

ChatGPT Enterprise runs only as an OpenAI-hosted service, so conversations, uploaded files and retrieved content are processed on OpenAI's infrastructure. You cannot place its application servers or database in your own cloud account or data center. If your policy requires that the conversation store sits inside your perimeter, this model fails that test regardless of its other controls. Confirm this boundary with your OpenAI account team before you finalize the architecture.

Regional residency for eligible customers

OpenAI's data residency stores in-scope content at rest in a region you select, and it is offered to eligible API customers and to new ChatGPT Enterprise and Edu customers. Inference residency is available in some regions on top of that. Residency covers where data is stored, which may not match every regulator's reading of processing location. Ask OpenAI which content types and which regions apply to your contract.

Admin retention and deletion window

Enterprise workspace admins control retention, and OpenAI states that deleted conversations are removed from its systems within 30 days unless legally required to keep them. That window is set by the vendor's statement, so your own retention schedule must still account for backups and legal holds. In Onyx, retention for indexed documents and query history follows the settings in your own database and object storage, so you define and prove deletion yourself.

Self-hosted Onyx components

Onyx Standard runs Postgres for the database, Vespa or OpenSearch for the index, Redis, and model servers, all inside your environment. You choose where these services run, whether that is Docker, Kubernetes, Helm or Terraform, and you hold the logs and backups they produce. Lighter chat-only deployments can drop the vector database and background workers, which changes what data is stored and where. Confirm the component list for the edition you plan to run.

Air-gap and offline operation

Onyx documents an air-gappable deployment in which the document index, database and processing run within a self-contained set of services. Paired with self-hosted models through Ollama, LiteLLM or vLLM, prompts and retrieved passages need not leave the network. Hosted models such as OpenAI, Anthropic or Gemini remain outside that boundary, so an isolated network must use local models only. Validate offline behavior, including image and model distribution, in a test environment before you rely on it.

Identity, SSO and SCIM provisioning

ChatGPT Enterprise documents SAML SSO as its identity control, with user access managed in the OpenAI workspace. Onyx supports SSO through Google OAuth, OIDC or SAML, and SCIM user provisioning, so deprovisioning in your directory can reach the assistant. Onyx also syncs source permissions, so answers draw only on documents a user can already see in SharePoint, Google Drive or Confluence. Check that your directory groups map cleanly to Onyx roles before go-live.

Compliance evidence ownership

OpenAI holds SOC 2 Type 2 audits for ChatGPT Enterprise, and you can rely on that report through your vendor review. A self-hosted Onyx deployment has no such vendor report, so your team must design, operate and document its controls, and an independent auditor must assess them before any certification claim is made. DeployOpen prepares systems and evidence for that assessment but does not issue audit reports or attestations. Agree the evidence scope in writing before work starts.

What ChatGPT Enterprise and self-hosted Onyx cost to run

ChatGPT Enterprise is bought as a workspace relationship with OpenAI, so the main recurring cost is the per-seat agreement with the vendor. Infrastructure, model hosting, upgrades and security patching for the service sit with OpenAI. Your internal cost is mostly administration: identity setup, retention settings, Compliance API exports and periodic access reviews. Ask the vendor to confirm in writing which admin tooling is included, how seats are counted for users who never sign in, and whether contract terms change at renewal.

Seat count: The subscription scales with the number of licensed users, so headcount changes and inactive accounts directly move the bill.
Admin effort: Retention configuration, export requests and audit log reviews are staff time that the subscription does not cover.
Integration: SAML SSO and provisioning work sits on your identity team, even though the service itself is hosted by OpenAI.
Data handling: Compliance API exports, if you need them for records, may require planning and internal storage that you pay for separately.
Renewal terms: Ask what happens to price, seat minimums and data residency options at renewal.

Check how the agreement treats seats, admin tooling and residency options before comparing it with any self-hosted line item.

Cost components, one-time and recurring

Each card maps one cost component to who pays for it, whether it is one-time or recurring, and what moves it. The ChatGPT Enterprise side is a single contract line, while the self-hosted Onyx side splits across software editions, models, infrastructure and people. Use the cards to build a like-for-like comparison before you request quotes.

Licensing and subscription

ChatGPT Enterprise is a recurring subscription from OpenAI, priced through your contract and renewed on its term. Onyx Community Edition is MIT licensed, so the core software carries no license fee. Features listed as enterprise, including RBAC and SCIM, sit in code under the Onyx Enterprise License and should be priced as a separate recurring item. Ask which features you need, which of them are in ee code, and whether Onyx Cloud is part of the comparison.

Model inference

Confirm in the ChatGPT Enterprise contract how model use is billed and whether any usage limits apply. With Onyx, the model is a separate choice: you pay a provider such as Anthropic, OpenAI or Gemini per token, or you run open models through Ollama, LiteLLM or vLLM on your own GPUs. Inference is the main recurring variable and grows with query volume, context length and model size. Ask for a sizing assumption covering users, queries per day and average retrieved context before comparing totals.

Hosting and infrastructure

Onyx Standard runs Postgres, Vespa or OpenSearch for the index, Redis, model servers and object storage in your cloud account or data center. Onyx Lite drops the vector database and background workers, which reduces the footprint for chat and agents but removes document sync and indexing. Compute and storage recur and grow with indexed document volume and sync frequency. ChatGPT Enterprise has no hosting line because OpenAI operates the service. Ask the vendor for a sizing table per edition and whether an air-gapped setup changes node counts.

Connectors and identity setup

Each source you connect, such as SharePoint, Confluence, Slack or Google Drive, needs a one-time connector build with service accounts, scopes and permission mapping, followed by recurring checks when the source changes. Onyx also needs SSO through Google OAuth, OIDC or SAML and SCIM provisioning, with RBAC in the enterprise edition. ChatGPT Enterprise signs users in with SAML SSO and needs no connector build, but teams then rely on users to paste or upload content, which shifts effort into governance. Ask for the connector list in scope and a named owner for each credential.

Upgrades, monitoring and support

OpenAI operates ChatGPT Enterprise, so upgrades, patching and availability are part of the service you buy. With Onyx, you run the software: releases such as v4.9.2 and Helm chart updates need a test environment, a change window and a rollback plan. Your team also watches index health, sync failures and model endpoints, and support can come from the vendor, a retainer or internal staff. Plan for on-call coverage before go-live. Ask for the release cadence, upgrade notes per version and whether support covers enterprise code.

Staff time and quote scope

Staff time is often the least visible line in a self-hosted estimate. ChatGPT Enterprise needs admins for users, retention settings and Compliance API exports. Onyx needs platform engineers for deployment, identity owners for SSO and SCIM, source owners for connectors and a security reviewer for permissions and logs. Implementation is one-time, while operation recurs. Request a written quote that lists connector scope, edition features, sizing assumptions, upgrade and on-call duties, and handover documentation such as runbooks and architecture diagrams.

What moving from ChatGPT Enterprise to Onyx involves

The sequence moves company knowledge access from an OpenAI-hosted workspace to an Onyx deployment you run, with permissions, identity and model choices settled before users are moved. It ends with a pilot group, a retired ChatGPT workspace and a recurring access review.

Inventory sources and the documents users actually ask about
Start by listing the systems where your people find answers today, including SharePoint, OneDrive, Google Drive, Confluence, Jira, Slack and Teams, and the files users currently paste or upload into ChatGPT. Ask department owners which sources matter most and who administers each one. The output is a written source list with owners and the permission model each source uses, which becomes the connector plan. Onyx's connectors directory on GitHub shows which sources have connectors in the current repository, so confirm each one you need before committing to the design.
Choose the deployment target and Onyx edition
Decide where Onyx will run (your cloud account, a data center or an air-gapped network) and whether the MIT-licensed Community Edition covers your needs or the Enterprise Edition is required for features such as RBAC. Onyx documents two deployment shapes: Onyx Standard, with vector and keyword indexing, background sync workers, model servers, object storage and Redis, and Onyx Lite, which runs chat and agents without a vector database or background workers. Record the choice in a short design note so the infrastructure and license decisions are reviewed together.
Stand up Onyx with Docker, Kubernetes, Helm or Terraform
Deploy Onyx in a staging environment using Docker Compose for a single-host trial, or Kubernetes with the Helm chart or Terraform for a production footprint. Your platform team owns the database, index, Redis and model server components, backups and network controls. Done means the services start cleanly, the admin account works, and a test document can be indexed and queried end to end, with a restore test of the database on record.
Connect sources and validate permission sync
Connect each source with a service account or OAuth grant scoped to read access, then run a test set of users across different groups. For each test user, compare what Onyx returns with what that user can open in the source application. Onyx states that answers draw only on documents the user can already see in the source, so any mismatch is a blocking defect. Record the test cases and results, and repeat the check after each connector change.
Configure SSO, SCIM and role-based access
Connect Onyx to your identity provider through Google OAuth, OIDC or SAML, and enable SCIM provisioning if your directory supports it so accounts and group membership follow joiners and leavers. Map groups to Onyx roles, and confirm which roles require the Enterprise Edition. The check is a test sign-in for each role, a deprovisioned test account that loses access, and a documented mapping table signed off by the identity owner.
Choose model providers and set data handling terms
Select the models Onyx will call, whether a self-hosted model through Ollama, LiteLLM or vLLM, or a proprietary provider such as Anthropic, OpenAI or Gemini. Each hosted provider has its own data terms and residency options, so ask legal and procurement to review them against your policy before any production document is sent. Done means a written model register that names the provider, the region, the data terms and the owner for each model.
Pilot with one user group and retire the ChatGPT workflow
Run a pilot with a defined group that already relies on ChatGPT for document questions. Collect feedback on answer quality, missing sources and permission issues, and fix them before widening access. Conversation history does not transfer to Onyx automatically. If you need prior ChatGPT conversations, use the Enterprise Compliance API as an admin to retrieve them, then decide what to keep, store and delete. A sibling page on migrating from ChatGPT Enterprise to Onyx covers that path in detail. Done means the pilot group has signed off, the retention decision is recorded and the old workspace access is removed.
Run recurring access reviews and audit checks
Set a recurring review of connector credentials, Onyx role assignments, model provider accounts and query history auditing, which Onyx lists among its enterprise features. Reviewers should sample permission results against source systems after each source change and after Onyx upgrades. Keep the review record with the design note so auditors and security teams can see who approved what. Confirm the review cadence with your own governance policy, since no interval is set by the platform.

Questions buyers ask before choosing Onyx or ChatGPT Enterprise

How much in-house effort does running Onyx require?

The effort depends on which Onyx deployment you choose and how many sources you connect. Onyx documents two shapes: Onyx Standard, which runs vector and keyword indexing, background sync workers, model inference servers, object storage and Redis, and Onyx Lite, a lighter chat and agents deployment without a vector database or background workers. Standard needs someone who can operate Postgres, a search index (Vespa or OpenSearch), Redis and model servers, plus upgrades and monitoring. Ask your team which of those skills already exist, and treat connector maintenance, permission sync checks and model hosting as recurring work that scales with the number of sources and users.

Can our team deploy Onyx without outside help?

A team with container and Kubernetes experience can deploy Onyx on its own, since it installs with Docker, Kubernetes, Helm or Terraform. The harder parts are usually identity integration (SSO through Google OAuth, OIDC or SAML, plus SCIM provisioning), permission-aware connector setup for each source, choosing a model provider, backup of the index and database, and hardening. Outside help is most useful for a fixed-scope implementation where scope, deliverables and timelines are agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and offers ongoing support as a retainer. It does not issue audit reports or certifications.

How long does a migration from ChatGPT Enterprise to Onyx take?

No fixed duration applies, because the timeline depends on the work in front of you. The main drivers are how many sources must be connected, how cleanly your identity provider groups map to Onyx roles, whether permissions in each source can be synced reliably, how many users need onboarding, and which model providers you approve. Teams that still rely on pasted or uploaded files usually need a source inventory first. Ask any implementation partner for a written scope with phases and acceptance criteria before accepting a timeline, and ask them to name the assumptions behind it.

Is the MIT Community Edition of Onyx enough, or do we need the enterprise features?

The Community Edition is enough for many chat and retrieval use cases, because it is MIT licensed and covers RAG, AI chat, agents and actions. Enterprise features such as role-based access control, SCIM user provisioning, usage analytics and query history auditing are listed among Onyx's enterprise features and sit under the Onyx Enterprise License in ee directories. Check the license for each feature you need, including SSO options, before you design access controls around it. Also confirm with Onyx whether the Enterprise Edition is self-hosted, Onyx Cloud is managed, and which one fits your compliance requirements.

Can Onyx run in an air-gapped network, and what does that require?

Onyx documents an air-gappable, self-hosted deployment in which the document index, database and processing run within a self-contained set of services. Running it offline still needs planning: container images and Helm charts must be delivered into the isolated network, the chosen model must run locally through Ollama, LiteLLM or vLLM, and you need a process for updates and connector credentials. Connectors to cloud sources such as SharePoint or Slack will not work without a route to those services, so the offline design may change which sources you index. Confirm each of these with Onyx and in your own environment before committing.

What does a ChatGPT Enterprise export cover, and what does it leave out?

Admins can view, export and delete end user conversations, and they can reach an audit log of conversations and GPTs through OpenAI's Enterprise Compliance API, which is the documented export path. Confirm with OpenAI what the Compliance API returns for your plan, including uploaded files, custom GPT configuration and any data outside the workspace. Retention settings matter too: OpenAI states that deleted conversations are removed from its systems within 30 days unless legally required. Plan your migration around what the API can return, not around what the workspace interface displays.

Can DeployOpen take on scoped implementation, hardening, backup and support for Onyx?

Yes. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications; independent auditors do that. If you prefer not to self-host, Onyx Cloud is a managed alternative that changes where the service runs and who operates it.

What to confirm with Onyx and OpenAI before you decide

The feature lists on both sides look similar on paper, so the answers to a short set of questions should decide the fit. Start with connectors. Write down every source your users currently search or paste from, then confirm with Onyx that each one has a connector in the repository and that it syncs the permissions your organization relies on. Ask which connectors are maintained, which are community contributions, and how a source that is not on the list would be handled. Some sources will need custom work, and that work belongs in the scope before you commit.

Next, confirm which Onyx edition includes the RBAC and SCIM features you require. The README lists SSO through Google OAuth, OIDC or SAML, SCIM provisioning and role-based access control among enterprise features, and the Community Edition is MIT licensed, but code in the ee directories sits under the Onyx Enterprise License. Ask Onyx in writing which of your required controls are in the Community Edition, which need the enterprise license, and what the license terms say about support and upgrades. Then map your identity provider groups to Onyx roles on paper before any installation, so you can see whether group-based access works for your structure or whether roles need to be assigned by hand.

On the OpenAI side, confirm what data residency and inference residency cover for your region and your contract. OpenAI's help center describes data residency as storage of in-scope content at rest in a selected region, with inference residency offered only in some regions on top of it. Ask whether your region and plan qualify, which content types are in scope, and whether inference happens in-region. Also confirm whether your users need models that only OpenAI provides. If they do, Onyx can still call OpenAI as a provider, but the hosting, retention and index decisions remain yours, and that split should be documented before you decide.

How DeployOpen helps evaluate, implement or migrate Onyx

DeployOpen is a Chainscore Labs company that 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 ChatGPT Enterprise vs Onyx, we start with the document sources, permission model and identity setup your organization actually uses, then decide whether Onyx fits your requirements.

How we scope

We agree scope, deliverables and timelines in writing before any work starts.
We inventory which sources, such as SharePoint, Google Drive or Confluence, users need searched and how their permissions are set.
We confirm whether Community Edition features cover your needs or whether enterprise license features such as RBAC and SCIM are required.

How we build

We deploy Onyx in your environment using Docker, Kubernetes, Helm or Terraform, matching your infrastructure standards.
We configure SSO, SCIM provisioning and connectors, then test that search results respect source-level permissions for sample users.
We connect your chosen model provider, whether a hosted API or a self-hosted model through Ollama, LiteLLM or vLLM, and document the data flow.

How we hand over

We deliver architecture, configuration and runbook documentation so your team can operate the stack without us.
We provide the access review, logging and retention settings and the evidence you need for internal or external compliance assessments, without issuing any audit report.
We walk your administrators through connector management, user onboarding and upgrade procedures before handover closes.

How we support

Ongoing support, upgrades and continuous security testing are available as a retainer after handover.
We track Onyx releases and plan upgrades, including the Helm chart, against your change windows.
Security testing of the deployed application and its APIs can be scoped separately under the same written agreement.

ChatGPT Enterprise vs Onyx