When does an Open WebUI enterprise license become necessary?
The free terms hold for internal use with the Open WebUI branding intact. An enterprise license becomes necessary in two cases: when the deployment exceeds 50 users in a rolling 30-day window and the team wants to alter, remove or obscure the branding, or when it wants enterprise-exclusive offerings such as Terminals. Under the Open WebUI License, which applies from v0.6.6 (April 19, 2025), the branding clause is the only condition that changes the picture for a team that otherwise uses the software as it is. Count distinct end users over any rolling 30-day period, not seats purchased or accounts created, because that count decides whether the 50-user threshold applies. Check the current wording in the Open WebUI license documentation before you rely on it.
The free edition is enough when the deployment stays at or below 50 users in any rolling 30-day window, when the team is happy with the Open WebUI branding, or when the team holds written permission from the copyright holder or is a substantive contributor. It is also enough for a team above 50 users that keeps the branding and does not need enterprise-only features. The paid route is worth considering when white-labeling is a requirement for a customer-facing or branded rollout, or when the organization needs dedicated support. Open WebUI does not publish enterprise pricing, so ask the vendor for a quote based on your expected seat count and compare it with the internal cost of keeping the branding intact.
The BSD-3 option is separate from the enterprise decision. Code merged up to and including v0.6.5 remains BSD-3-Clause with no branding requirement, so a fork based on that code is not bound by the branding clause. This is not a free upgrade path to newer features, and it carries its own conditions: you give up later fixes and features that ship under the newer license, and you take on the maintenance of that fork. Have counsel confirm how the BSD-3 terms apply to your planned modifications before you choose it.
How internal, customer-facing and forked deployments differ
When staff are the only users and the Open WebUI branding stays visible, the branding clause generally does not require an enterprise license, provided the deployment stays at or below 50 users in any rolling 30-day period. Internal use with branding intact is free under the Open WebUI License, and you may still modify code and interface as long as you do not alter or remove the branding.
- User count: Track distinct end users over any rolling 30-day window, not just the headcount you licensed for.
- Branding intact: Keep logos, names and visible attribution unchanged in the login page, interface and about screens.
- Modifications: Internal customizations are permitted, but any change that touches branding moves you into a different category.
- Growth trigger: A team that grows past 50 active users must revisit this tab before the next onboarding wave.
- Records: Keep a dated user count, the version in use and a screenshot of the branding as deployed.
Confirm with the vendor or counsel how your organization counts users, especially contractors, service accounts and shared logins, before relying on the 50-user threshold.
If customers, partners or the public use the deployment, or if you rebrand it under your own name, the branding condition is more likely to apply, and the count of 50 users is no longer a safe harbor on its own. White-labeling, rebranding or modifying the original branding requires an enterprise license or written permission from the copyright holder. Enterprise licenses are available only to registered entities and organizations, and pricing is not published, so you will need a quote based on your expected seat count.
- Branding change: Any alteration or removal of Open WebUI branding in a customer-facing product needs an enterprise license or written permission.
- Hosting for others: Offering access to a team or business, including charging for access, is permitted only where the branding condition is met.
- Enterprise-only offerings: Features such as Terminals are enterprise-exclusive and need the enterprise license regardless of audience.
- Entity status: Confirm that your legal entity qualifies as registered before requesting a license.
- Records: Keep the signed license or permission letter with the deployment record and the branding configuration it covers.
Ask counsel whether a managed service you run for a client counts as a deployment for licensing purposes, and get the enterprise license scope confirmed in writing.
All code merged up to and including Open WebUI v0.6.5 remains BSD-3-Clause, with no branding requirement. A fork built from that code is not bound by the branding clause that applies from v0.6.6. Open WebUI's license documentation states that the license for v0.6.6 and later is not an OSI-approved open source license, so the BSD-3 base and the later code carry different terms.
- Source point: The fork must start from code through v0.6.5 specifically, not from a later release branch.
- Later merges: Pulling any code from v0.6.6 or later brings the Open WebUI License terms into the fork for that code.
- Dependencies: Third-party components carry their own licenses, so review each one separately.
- Maintenance: A fork from an older base receives no upstream fixes unless you backport them yourself.
- Records: Keep the exact commit hash the fork started from and a log of every merge from upstream.
Before relying on a BSD-3 fork, have counsel confirm the commit history and the license of each merged change, since this is a question of fact about your own code base.
Most teams fit one of the first two situations, and the choice depends on who sees the interface and whether the name or logo changes. The fork route is a separate decision with its own trade-offs, because it moves you away from the current release line and the features it contains. Each path needs a different written record, and the records should match what is actually deployed.
- Audience test: If only employees log in, start with the internal tab.
- Brand test: If the interface shows your name instead of Open WebUI, use the customer-facing tab.
- Version test: If the deployment was built from v0.6.5 or earlier code, read the fork tab before any upgrade.
- Mixed use: A tool used by staff and by clients may fall under more than one tab at once.
- Review cadence: Revisit the classification at each major upgrade and whenever the user count or audience changes.
Before committing, get a written answer from the vendor or counsel that covers your audience, your branding plan and your code base.
How the 50-user threshold works in a rolling 30-day window
The 50-user threshold counts end users across any rolling 30-day period, not named accounts and not seats bought in advance. The branding condition in the Open WebUI License is triggered by how many distinct people actually use the deployment within a 30-day window that moves forward each day. A team that buys 40 seats but has 70 people sign in across a month is likely outside the threshold for that month, and a team with 200 accounts where only 30 people log in during any 30-day window may be inside it. Because the window is rolling, a deployment that briefly crosses 50 users may still be affected for the period in which it crossed. Confirm the exact counting method, including how it treats inactive accounts, service accounts and API-only use, against the Open WebUI license documentation and the LICENSE file before you rely on any reading of it.
Identity provisioning can change the count quickly. Open WebUI documents SSO through OIDC and LDAP and SCIM 2.0 user and group provisioning, so a directory sync can create hundreds of accounts on the day it runs without any of those people ever signing in. Whether a provisioned but never-active account counts as an end user is a question to put to the vendor in writing, and the answer should be checked against the license text rather than assumed. Also confirm how shared accounts, group-based access and automation keys are classified, because each of these can make the active count differ from the account count.
Keep evidence that lets you prove your count to an auditor, a customer or the copyright holder. Useful records include the Open WebUI admin user list with last-login timestamps, identity provider logs for successful authentications by application, SCIM provisioning and deprovisioning logs, and a dated monthly export of distinct active users. Teams with growth plans should model the count before rollout, using a worst-case month that includes pilot groups, seasonal staff and contractors, and decide in advance whether they will need an enterprise license or must restrict access. Ask Open WebUI enterprise sales how they expect seat counts to be stated in a quote, since pricing is not published.
What the enterprise license adds beyond the branding exception
This table separates what the Open WebUI License allows without payment from what an enterprise license adds, and flags the features whose edition gating you must confirm. Read the first four rows to settle the branding question, then check the feature rows against the current documentation and your quote.
| Capability | Free use under the Open WebUI License | Enterprise license scope |
|---|---|---|
| Internal use with branding intact | Permitted when the branding condition is met, such as 50 or fewer users in a rolling 30-day period | Covered, but not required for internal use with branding intact |
| White-labeling and custom branding | Not permitted above 50 users unless written permission exists | Included, per the Open WebUI Enterprise docs |
| Modifying the original branding | Not permitted above 50 users without an enterprise license or written permission | Included, per the Open WebUI Enterprise docs |
| Enterprise-exclusive offerings such as Terminals | Not included in the free license | Included, per the Open WebUI Enterprise docs; confirm the current list with sales |
| Dedicated support options | Community channels only; confirm current options in the docs | Dedicated support options included; scope and response terms must be confirmed in writing |
| SSO through OIDC and LDAP | Documented feature; confirm whether this is open to all editions | Confirm with Open WebUI which items are gated by edition before assuming either way |
| SCIM 2.0 user and group provisioning | Documented feature; confirm edition gating before deployment | Confirm with Open WebUI before assuming either way |
| Role-based access control, API keys and authenticator-app MFA | Documented features; confirm edition gating before assuming either way | Confirm with Open WebUI before assuming either way |
| Enterprise license eligibility | Not applicable | Available only to registered entities and organizations; pricing is quoted after contacting enterprise sales |
License, support and update terms for each option
Open WebUI now ships under two different license regimes depending on the version you run. The cards below separate the Open WebUI License that applies from v0.6.6, the enterprise license layered on top of it, and the BSD-3-Clause code that stays frozen at v0.6.5. Check the vendor's documentation for the final word on update and support scope.
Open WebUI License from v0.6.6
Applies to every release from v0.6.6 (April 19, 2025) onward, including v0.12.3. The license is not OSI-approved, and its branding clause is the condition that matters. Internal teams and businesses may modify and host the code, but altering or removing Open WebUI branding is allowed only at 50 or fewer users in a rolling 30-day window, with an enterprise license, or with written permission from the copyright holder. Upgrades carry the same terms, so check the user count against each release you plan to adopt.
Enterprise license
Required for white-labeling, rebranding or modifying the original branding, and for enterprise-exclusive offerings such as Terminals. Internal use with branding intact does not need it. Enterprise licenses are available only to registered entities and organizations, not to individuals or unregistered groups. Dedicated support options come with this tier, and pricing is not published, so ask for the scope, seat count basis and support terms in writing before you rely on them.
BSD-3-Clause code through v0.6.5
All code merged up to and including v0.6.5 remains BSD-3-Clause with no branding requirement, so forks started from that code are not bound by the branding clause. This is the basis of the BSD-3 fork option, but a fork is a separate product you maintain. Ask whether security fixes and feature work will reach it, and who in your organization owns merging upstream changes and checking each one against your license position.
Support under the open license
The Open WebUI License carries no dedicated vendor support in the terms described in the docs. Support for the community edition comes from public channels and the project's own release process, so your team carries patching, upgrade testing and incident response. Confirm the support channels and response expectations in the vendor's documentation, and budget internal or third-party effort for the operational work.
Upgrade terms across releases
Each release is a new artifact under the same license family, so an upgrade does not reset the branding condition. Confirm, release by release, that your user count and branding plan still fit the terms, especially after a rise in headcount or a move to customer-facing use. Test upgrades in a staging copy first, since the scaling guide recommends PostgreSQL and shared Redis for multi-instance setups.
Eligibility and proof of entitlement
Ask who on your side can sign an enterprise agreement, what proof of registered entity status the vendor requires, and whether the license covers affiliates, contractors or customer-facing users. Keep written records of the license basis for each deployment, including any contributor permission, so an internal audit or customer review can trace which terms applied at which version and user count.
How buyers request and scope an enterprise license quote
Open WebUI does not publish enterprise license pricing. The quote follows from contacting enterprise sales with an expected seat count, so the first decision is who on your side owns that conversation and what number you will give them. Enterprise licenses are available only to registered entities and organizations, so confirm before the call that your legal entity can contract directly and that you can supply its registration details. Individual teams or unregistered groups should not expect to buy one. Ask sales to state in writing what the license covers, what term applies and whether the seat basis is the same as the 50-user threshold in the branding clause.
Before the conversation, prepare user counts for today and for the next budget period, with a clear method for counting. The branding condition is measured in users in a rolling 30-day window, so distinguish named accounts from people who actually log in, and record which groups will use the instance. Write down the branding changes you need, such as white-labeling, a custom name or logo, or modified branding, because the enterprise license is the route for those changes. Also state whether you plan to use enterprise-exclusive offerings such as Terminals. If you do not know yet, say so, since the scope affects the quote and a later addition may require a new agreement.
Finally, document the support expectations and the deployment environment. Note who will operate the instance, which identity provider and vector database you plan to connect, and whether it runs on a single container, a multi-replica setup or Kubernetes with Helm, as listed in the Open WebUI features documentation. Ask the vendor which support options come with the license, what response expectations apply and how upgrades between releases are handled. If you are weighing the Open WebUI enterprise documentation against the BSD-3-Clause fork option, get a written statement of what each path permits before you commit.
What an Open WebUI deployment costs under each license
This table lists each cost component of an Open WebUI deployment, who gets paid for it, whether it is one-time or recurring, and what moves it up or down. Read it against your user count and branding plans, because the license fee is the only line that depends on the enterprise decision.
| Cost component | One-time or recurring | Who is paid | What drives it up or down |
|---|---|---|---|
| Enterprise license fee | Recurring under the subscription terms you agree (confirm term and renewal) | Open WebUI (enterprise sales) | Not published. Quoted after contact with an expected seat count. Ask whether the quote covers white-labeling and which support tier is included. |
| Single instance infrastructure | Recurring hosting | Your cloud provider or data center team, or DeployOpen if scoped that way | Documented install paths are Docker, Docker Compose, Kubernetes with Helm and pip. Load, model location and retention set the size. |
| Multi-replica infrastructure | Recurring hosting | Your cloud provider or data center team | Needs PostgreSQL instead of SQLite, Redis for sessions and WebSockets, and shared file storage reachable from every replica. Each added service adds hosting and monitoring. |
| Vector database hosting (13 supported options) | Recurring hosting and storage | Your platform team, a managed database provider or DeployOpen under a written scope | Choice of store drives cost. Options include ChromaDB, PGVector, Qdrant, Milvus and Elasticsearch. Corpus size, replicas and backups set the footprint. |
| Implementation and integration | One-time, plus change requests | DeployOpen or your internal engineers | Identity setup (OIDC, LDAP, SCIM 2.0), model provider connections, storage and vector store choice, and branding work all add scope. Fixed scope is agreed in writing before work starts. |
| Internal operations and upgrades | Recurring staff time | Your internal team or a retainer provider | Release cadence, backups, PostgreSQL and Redis maintenance and testing each upgrade. Pinning versions and keeping a test replica reduces surprises. |
| Independent review of the deployment | One-time per assessment, plus periodic retesting | Security testers and auditors you engage | Scope of the environment, number of integrations and the assessment framework you need. DeployOpen prepares evidence but does not issue audit reports or certifications. |
Questions buyers ask about the Open WebUI enterprise license
Is the free Open WebUI license enough for a 200-person company?
It depends on whether you will alter or remove Open WebUI branding and how many end users the deployment serves. The branding clause applies from v0.6.6 when a deployment has more than 50 end users in a rolling 30-day period. At 200 people, if every user is an end user and you keep the branding intact, the free terms still cover internal use. If you plan to rebrand the interface, white-label it, or offer enterprise-exclusive features, you need an enterprise license, written permission from the copyright holder, or a different base. Confirm the user count definition, including whether contractors and service accounts count, with the vendor or counsel before you decide.
How much does an Open WebUI enterprise license cost and how is it quoted?
Open WebUI does not publish enterprise license pricing. You contact enterprise sales with an expected seat count, and the quote follows from that number and the support options you select. Enterprise licenses are available only to registered entities and organizations, so expect to provide company registration details. The cost is recurring under most commercial terms, so ask whether the quote is annual, multi-year or perpetual, what renewal pricing looks like, and what happens to your rights if you stop renewing. Ask for the terms in writing and have counsel review them before signing.
What does the enterprise license add beyond removing the branding clause?
The enterprise docs describe three things: permission to white-label, rebrand or modify the original branding, access to enterprise-exclusive offerings such as Terminals, and dedicated support options. Internal use with branding intact stays free without it. Before buying, list the exact features your teams need and confirm in writing which ones sit behind the enterprise license. Do not assume that a feature in the open-source code is available to you under the free terms if the docs place it in an enterprise-only offering.
Can a fork from v0.6.5 avoid the branding clause?
Code merged up to and including v0.6.5 remains BSD-3-Clause with no branding requirement, so a fork based on that code is not bound by the clause. The limits matter, though. The fork inherits only the code through v0.6.5, so you lose later fixes, security patches and features unless your team backports them. Any code merged after v0.6.5 falls under the Open WebUI License. Have counsel confirm the exact commit history of your fork, and confirm with the vendor how they treat forked code and any trademark use of the name.
How long does an enterprise rollout take and what drives that time?
No duration is published for licensing or rollout, so ask for a schedule tied to a written scope. The main drivers are the number of identity integrations (OIDC, LDAP and SCIM provisioning), the choice of database, the number of replicas, the model providers you connect, and the knowledge sources you index. If you run multiple instances, the scaling guide requires PostgreSQL instead of SQLite, plus Redis for shared state and shared file storage. Each of these adds build and test work. A fixed-scope agreement with written deliverables makes the timeline easier to compare across bids.
What does our internal team need to provide during a rollout?
Your team needs to supply access and decisions, not only budget. Expect to provide the identity provider details for SSO, group mappings for role-based access, the cloud or data center target, storage for uploads and knowledge, and the model endpoints you approve for use. Someone must own the user count tracking if you rely on the 50-user threshold, and someone must approve the branding decision. Ask the implementation partner to list these inputs in the written scope so you can assign owners before work begins.
Can our team make the branding decision and run the license alone?
Yes, if you have counsel to read the license and a named owner who tracks user counts and approvals. The decision has three branches: keep branding and stay on the free terms under 50 users, buy an enterprise license for white-labeling, or obtain written permission from the copyright holder. Your team can handle the internal work, but the legal reading, the contract negotiation and the record of user counts should not rest on engineering alone. If you lack that capacity, a partner can prepare the configuration and evidence, while counsel reviews the license terms.
Does DeployOpen provide the Open WebUI enterprise license?
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Enterprise license terms come from Open WebUI, so confirm pricing, eligibility and contract terms with Open WebUI enterprise sales. DeployOpen's role is the implementation work in your environment, and the written scope sets its deliverables and timeline. Ask for the scope in writing before you commit, so the licensing decision and the engineering work are tracked separately.
How to move from the free license to an enterprise license, or change course
This sequence tells you whether the branding clause applies to your deployment, what a paid license would cover, and how to upgrade without breaking a scaled setup. Each step ends with a record you can file, so the decision can be checked later against the license text.
Measure the rolling 30-day user count
Start by counting the distinct end users who accessed the deployment in any rolling 30-day window, not only the number of accounts you provisioned. Your platform or IT team can pull this from the application's user and login records, and the result should be a dated figure for each window you review. The step is done when you have a written count showing whether the deployment has stayed at or below 50 users, or has exceeded that threshold in any window. Confirm how the license text defines an end user before you rely on the number, because a provisioned account that never logs in may be counted differently from an active one.
Decide whether branding must change
Next, decide whether you need to alter, remove or obscure Open WebUI branding. Internal use with the logo and name intact does not require an enterprise license, so a team that keeps the interface as shipped can stop here. Changing the logo, name, or other branding for staff, customers or partners is the trigger for the paid path. The output is a short written decision signed off by the business owner, with the reason recorded. If you are unsure whether a particular change counts as altering branding, put that question to the copyright holder or to Open WebUI's enterprise sales team before you proceed.
Request a written quote with an expected seat count
If you need an enterprise license, contact Open WebUI's enterprise sales team with a stated expected seat count and the branding changes you plan to make. Pricing is not published, so the quote is the only way to learn the cost. Ask for the license term, what support is included, what is one-time and what recurs, and whether renewal or seat changes affect the price. Ask the vendor to put the scope and the license terms in writing. The step is done when you hold a quote that names the seat count, the licensed features and the support level, and you can compare it against the cost of keeping branding intact or moving to a fork.
Confirm eligibility as a registered entity
Enterprise licenses are available only to registered entities and organizations. Before signing, confirm that the legal entity that will hold the license is registered and that the contracting person can bind it. Individual users, hobby projects and unregistered teams should not expect this route to be open to them. Your legal or procurement team should verify the entity details and save the confirmation with the quote. The step is complete when the entity name on the quote matches the registered name in your records, and the signatory is authorized under your internal policy.
Plan the upgrade against the release notes
Before you change versions, read the GitHub release notes for the version you run and for each version you plan to reach. Open WebUI publishes releases on its GitHub releases page, and the notes show configuration changes, database migrations and any changes that affect licensing or branding. Test the upgrade in a non-production copy with a backup of your data and your configuration. The step is complete when you have a tested upgrade record listing the source version, target version, migration results and the rollback plan you would use if the upgrade fails.
Check the scaled architecture before growth
If user growth means more than one replica, confirm the architecture first. Open WebUI's scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments, and it needs Redis as a shared state store for sessions, websocket connections and application state. Uploads and knowledge must also sit on shared file storage that every replica can reach. Check each component in your environment and run a session test across replicas. The step is done when you have a diagram of the running components and a test record showing that a user session survives a replica restart.
Record the decision and recheck the license
Close the sequence by writing down the outcome: keep the free license with branding intact, buy an enterprise license, or change course to a fork based on code through v0.6.5. A fork from v0.6.5 or earlier is not bound by the branding clause, but it will not receive later Open WebUI changes unless your team ports them. Store the decision, the quote if one exists, and the license version you relied on. Confirm each step against the current license text on the license page before any contract is signed, because the terms can change between releases. The step is complete when the decision record names the license text you checked and the date you checked it.
How DeployOpen scopes and supports an Open WebUI deployment
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Open WebUI, that starts with a written decision on whether the branding clause applies to your user count and whether an enterprise license is needed before any build work begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We count current end users against the 50-user rolling 30-day threshold and document which branding terms apply to your deployment.
- We confirm with you whether a paid enterprise license, written contributor permission or a BSD-3 fork from v0.6.5 or earlier fits your plans.
How we build
- We deploy Open WebUI in your cloud account, data center or air-gapped network, using the install method your platform team already runs.
- We configure SSO, SCIM provisioning, groups and role-based access to match your identity setup and access policies.
- We connect your approved model providers, including local Ollama models and OpenAI-compatible endpoints, and test each one before users arrive.
How we hand over
- You receive configuration records, architecture notes and a branding compliance record that reflects the license terms agreed in scope.
- We run documented acceptance testing against the written scope, and we list each open item and who owns it.
- Runbooks cover backups, upgrades and the license conditions your administrators must keep tracking as user counts change.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial build.
- We review each new Open WebUI release against your branding position and your configuration before you apply it.
- Confirm with us which support, response and upgrade terms apply to your retainer, since DeployOpen does not publish a price list and quotes follow the written scope.
