Open WebUI vs Onyx: when to choose each platform
Choose Open WebUI when your main need is a shared chat workspace over models you control, with knowledge bases and tools added around it. Choose Onyx when the main need is answers grounded in company systems such as SharePoint, Confluence or Slack, and when a user must never see a document that the source application would hide from them. Both can run in your own infrastructure, so the decision turns on what the assistant must know and who is allowed to know it, not on hosting alone. Start by asking whether answers must be grounded in connected sources. Onyx connects to 50+ applications and syncs their permissions, so answers only draw on documents the user can already see in the source application. Open WebUI supports knowledge bases and retrieval with 13 vector databases, including PGVector, Qdrant and Milvus, but its core model is chat over models you select. If permission mirroring is a hard requirement, confirm with Onyx which connectors and paid editions provide it for each source, since Open WebUI's documentation places source-permission mirroring in Onyx's paid editions. Also check the Open WebUI branding clause: it applies once a deployment exceeds 50 end users in any rolling 30-day period, and an enterprise license is one of the ways to lift it.
Identity and administration matter in both cases. Open WebUI's free edition includes OIDC and OAuth SSO, LDAP, RBAC, SCIM 2.0 and audit logging, which covers many internal rollouts without a paid tier. Onyx lists SSO through Google OAuth, OIDC or SAML, SCIM provisioning and RBAC among its enterprise features, and Onyx's paid editions carry the permission mirroring described above. Ask each vendor which of these controls are free, which are paid and which apply to your identity provider. Who runs the stack changes the answer as well. Onyx's standard deployment includes Postgres, Vespa or OpenSearch, Redis, model servers and background sync workers, while Onyx Lite removes the vector database and workers for a lighter chat deployment. Open WebUI at small scale needs one container, but multi-replica use requires PostgreSQL, Redis and shared file storage. If your team lacks people to operate search indexes and sync jobs, a plain chat workspace is the smaller commitment. If connected knowledge is the goal, budget for Onyx's services from the start and request a written scope that covers connector setup, permission testing and upgrades.
Which scenario fits Open WebUI and which fits Onyx
This table maps common buying scenarios to the platform that fits each one better, with the reason tied to supplied capabilities and license terms. Read each row by asking which requirement dominates your rollout, then check the reason before deciding. Where the two platforms can run side by side, the table says so.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Offline or air-gapped chat for a small team | Open WebUI | Open WebUI is built to run entirely offline and connects to Ollama and OpenAI-compatible APIs, so local models need no external service. Confirm that your model runtime and any plugins work without internet access. |
| Company-wide assistant over local and cloud models | Open WebUI | Open WebUI offers one interface for Ollama, OpenAI, Anthropic and other OpenAI-compatible providers. Above 50 users in a rolling 30-day window, branding changes need an enterprise license or written permission. |
| Employee search across SharePoint, Confluence and Slack with source permissions | Onyx | Onyx connects to 50+ applications and syncs source permissions so answers only draw on documents the user can already see. Confirm that each connector covers the exact spaces and sites in your tenant. |
| Regulated team needing audit logs and SSO | Onyx for query-level auditing, Open WebUI for SSO and logs at lower tier | Open WebUI's free edition documents OIDC, LDAP, RBAC, SCIM 2.0 and audit logging. Onyx lists query history auditing and SAML alongside RBAC, but its permission mirroring sits in paid editions. Confirm which controls your assessor expects. |
| Identity provisioning through SCIM and group-based access | Open WebUI | Open WebUI documents SCIM 2.0 in its free edition, with RBAC by groups and per-resource permissions. Onyx lists SCIM and RBAC as enterprise features, so confirm the edition you would license. |
| Teams that need a chat front end over their own knowledge base only | Open WebUI | Open WebUI's knowledge bases support 13 vector databases with hybrid search and reranking. Choose Onyx if the knowledge must stay tied to source-system permissions instead of uploaded copies. |
| Running both side by side | Both, in a pilot | Open WebUI's documentation says the two can be used together, and Onyx's migration guide recommends running them alongside each other, connecting the same models and piloting with one team. |
| Migrating an existing Open WebUI rollout to Onyx | Onyx, after a pilot | Pipelines, community Functions and UI themes do not carry over directly, and documents are re-indexed from source by Onyx connectors. Budget review time for custom components. |
How each platform is built and what it means for operations
Open WebUI and Onyx both run as several services, but the pieces differ in count, role and who has to patch them. The cards below cover what each install path asks your team to run, where the scaling and on-call work sits, and the points to confirm with each vendor before you commit to a design.
Open WebUI install methods
Open WebUI supports Docker and Docker Compose, Kubernetes with Helm, and a pip install followed by open-webui serve. A single container with the default SQLite database is the simplest path for a pilot, but it is not the one to run for many users. Your team owns image upgrades, backups and the choice of install path, so decide early which path your platform team will patch. Confirm with the vendor which install path it recommends for your user count.
Open WebUI multi-replica needs
The scaling guide requires PostgreSQL instead of SQLite once you run more than one instance, because SQLite does not handle concurrent writes from multiple processes well. Multiple replicas also need Redis for sessions, websocket connections and application state, plus shared file storage so uploads and knowledge stay reachable from every replica. Each added piece is another service to patch, back up and monitor on call. Confirm the exact replica thresholds and failure modes with the vendor's scaling guidance before sizing.
Open WebUI vector database choice
Open WebUI's retrieval features support 13 vector databases, including ChromaDB, PGVector, Qdrant, Milvus and Elasticsearch, with hybrid BM25 plus vector search and cross-encoder reranking. The multi-replica guidance points toward a client-server vector database rather than an embedded one. Choosing one means your team runs and upgrades another stateful service. Confirm which vector store the vendor supports for your replica count and whether the built-in option is acceptable for production.
Onyx Standard service footprint
Onyx Standard includes vector and keyword indexing, background sync workers, model inference servers, object storage and Redis. Its documented infrastructure adds Postgres and Vespa or OpenSearch for the index. Background sync workers mean connector health becomes an operational concern, since a failed source sync can leave answers stale without an obvious outage. Confirm who owns connector credential rotation, sync failure alerting and index capacity planning.
Onyx Lite as a lighter option
Onyx Lite is a lighter chat and agents deployment without a vector database or background workers. It removes the index and sync services from your patch and on-call list, but it also removes the permission-aware company search that justifies choosing Onyx in the first place. Lite suits teams that want Onyx's chat and agents without connected knowledge. Confirm with the vendor whether Lite can later be upgraded to Standard in place and what that migration involves.
Air-gapped and self-contained deployment
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 be deployed with Docker, Kubernetes, Helm or Terraform. For a network with no outbound access, model servers and any connector sources must still be reachable inside that boundary, and image and chart updates must be moved in by hand. Confirm the offline image, model and update process with the vendor before you rely on it. Open WebUI is also built to run entirely offline, so verify the same for each model and add-on you plan to use.
Capabilities side by side: identity, retrieval, licensing and deployment
This table sets Open WebUI and Onyx against each other on purpose, licensing, identity, retrieval and deployment. Read each row with its edition note, because several Onyx identity and permission features sit in paid tiers, and confirm current edition contents with each vendor before you decide.
| Capability | Open WebUI | Onyx |
|---|---|---|
| Core purpose | General AI chat platform built around chat, knowledge bases, tools and model providers | Enterprise search and AI assistant that grounds answers in connected company applications |
| License base | Open WebUI License since v0.6.6 (April 19, 2025); code through v0.6.5 remains BSD-3-Clause | Community Edition under MIT; code in ee directories under the Onyx Enterprise License |
| Branding terms | Branding may not be altered or removed above 50 users in a rolling 30-day period without an enterprise license or written permission | Confirm branding terms for your edition directly with Onyx |
| SSO (OIDC, LDAP, SAML, Google OAuth) | OIDC, OAuth and LDAP in the free edition; confirm SAML support in your version | Google OAuth, OIDC or SAML listed as enterprise features |
| SCIM 2.0 provisioning | Included in the free edition per Open WebUI documentation | Listed as an enterprise feature; confirm tier with Onyx |
| Role-based access control | Groups and per-resource permissions in the free edition | Listed as an enterprise feature (paid tier) |
| Audit logging | Included in the free edition per Open WebUI documentation | Query history auditing and usage analytics listed among enterprise features |
| Source permission sync | Not a documented core feature; knowledge access is managed within Open WebUI | Syncs source permissions so answers only use documents the user can already see; paid editions per Open WebUI docs |
| Connector count | Not positioned as a connector-first product; relies on knowledge uploads and tools | 50+ applications, including SharePoint, Confluence, Jira, Slack and Google Drive |
| Model provider support | Ollama, OpenAI, Anthropic and any OpenAI-compatible provider from one interface | Ollama, LiteLLM and vLLM for self-hosted models, plus Anthropic, OpenAI and Gemini |
| Vector database options | 13 vector databases, including ChromaDB, PGVector, Qdrant, Milvus and Elasticsearch | Indexes in Vespa or OpenSearch with Postgres and Redis |
| Deployment methods | Docker and Docker Compose, Kubernetes with Helm, or pip install with open-webui serve | Docker, Kubernetes, Helm or Terraform; air-gappable self-hosted deployment |
| Editions and paid tiers | Free edition plus enterprise license for white-labeling and dedicated support; pricing quoted by sales | Community Edition, Onyx Cloud and self-hosted Enterprise Edition; confirm current contents with Onyx |
What each license allows and what is paid for
Open WebUI's code history has two parts. Code merged through v0.6.5 remains under BSD-3-Clause, which is permissive. From v0.6.6, released April 19, 2025, the project is distributed under the Open WebUI License, which keeps the open-source use case but adds a branding clause. The clause forbids altering or removing Open WebUI branding unless the deployment has no more than 50 end users in a rolling 30-day period, the copyright holder gives written permission, or the licensee holds an enterprise license.
- Branding threshold: The 50-user limit is counted on a rolling 30-day window, so a team that grows past it during a quarter can trigger the clause even if it shrinks later. Track active users, not seats, when you decide.
- Enterprise license: The enterprise license permits white-labeling and custom branding and comes with dedicated support options. Pricing is not published. You request a quote from enterprise sales with an expected seat count, which is the main recurring cost to budget for if you need branding changes.
- BSD-3 fork option: If you need to rebrand without a commercial agreement, the code through v0.6.5 is available under BSD-3-Clause. Confirm with counsel which features you would have to forgo and how a fork would be maintained.
- Internal use: Running Open WebUI for staff inside your own organization is the scenario the free terms cover most directly, subject to the branding clause above.
- Customer-facing use: Exposing the interface to customers, partners or external users is where the user count and branding terms need legal review before go-live.
Before committing, have legal counsel read the current license text and confirm how user counts are measured for your deployment.
Onyx is open core. Onyx Community Edition is MIT licensed and covers RAG, AI chat, agents and actions, so you can self-host the core without a license fee. Code in directories named ee is under the Onyx Enterprise License, and the paid features sit there. The features that matter for enterprise search, such as mirroring source-system permissions and enforcing them at retrieval time, along with RBAC, belong to the paid editions described in the Onyx documentation.
- Community Edition: MIT-licensed code covers the core chat, retrieval and agent features. It is the right starting point for a pilot, but it does not include the permission mirroring that stops answers from drawing on documents a user cannot see in the source system.
- Enterprise Edition: The self-hosted Enterprise Edition adds premium features such as RBAC. Confirm exactly which SSO, SCIM, audit and permission features are inside the ee directories for the version you plan to run.
- Onyx Cloud: The managed service removes the infrastructure work but moves hosting and data handling to a vendor. This matters for regulated data residency and for air-gapped requirements.
- Self-hosted deployments: Onyx documents Docker, Kubernetes, Helm and Terraform paths. Your license terms follow the edition you deploy, not the deployment method.
- Quoting: Ask for a written quote that lists which features are included, the license term, support scope and whether the price recurs annually.
Before you deploy, have counsel confirm how the ee directories apply to your internal and customer-facing use, and get the Enterprise License terms in writing.
What drives the running cost of each platform
The running cost of Open WebUI is mostly infrastructure and the people who operate it, and the cost rises sharply once you move past a single container. The Open WebUI scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments, and multiple replicas also need Redis for sessions, websocket connections and application state, plus shared file storage so uploads and knowledge stay reachable from every replica. Each of these is a service your team patches, backs up and monitors, so a single-instance pilot and a multi-replica production setup should be costed separately. Recurring costs include cloud or data center capacity, database and storage growth as knowledge bases expand, and the staff time to upgrade a release line that shipped v0.12.3 on October 16, 2026. Licensing is a separate line. Above 50 end users in a rolling 30-day period, the branding clause applies unless you hold an enterprise license or written permission, and enterprise pricing is quoted after contacting sales with an expected seat count, so ask for that figure in writing before you size the deployment.
Onyx carries a heavier standing footprint because its documented infrastructure includes Postgres, Vespa or OpenSearch for the index, Redis and model servers. The index and model servers are usually the largest recurring items, and their size tracks how many connectors you run and how much content they sync. Connector maintenance is a cost that Open WebUI does not carry in the same form: each of the 50+ connectors authenticates against a source system, follows that system's API changes and keeps permission sync accurate, so someone must own those credentials and failures. Onyx's Enterprise Edition, which adds features such as RBAC, is a separate paid tier, and support terms vary by contract. Lighter options exist: the Onyx Lite deployment drops the vector database and background workers, which reduces infrastructure but removes the document sync that justifies Onyx in the first place.
Separate one-time work from recurring work before comparing totals. One-time work includes the initial deployment, identity integration (SSO, SCIM provisioning and RBAC design), connector build-out and the pilot that Onyx's July 15, 2026 migration guide recommends running alongside Open WebUI. Recurring work includes upgrades, connector and index maintenance, security patching, backups, on-call support and any retainer. Ask any vendor or implementation partner for a written quote that states scope, the list of connectors and their source systems, expected user count, environments (production, staging and air-gapped if relevant), the support hours and response commitments, the number of upgrades covered per year and who pays for model inference. Ask whether enterprise license fees are quoted per seat or per deployment, and whether connector additions are priced separately. Where a figure is not in the quote, treat it as unknown rather than assume it is included.
Moving from Open WebUI to Onyx without losing users
The sequence runs Onyx beside Open WebUI, connects the same models, pilots with one team and cuts over only after permissions and user access are confirmed, so staff keep working throughout.
Deploy Onyx beside the running Open WebUI
Your platform or infrastructure team installs Onyx in the same environment as the existing Open WebUI deployment, without touching Open WebUI's data or configuration. Onyx's own deployment options include Docker, Kubernetes, Helm and Terraform, and its standard deployment needs Postgres, a vector index (Vespa or OpenSearch), Redis and model servers, so confirm capacity for those services before you start. The step is done when Onyx starts cleanly, reaches its index and database, and Open WebUI still serves staff unchanged.
Connect the same model providers to Onyx
Next, the administrator configures Onyx with the same model providers Open WebUI uses, such as Ollama, vLLM, LiteLLM or hosted providers like Anthropic, OpenAI or Gemini. Model connections are the part of the setup that carries over in practice, because you re-enter them rather than migrate them. Keep a written inventory of each provider, endpoint and credential owner from the Open WebUI side first. The step is done when a test prompt returns a response from each model in Onyx and the list matches the inventory.
Rebuild custom Pipelines, Functions and themes
Plan the rebuild of anything custom in Open WebUI. Onyx's migration guide says custom Pipelines, community Functions and UI themes do not carry over directly, so each one needs an owner who decides whether to recreate its behavior in Onyx's agents and actions, drop it, or keep it in Open WebUI for the teams that still use it. Record the decision for each item in a short register. The step is done when every custom component has a recorded outcome and an owner.
Re-index knowledge from source systems
Documents are not moved as files. Onyx's connectors re-index content from its original sources, such as SharePoint, Google Drive, Confluence or Jira, so the source system stays the system of record. Confirm which sources each knowledge base depended on in Open WebUI, configure the matching connectors, and check that the connector set covers them. The step is done when indexing completes for each source and a spot check of known documents returns the expected results.
Verify permission sync before any user sees answers
This check matters more than the others. Onyx's paid editions can mirror source-system permissions and enforce them at retrieval time, and Open WebUI's knowledge bases are governed by its own RBAC and per-resource permissions, so the access model changes. Pick test accounts with different access in each source, ask questions whose answers sit behind restricted documents, and confirm that Onyx returns only what each account can already see in the source. Confirm with the vendor which edition provides the permission sync you need for your sources. The step is done when restricted content is withheld for every test account and the results are written down.
Pilot with one team and re-onboard its users
Pick one team with a clear use case and a willing lead. Set up identities through the identity provider you intend to use (OIDC, SAML or SCIM provisioning, depending on your edition and setup), then ask pilot users to sign in to Onyx and recreate the prompts, saved workflows and habits they relied on in Open WebUI. Expect to explain what changed and where Open WebUI history stays available during the overlap. The step is done when the pilot team completes its normal tasks in Onyx, the issues log is triaged, and sign-in works for every pilot account.
Cut over in stages and retire Open WebUI access
After the pilot results are reviewed, move remaining teams in groups, keeping Open WebUI running until each group confirms its work is available in Onyx. Remove Open WebUI access only once the last group signs off, and keep a read-only copy of its data for the retention period your policies require. Confirm with your compliance owner how Open WebUI audit logs and chat records are archived. The step is done when all users sign in to Onyx, Open WebUI is disabled for general use, and the archive is verified.
Where Open WebUI and Onyx projects usually run long
Most schedule slips on either platform come from identity and data access work that looks small at kickoff. For Open WebUI, the usual trap is group mapping. The free edition documents OIDC and LDAP sign-in and SCIM 2.0 provisioning, but the groups that arrive from your identity provider must map cleanly onto the RBAC groups and per-resource permissions you intend to use for knowledge bases and models. Confirm with your identity team which claim or group attribute carries role membership, how nested groups flatten, and who owns the mapping after go-live. If you plan several replicas, budget for PostgreSQL in place of SQLite, Redis for sessions and WebSocket state, and shared file storage, since the scaling guide treats each as a prerequisite rather than an option. Ask DeployOpen or your platform team to confirm these pieces are provisioned before user onboarding starts.
For Onyx, the slip points sit at the connectors. Each source needs a service credential with read access to the content and the permission metadata Onyx must sync, and a permission check fails quietly if that scope is too narrow. Test with two or three users who hold different access to the same SharePoint site, Confluence space or Google Drive folder, and confirm that retrieval returns only what each user can already open in the source. Sizing the index is the other common overrun. Onyx Standard runs a vector and keyword index on Vespa or OpenSearch with background sync workers, model servers, object storage and Redis, while Onyx Lite drops the vector database and workers. Ask the vendor to walk through index size and sync load for your document volume and connector count before you commit to a tier, and confirm which edition includes the RBAC and permission-sync features you need.
Questions buyers ask before choosing or hiring help
Can Open WebUI and Onyx run together in the same company?
Yes. Open WebUI's documentation says the two can be used together, and Onyx's July 15, 2026 migration guide recommends running Onyx alongside Open WebUI, connecting the same models and piloting with one team before any cutover. The practical pattern is to keep Open WebUI as the general chat workspace for staff and use Onyx for questions that must draw on connected company sources. Confirm with your own architects how identity, model access and logging will be shared between the two before you commit to that split.
What does the 50-user threshold in the Open WebUI License mean in practice?
The Open WebUI License forbids altering or removing Open WebUI branding in deployments that exceed 50 users in any rolling 30-day period, unless the operator holds an enterprise license or written permission from the copyright holder. Below that count, you can rebrand without a separate agreement. Above it, branding changes require one of those two routes. Count users across the rolling window rather than headcount, and ask your legal team to read the LICENSE file alongside the Open WebUI license documentation before rollout. Onyx's Community Edition is MIT licensed, so this clause does not apply to it in the same way.
Do SSO and RBAC require the paid tier in Open WebUI or Onyx?
It depends on which features you need. According to Open WebUI's documentation, its free edition includes OIDC and OAuth SSO, LDAP, RBAC, SCIM 2.0 and audit logging. Onyx lists SSO through Google OAuth, OIDC or SAML, SCIM provisioning, role-based access control and query history auditing among its enterprise features, and its paid editions can mirror source-system permissions and enforce them at retrieval time. If permission-aware answers are the reason you are buying, plan for the Onyx Enterprise Edition. Ask Onyx which controls sit in which edition before you size the deployment.
How much effort does a pilot take, and what drives it?
The effort depends mostly on how many connectors you enable, which model providers you connect and how much identity integration the pilot must prove. Onyx's migration guide recommends piloting with one team before cutting over, which keeps the first scope small. For Open WebUI, the scaling guide notes that a single container with SQLite is simple, while multi-instance use needs PostgreSQL and Redis. Ask for the pilot scope, the number of sources, the identity provider to integrate and the acceptance tests in writing, since those inputs set the work more than the software does.
What must our own team provide for either platform?
Your team usually owns the infrastructure account, the identity provider, the model access decisions, the data owners who approve which sources are connected, and the people who accept the pilot results. For Onyx, the Standard deployment includes Postgres, Vespa or OpenSearch for the index, Redis and model servers, so someone must operate or approve those services. For Open WebUI, multi-replica setups need PostgreSQL, Redis and shared file storage. Document these owners before the first workshop so that open decisions do not stall the work.
Can our own engineers implement this without outside help?
Yes, if your team has Kubernetes or Docker operations skills, an identity integration owner and time to test connectors and permissions. Both projects publish install methods, including Docker, Kubernetes with Helm, and Terraform for Onyx. The harder work is usually permission testing, connector scope and migration of custom Open WebUI Pipelines, community Functions and UI themes, which Onyx's migration guide says do not carry over directly. Outside help makes the most sense when those items need evidence for an assessment or when the team lacks capacity.
What does a fixed-scope engagement with DeployOpen cover?
A DeployOpen engagement is typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For this comparison, that can include planning the deployment inside your own infrastructure, integrating identity, configuring connectors and permissions, running a pilot, documenting the setup and preparing evidence for a compliance assessment. DeployOpen does not issue audit reports or certifications, and it does not publish a price list. Ask for a written scope that names each system, each connector, each integration and each handover item, then compare the quote against that document.
What drives the cost of running Onyx or Open WebUI over time?
Costs fall into three groups: licenses, infrastructure and people. Open WebUI's free edition covers many features, while enterprise licenses are quoted after contacting sales with an expected seat count, and Onyx Enterprise pricing follows its own quote. Infrastructure grows with the Onyx index services, model servers and object storage, and with the number of Open WebUI replicas. People costs recur through upgrades, connector maintenance and access reviews. Ask each vendor for a quote that separates one-time setup from annual license and support, and ask what changes when user counts cross 50.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Open WebUI vs Onyx, we start with a written scope that tests which tool fits each team, then build, document and support the chosen path.
How we scope
- Map which teams need general chat over models and which need answers grounded in connected company sources.
- Confirm identity requirements, including SSO, SCIM provisioning and role-based access, before choosing an edition.
- Agree the written scope, deliverables and timeline in writing before any work starts, since most engagements are fixed-scope.
- Define the license review for branding, user counts and internal versus customer-facing use before rollout.
How we build
- Deploy the chosen platform in your infrastructure, including the database, cache and index services it requires.
- Connect the model providers your teams already approve, whether self-hosted or cloud-hosted.
- Configure connectors and permission sync for source systems, and test that retrieval respects existing access rights.
- Run a pilot with one team in a parallel setup to compare answers and access behavior before any cutover.
How we hand over
- Document the architecture, configuration, identity mappings and license conditions for your own operators.
- Deliver a migration plan covering what must be rebuilt, such as custom pipelines, functions or themes, and what is re-indexed from source.
- Provide test evidence and control documentation that your internal reviewers and independent auditors can examine.
- Train your administrators on upgrades, backups and access reviews so the platform stays under your control.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan upgrades against each vendor's release line, testing new versions before they reach production users.
- Retest retrieval and access controls after connector, model or permission changes.
- Agree support scope and response expectations in the written contract rather than assuming them.
