Open WebUI vs LobeHub: which self-hosted chat fits your company
A team shortlisting self-hosted ChatGPT-style interfaces for staff should start with two questions: how many people will use the tool, and who will run its database and storage. Open WebUI fits best when you want chat over Ollama or OpenAI-compatible models, need the platform to run offline, and want identity controls such as OIDC, LDAP and SCIM 2.0 user and group provisioning with role-based access control. Its install paths include Docker, Docker Compose, Kubernetes with Helm and pip, and its documentation describes it as built to run entirely offline. Read the Open WebUI License before you commit, because the branding clause applies to deployments with more than 50 end users in a rolling 30-day period.
LobeHub fits teams that want a PostgreSQL-centered stack and sign-in through Better Auth, which supports email and password, magic links, OAuth and generic OpenID Connect or OAuth 2.0 providers. Its Docker guide uses PostgreSQL 17 with the pgvector and pg_search extensions, set through a DATABASE_URL connection string. LobeHub's README now also presents the product as a platform for organizing AI agents into scheduled, reported operations. Choose it only if that agent direction matches your roadmap. Its quick start for model access uses an OpenAI API key, so confirm how local models would be connected in your environment before you plan around them.
The decision turns on three things. First, your user count against the 50-user branding threshold in the Open WebUI License. Second, the LobeHub Community License, which permits commercial use as a frontend and backend service without modifying the source but requires a commercial license to develop and distribute derivative works. If you plan custom code, read that condition with counsel first. Third, who will operate PostgreSQL, Redis and file storage. Open WebUI needs Redis and shared storage once you run multiple replicas, and LobeHub depends on a PostgreSQL 17 instance with extensions. Name an owner for each service before you request a quote.
Which factors decide the choice for a company rollout
Four factors tend to settle this choice: how many people will use the platform, whether your team will change the code, how identity must work, and whether you want chat only or agent operations. Each one matters under specific conditions, so check them in the order they constrain your rollout.
User volume against the branding clause
The Open WebUI License restricts altering or removing Open WebUI branding once a deployment exceeds 50 end users in a rolling 30-day period, unless you hold an enterprise license or written permission from the copyright holder. This matters only if you plan to rebrand or remove the logo. If you stay under the threshold or keep the branding, the clause does not change your rollout. Count real end users, not licensed seats, and confirm the terms with the license text before you commit.
Planned code changes and redistribution
LobeHub's Community License, based on Apache 2.0, lets you run LobeChat commercially without modifying the source, but a commercial license is required to develop and distribute derivative works. Open WebUI's branding clause is a narrower restriction. If your team plans to fork, patch or ship a modified build to other companies or customers, read both licenses closely and ask counsel whether your use counts as distribution. Internal patches with no distribution are a different question from a customer-facing product.
SCIM 2.0 provisioning against Better Auth SSO
Open WebUI documents SSO through OIDC and LDAP, plus SCIM 2.0 user and group provisioning, so joiners and leavers can flow from your identity provider without manual account work. LobeHub uses Better Auth with email, magic links, OAuth and SSO providers such as Google, GitHub and Microsoft, and any generic OpenID Connect or OAuth 2.0 provider. If your audit needs automated deprovisioning or group-based access, confirm whether LobeHub's authentication covers SCIM-style provisioning before you rely on it.
Chat only or agent operations
LobeHub's README now presents the product as a platform for organizing AI agents into scheduled, reported operations, alongside its chat interface and plugin system. Open WebUI is built around chat, knowledge bases and model access. If your team needs only a shared chat workspace, the extra agent surface adds configuration and review effort without a clear gain. If you expect to run recurring agent tasks, check how scheduling, reporting and plugin access are governed and whether they fit your change process.
Database and storage footprint
Open WebUI requires PostgreSQL rather than SQLite for multi-instance deployments, and multiple replicas also need Redis and shared file storage. LobeHub's Docker guide uses PostgreSQL 17 with the pgvector and pg_search extensions, set through a DATABASE_URL connection string, for vector and full-text search. Both designs move the work toward a database you must back up and tune. Ask your platform team which database operations they already support and who owns extension upgrades.
Model provider and API key policy
Open WebUI connects to Ollama, OpenAI, Anthropic or any OpenAI-compatible provider from one interface, which suits teams running local models alongside cloud services. LobeHub's README quick start for model access uses an OpenAI API key, either from the official service or a third-party proxy. If your policy requires local inference or controlled gateways, verify which providers and endpoints each platform handles in your environment and who holds the keys.
Which platform fits which company scenario
This table maps six common company scenarios to the platform that fits each one better, with the reason in the adjacent cell. Read it as a starting point, because the deciding factors are usually user count, whether you must keep Open WebUI's branding, whether you need SCIM or offline operation, and whether you plan to change the source. Where a cell says to confirm, check LobeHub's current documentation or ask the vendor before you commit.
| Scenario | Better fit | Why |
|---|---|---|
| Small internal rollout, 50 users or fewer | Open WebUI | Branding clause does not apply at 50 or fewer users in a rolling 30-day period, so setup and branding stay unchanged. |
| Large staff rollout above 50 users | Open WebUI if you keep its branding, LobeHub if branding is not a constraint | Above 50 users, Open WebUI branding must stay intact unless you hold an enterprise license or written permission. Confirm LobeHub's terms for your service model. |
| Offline or air-gapped deployment | Open WebUI | Its documentation describes a platform built to run entirely offline, with Ollama for local models. Confirm LobeHub's offline and model access options first. |
| Team needing SCIM provisioning | Open WebUI | Open WebUI documents SCIM 2.0 user and group provisioning alongside OIDC and LDAP. For LobeHub, confirm SCIM support in its authentication docs. |
| Team building internal tooling on the source | Open WebUI, if branding stays intact | LobeHub needs a commercial license for derivative works. Open WebUI's main restriction is branding, so confirm its full license text. |
| Team that wants agent scheduling in the same product | LobeHub | Its README presents the product as a platform for scheduled, reported agent operations. Confirm the maturity of that feature before adopting it. |
How Open WebUI and LobeHub are built and deployed
Open WebUI lists three official install methods: Docker and Docker Compose, Kubernetes with Helm, and a Python path using pip install open-webui followed by open-webui serve. A single container is the simplest start, and it can run on SQLite. Once you plan more than one instance, the deployment changes shape, because the scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments since SQLite does not handle concurrent writes from multiple processes well.
- Single container: Docker or the pip path suits a pilot or a small team on one host.
- Compose or Helm: These are the usual routes when you want repeatable configuration and a defined upgrade process.
- PostgreSQL: Required for multi-instance deployments, so plan a managed or self-run database before the second replica.
- Vector database choice: Open WebUI's retrieval features support 13 vector databases, including ChromaDB, PGVector, Qdrant, Milvus and Elasticsearch, so you can pick a store that matches your existing operations.
- Hybrid retrieval: Retrieval supports hybrid BM25 plus vector search and cross-encoder reranking, which adds components to tune.
Confirm with your platform team which vector database and database service you already operate, since that choice changes the backup and monitoring scope.
Running several Open WebUI replicas adds shared state that a single container keeps in memory or on local disk. The scaling guide states that multiple replicas need Redis as a shared state store for sessions, websocket connections and application state. Uploads and knowledge also need shared file storage so every replica can reach the same files. These are the pieces that turn a simple install into a service your team must design, secure and back up.
- Redis: Holds sessions, websocket connections and application state across replicas.
- Shared file storage: Keeps uploads and knowledge reachable from every replica, so the storage backend becomes part of your recovery plan.
- PostgreSQL: Stores the application database for all replicas.
- Secret key consistency: Replicas need to share the same secret key so that sessions validate across instances.
- Operations load: Each added service needs its own patching, monitoring and backup routine.
Ask the vendor or read the scaling guide for the current list of required settings for your version before you size the environment, because the requirements are tied to the release you deploy.
LobeHub publishes a lobehub/lobehub Docker image and a Docker Compose path for self-hosting. Its Docker guide uses PostgreSQL 17 with the pgvector and pg_search extensions, which handle vector and full-text search inside the database. The connection is set through a DATABASE_URL connection string, so the database is a required dependency from the first run rather than an option you add later.
- Image and Compose: The
lobehub/lobehubimage and Compose file bring the application up on your own host or cluster. - PostgreSQL 17: Required, with the pgvector and pg_search extensions enabled for vector and full-text search.
- `DATABASE_URL`: The single connection string that binds the application to the database, so it belongs in your secrets management process.
- Extension management: Your database team must confirm that the extensions are available and supported on your managed PostgreSQL service.
- Model access: The quick start uses an OpenAI API key, either through the official service or a third-party proxy.
Confirm the exact image tag, extension versions and upgrade path in the Docker guide before you schedule a rollout.
The LobeHub README lists self-hosted deployment on Vercel, Zeabur, Sealos or Alibaba Cloud, in addition to the Docker image and Compose path. These platforms differ in who runs the underlying infrastructure, which matters if your policy requires that data stay in your cloud accounts or data centers. Each option moves some operating work to the platform provider and leaves other work with your team.
- Vercel and Zeabur: Hosted build and run platforms, so confirm where the database and data are located and who operates them.
- Sealos and Alibaba Cloud: Cloud-based options that may fit teams already contracted with those providers, so check regional and data residency terms.
- Your own infrastructure: The Docker and Compose route is the one that most directly keeps the stack in your environment.
- Patching and backups: Under a platform option, confirm which party applies updates and takes database backups.
- Support boundaries: Establish which party supports the application, the database and the platform.
Before choosing a hosted option, check the README and your provider contract for data location, backup responsibilities and the process for upgrades.
Both products connect to enterprise identity, but the setup differs. Open WebUI documents SSO through OIDC and LDAP, SCIM 2.0 user and group provisioning, role-based access control with groups and per-resource permissions, API keys and authenticator-app MFA. LobeHub uses Better Auth, which supports email and password, magic links, OAuth and SSO providers such as Google, GitHub and Microsoft, plus any generic OpenID Connect or OAuth 2.0 provider. Identity decisions affect how users are onboarded and removed, so they shape day-to-day operations.
- Open WebUI SCIM 2.0: Provisioning and deprovisioning can follow your directory, which reduces manual account cleanup.
- Open WebUI RBAC: Groups and per-resource permissions control access to models and knowledge.
- LobeHub Better Auth: Supports generic OpenID Connect or OAuth 2.0, so confirm that your identity provider fits that pattern.
- LobeHub provisioning: Confirm whether user lifecycle and group sync are available in your version, because the documented options focus on sign-in.
- MFA: Open WebUI documents authenticator-app MFA, so verify what LobeHub enforces before relying on it.
Test your identity provider integration in a staging environment with a representative set of users and groups before you open access.
Capability comparison for user management, storage and providers
This table compares the identity, storage, provider and agent capabilities that matter most when Open WebUI or LobeHub becomes a company-wide tool. Where the researched facts do not cover a row for one platform, the cell tells you what to confirm before you decide. The main takeaway is that Open WebUI documents more of its identity controls, while LobeHub's database and authentication choices are more tightly tied to PostgreSQL and Better Auth.
| Capability | Open WebUI | LobeHub |
|---|---|---|
| License | Open WebUI License from v0.6.6. Branding clause applies above 50 users in 30 days. | LobeHub Community License from 1.0. Commercial use as a service is allowed unmodified; derivative works need a license. |
| User management and RBAC | Role-based access control with groups and per-resource permissions. | Confirm user administration and role model in LobeHub's current docs. |
| SSO | OIDC and LDAP documented. | Better Auth with Google, GitHub, Microsoft and generic OIDC or OAuth 2.0. Confirm LDAP support. |
| SCIM 2.0 provisioning | User and group provisioning documented. | Not covered in the facts reviewed. Confirm before relying on automated provisioning. |
| MFA and API keys | Authenticator-app MFA and API keys documented. | Confirm MFA and API key options in the authentication and admin documentation. |
| Model providers | Ollama, OpenAI, Anthropic and any OpenAI-compatible provider from one interface. | Quick start uses an OpenAI API key or proxy. Confirm the full provider list and local model support. |
| Vector search | Supports 13 vector databases, including PGVector, Qdrant and Milvus, with hybrid search and reranking. | PostgreSQL with pgvector and pg_search for vector and full-text search. |
| Database requirements | SQLite for a single instance. PostgreSQL and Redis are required for multiple replicas, plus shared file storage. | PostgreSQL 17 set through a DATABASE_URL connection string in the Docker guide. |
| Agent operations | Confirm agent scheduling and reporting features in current Open WebUI documentation. | README presents scheduled, reported agent operations and a plugins gateway. Confirm how this works in your deployment. |
What the Open WebUI License and LobeHub Community License allow
Code merged up to and including v0.6.5 remains under the BSD-3-Clause license, the permissive terms Open WebUI used before the change. Those terms do not carry the branding restriction that applies from v0.6.6, so a deployment built only from that code line is governed by the base terms. Which release your team actually runs decides which set of terms applies, so the version check comes first.
- Permissive base: BSD-3-Clause generally permits use, modification and redistribution, with conditions such as keeping the copyright notice and disclaimer.
- Version boundary: The change took effect with v0.6.6, released April 19, 2025. Code through v0.6.5 keeps the BSD-3-Clause terms.
- Forks from that line: Teams that want the older terms can build from the BSD-3-Clause code. Confirm with counsel that the fork and its release choice fit your intended use.
- Third-party components: The core license does not automatically cover plugins, models or extensions you add. Review each of those separately.
Confirm the exact version and image tag in production, and have counsel confirm the BSD-3-Clause position for any code you base a build on.
From v0.6.6, released April 19, 2025, Open WebUI code is distributed under the Open WebUI License, which adds a branding protection clause to the base terms. The clause forbids altering or removing Open WebUI branding in deployments that exceed 50 users in any rolling 30-day period. Below that threshold, the branding restriction does not apply by its terms, but the threshold is counted on end users, so growth can change the answer without any change to the code.
- Threshold: The count is end users in a rolling 30-day window. Read the license definition of end user before you count.
- Three exceptions: Branding may be changed if the deployment has no more than 50 end users in that window, the copyright holder gives written permission, or the licensee holds an enterprise license.
- Internal use: Above 50 users, staff-only use still falls under the clause unless one of the exceptions applies. Internal deployments are not automatically exempt.
- Growth risk: A pilot under 50 users can cross the threshold after rollout, which changes the branding position without any action by the team.
Ask counsel to read the LICENSE file for the exact user-count wording, including how it treats contractors and users who reach the platform through integrations.
The enterprise license is the route that covers branding changes without relying on a written permission from the copyright holder. Open WebUI describes its enterprise licenses as allowing white-labeling and custom branding, with dedicated support options. Pricing is not published. The vendor quotes after an enterprise sales contact with an expected seat count, so the commercial position depends on the agreement rather than on the public license text.
- White-label option: The enterprise license permits white-labeling and custom branding, the change the base license restricts above 50 users.
- Dedicated support: Support is described as dedicated, but the response commitments belong in the signed agreement. Ask for them in writing.
- Quote basis: Expect the quote to depend on the seat count you state. Ask which charges are one-time and which recur each year.
- Scope of grant: Confirm which environments, user counts and copies are covered, including staging, test and disaster recovery deployments.
Get the license scope and the quote in writing before rollout, and ask counsel to compare the enterprise terms with the branding clause in the base license.
LobeChat is licensed from version 1.0 under the LobeHub Community License, which is based on Apache License 2.0. The license allows commercial use of the software as a frontend and backend service without modifying the source. Developing and distributing derivative works requires a separate commercial license, so the line between running the software and changing it is the decision point for most teams.
- Service use: Running LobeHub as a frontend and backend service for your organization is commercial use that the license permits without source modifications.
- Modified builds: Changing the code to build your own version, or distributing a modified build, is a derivative work that needs a commercial license.
- Version boundary: The Community License applies from version 1.0. Confirm the terms that apply to any earlier release before you use it.
- Repository history: The repository is the former lobe-chat project. Check the license file in the copy you deploy, not an older README or article.
Ask counsel to define derivative work for your setup, including patched images, configuration overlays and custom plugins, because those can fall on either side of the line.
The LobeHub license sets terms for contributors, and those terms affect code your team submits upstream. Under them, contributors agree that the producer can make the license stricter or more relaxed, and that the producer can use contributed code commercially, including in its cloud edition. These terms matter when you send fixes back to the project or depend on community code inside a self-hosted build.
- License changes: Contributors agree the producer may change the license, so the terms you accept today may not stay fixed.
- Commercial reuse: Contributed code can be used commercially by the producer, including in the cloud edition.
- Upstream patches: Patches you submit fall under the contributor terms. Keep internal details, customer data and proprietary configuration out of them.
- Feature alignment: Confirm that the features you need are documented for self-hosting, since the product direction is shaped by the cloud offering.
Read the contributor clause in the current LICENSE file, and have counsel confirm how it fits your internal contribution policy before anyone opens a pull request.
How LobeHub's move toward agent operations changes the choice
The LobeHub README now presents the product as a platform for organizing AI agents into scheduled, reported operations, alongside its chat interface and a plugin system served through a plugins gateway. That changes what you are deploying. An Open WebUI rollout is mainly a shared chat workspace with knowledge bases, tools and model connections. A LobeHub rollout may also run recurring agent jobs that call models, plugins and outside services without a person starting each run. Teams that want automated agent runs with reports on what happened will find that LobeHub's direction matches their goal more closely.
That benefit brings extra operating surface. Scheduled runs need a scheduler to be kept running and monitored, plugin services need their own hosting, access control and version tracking, and reported output needs someone to review it. Each agent that can act on data or systems also adds a review burden: who approves a new agent, who checks its outputs, and who can stop a run that misbehaves. Ask the vendor or the public documentation exactly how scheduling, plugin hosting and run reports are configured, and which of these features are included in the license you are considering.
Open WebUI's focus is chat, knowledge and tools, so its operating surface is smaller for a company that mainly wants staff to chat with models over their own documents. Whichever direction you choose, test each feature in your own environment before committing: run one scheduled agent end to end, confirm where its logs and reports are stored, check how plugin credentials are isolated, and verify that you can disable a job without a redeploy. Treat agent operations as a separate approval decision from the chat rollout.
What drives running cost for each platform
Running either platform costs more than its license line. The cards below separate the infrastructure, staff, licensing and model usage costs, and note which ones are paid once and which recur every month.
Database and shared state infrastructure
Open WebUI needs PostgreSQL instead of SQLite once you run multiple instances, and Redis as a shared state store for sessions and WebSocket connections when you run multiple replicas. LobeHub's Docker guide uses PostgreSQL 17 with the pgvector and pg_search extensions, set through DATABASE_URL. Both recur as hosting, backups and patching costs. Ask for the expected node count, managed or self-run database choice, and backup retention in any quote.
Shared file storage
Multi-replica Open WebUI deployments need shared file storage so uploads and knowledge stay reachable from every replica. This is a recurring capacity cost that grows with the document library and user uploads. Confirm which storage backend your platform team will provision, who owns its backups, and how capacity growth will be forecast before the rollout date is set.
Upgrade and release tracking staff time
Both projects ship often. Open WebUI v0.12.3 was published on October 16, 2026, following v0.12.0 on October 10, and LobeHub v2.2.20 was published on October 18, 2026. Someone must test each release, check database migrations and apply changes in your environment. This is recurring internal time or retained DeployOpen support, so ask who owns upgrades and how fast security fixes are applied.
Open WebUI enterprise license quote
Above 50 end users in a rolling 30-day period, changing Open WebUI branding requires an enterprise license or written permission from the copyright holder. Enterprise licenses are quoted after contacting sales with an expected seat count, and pricing is not published. This is a recurring subscription if you need it. Ask whether the quote covers white-labeling, support scope, renewal terms and seat growth.
Model provider usage
Both platforms pass requests to model providers, so token charges from OpenAI, Anthropic or other APIs are paid to the provider, not to the platform vendor. Usage recurs and rises with user count and document context size. Local models through Ollama shift this cost into GPU or server hardware. Ask for a token budget per team and a monthly usage report before you commit to a provider.
One-time setup and integration work
Initial installation, SSO wiring through OIDC or Better Auth, SCIM provisioning, and the first backup and restore test are mostly one-time costs. Fixed-scope work is agreed in writing before it starts, so the scope document should name each integration. Ask a provider to separate setup effort from recurring retainer work so you can see which costs stop after go-live.
How to move users and data between the two platforms
This sequence moves a company's users, chat history, settings and knowledge from one interface to the other without losing track of who can see what. It ends with a tested pilot group and a cut over that leaves a clear record of what was retired and what was rebuilt.
Inventory users, models and knowledge bases
The platform owner lists every active user, group and role in the current Open WebUI instance, along with the model connections, tools and knowledge collections each group depends on. Compare that list against the providers your target will reach through its own model configuration, because LobeHub's quick start is built around an OpenAI API key and any provider you use must be configured there. The step is done when the team has a signed inventory that names each knowledge collection, its owner and the data classification it carries.
Build the target database and identity setup first
Before any data moves, the infrastructure team deploys the LobeHub target with PostgreSQL 17 and the pgvector and pg_search extensions, connected through DATABASE_URL, and configures Better Auth with the identity provider you intend to use. Open WebUI's SSO through OIDC, LDAP or SCIM provisioning does not carry over automatically, so the target's login path must be proven with test accounts first. The step is complete when test users can sign in, their roles resolve as planned and the database backup routine has been tested on the new instance.
Export chat history and settings
The platform owner exports conversations, prompts and personal settings from Open WebUI using its supported export paths, then confirms which items the target can import directly and which need conversion. Plan on manual rebuilding for anything that depends on Open WebUI-specific features such as custom models, tools or permissions per resource, since these are not documented as portable. The step is complete when a sample of exported conversations has been opened in a test environment and each user has a written list of settings to recreate.
Map identities and rebuild roles
Using the inventory from the first step, the identity owner maps each Open WebUI group and role to the equivalent access model in LobeHub, then sets up the same groups in the identity provider that Better Auth will use. Administrators should confirm which permissions do not have a direct equivalent in the target and decide how to handle them before users arrive. The step is complete when a signed mapping table shows each source group, its target role and the named approver for every exception.
Rebuild knowledge and vector stores in the target
Knowledge collections are re-ingested into the target from their original source files rather than copied out of Open WebUI's vector database, because the vector store and its embeddings are tied to the chosen retrieval configuration. The team rebuilds each collection in PostgreSQL with pgvector, then checks that search returns the expected passages for a fixed set of test questions. The step is complete when every collection in the inventory has a retrieval test result and an owner has signed off on it.
Pilot the target with one group
A single business group uses the LobeHub instance for normal work for a defined trial period agreed in advance, while Open WebUI stays available for everyone else. The pilot tests sign-in, chat history, model responses, knowledge retrieval and the support process for problems that arise. The step is complete when the pilot group's issues are logged, resolved or accepted as known limitations, and the owners have approved the cut over in writing.
Cut over and retire the old instance
The team announces a cut over date, moves the remaining users, makes a final backup of Open WebUI, and switches access so new work happens only in LobeHub. The old instance is kept in read-only form for a retention period set by the organization's own records policy, then removed under change control. The step is complete when the access logs show no new Open WebUI sessions, the final backup has been verified and the decommissioning record is filed.
Where implementation projects usually run long
The longest delays in an Open WebUI or LobeHub rollout rarely come from installing the container. They come from the decisions and integrations around it, and the first one to check is licensing. Open WebUI's branding clause applies to deployments above 50 users in any rolling 30-day period, and LobeHub's Community License limits derivative works and distribution, so a rebranding or fork decision made late can reopen the scope. Get written sign-off on branding, user counts and whether you will modify the source before the statement of work is final. Ask DeployOpen and your counsel to confirm how each clause maps to your planned user base, rather than assuming the open-source label settles it.
Identity work is the second common slip. On Open WebUI, the team has to map OIDC or LDAP claims to groups, decide whether SCIM 2.0 provisioning will drive group membership, and test role-based access control against per-resource permissions. On LobeHub, the Better Auth configuration for a generic OpenID Connect provider needs the same group and role decisions, and it is easy to discover late that group claims do not arrive in the form the team expected. Plan a test tenant with real group memberships and sign off each role before you connect the production identity provider.
Multi-replica setups add a third set of slips. Open WebUI requires PostgreSQL, Redis for sessions and WebSocket state, and shared file storage so uploads and knowledge stay reachable from every replica. LobeHub's Docker guide depends on PostgreSQL 17 with the pgvector and pg_search extensions, set through DATABASE_URL. Confirm which managed or self-run services you will provision, who holds the database and Redis credentials, and how model provider keys are stored and rotated. Then load test the replicas with realistic concurrency before go-live, because file storage and session issues often appear only under load.
Questions buyers ask before choosing or hiring help
Does a company with more than 50 users need a paid Open WebUI license?
Not automatically. The branding clause in the Open WebUI License applies only when a deployment exceeds 50 end users in any rolling 30-day period and you want to alter or remove Open WebUI branding. Below that threshold, or if you keep the branding intact, the clause does not require a paid license. Above it, you need an enterprise license or written permission from the copyright holder to change branding. Enterprise licenses add white-labeling and dedicated support options. Pricing is not published, so ask enterprise sales for a quote based on your expected seat count, and confirm in writing how seats are counted. Code through v0.6.5 remains BSD-3-Clause, but a fork built on it would move maintenance to your team. Have your legal team read the Open WebUI License documentation against your branding plans.
What does the LobeHub license forbid for internal customization?
It does not prohibit running the software internally, but it limits what you can do with modified code. The LobeHub Community License, based on Apache License 2.0, allows commercial use as a frontend and backend service without modifying the source. Developing and distributing derivative works requires a commercial license. For an internal team, the open question is whether patches, custom plugins or themes count as derivative works when you never distribute them, and whether that changes if you share them with a subsidiary or contractor. Also note that contributors agree the producer can make the license stricter or looser, so terms can change. Get LobeHub's position in writing before you plan customization, and reread the LobeHub license at each upgrade.
Does LobeHub support SCIM user provisioning?
The material available to us does not confirm SCIM support, so treat it as unverified until LobeHub confirms it. What is documented is sign-in: Better Auth with email and password, magic links, OAuth, SSO providers such as Google, GitHub and Microsoft, and any generic OpenID Connect or OAuth 2.0 provider. Sign-in alone does not show automated creation, group updates and deprovisioning from your identity provider. Open WebUI documents SCIM 2.0 user and group provisioning, OIDC, LDAP and role-based access control with groups. Ask LobeHub whether SCIM, group mapping and session revocation exist, then test offboarding: a disabled identity should lose access to the app and its active sessions. Start with the LobeHub authentication docs.
How much work do PostgreSQL and Redis add to each deployment?
For LobeHub, PostgreSQL is part of the baseline. Its Docker guide uses PostgreSQL 17 with the pgvector and pg_search extensions, connected through a DATABASE_URL setting. For Open WebUI, a single instance can run without PostgreSQL, but its scaling guide requires PostgreSQL for multi-instance deployments and Redis for sessions, websocket connections and shared application state across replicas. Shared file storage is also needed so uploads and knowledge stay reachable from every replica. The recurring work includes database backups and restore tests, extension and version upgrades, failover design, Redis availability and storage monitoring. The one-time work covers architecture, network placement and runbooks. Ask LobeHub to confirm its Redis requirement for multi-replica operation before you size the stack.
Can an internal team run either platform without outside help?
Often yes for a single instance with a small user group and few integrations, but the answer depends on skills your team already has. The work includes container operations, PostgreSQL administration, identity configuration, TLS, backups, monitoring and upgrade testing. Open WebUI offers Docker, Docker Compose, Kubernetes with Helm and pip installs, and scaling adds components you must run. LobeHub deploys with its Docker image and Compose file or the platform options in its README. The main effort drivers are user count, SSO complexity, number of model providers, knowledge base size, replica count and customization. Ask each vendor for its upgrade notes and release cadence, and decide who answers security questionnaires and on-call pages before you commit.
What does outside help from DeployOpen cover for this decision?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For this decision, that can include identity integration, database and Redis design, backup and restore testing, deployment runbooks and documentation for your security team. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. License interpretation stays with your legal team and the vendor.
How does switching between Open WebUI and LobeHub affect users later?
A switch touches accounts, chat history, knowledge bases, model provider settings, SSO configuration, prompts and user habits. The material available to us does not document an export or import path between the two products, so confirm the export formats for each, whether user identifiers can be mapped, and how knowledge files and embeddings move. A common approach is a pilot with one group, a parallel run for an agreed period, then a cutover with a short write freeze. Costs include data migration work, SSO retesting, rebuilding provider keys, retraining users and re-approving the new deployment with your security team. Include future license changes in the switching risk, because the terms of either license can change.
How DeployOpen helps you choose and implement a private chat platform
DeployOpen is a Chainscore Labs company. We plan, implement, harden, back up and document self-hosted open-source platforms inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network. For a chat platform like Open WebUI or LobeHub, that work covers the parts this comparison leaves open: the PostgreSQL database and its backups, the Redis and shared file storage a multi-replica deployment needs, the identity provider wiring for SSO and SCIM, the model provider credentials, and the hardening and documentation your security team will ask for. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts, and we quote from that written scope. We do not publish a price list, and we do not estimate our fees here.
We do not favor either platform. Our role is to help you test the decision against your own requirements, such as whether your deployment will exceed 50 end users in a rolling 30-day period, whether you need to change branding, which identity protocols your directory supports, and whether your team is ready to operate a LobeHub stack built around PostgreSQL 17 with pgvector and pg_search. We can document what each option requires in your environment and what the trade-offs look like for your staff. The licensing questions in this comparison, including the Open WebUI License and the LobeHub Community License, should be reviewed with your legal counsel before you commit. DeployOpen does not issue audit reports, attestations or certifications. Where a compliance assessment is needed, the independent auditor or certification body performs it, and we help prepare the systems, controls and evidence they will review.
