Open WebUI customization services

What Open WebUI customization covers

Customization in Open WebUI means shaping how the interface behaves for your organization after the platform is installed. In practice that covers model presets that pin a base model with a system prompt and settings for a given team, tools and functions that extend what a model can do, retrieval settings for the knowledge base, group-based permissions that decide who sees which models and resources, and branding. Each of these is a configuration surface that changes behavior for real users, so each deserves a deliberate owner and a review step.

Most changes start from one of four triggers: a department rollout that needs its own presets and knowledge collections, a model approval policy that limits which providers and models users can reach, a branding requirement for an externally visible deployment, or a new internal system the assistant must call through a tool. Administrators can make many of the first two in-house through the admin settings. Custom code, permission design across several groups, and branding changes are the areas where organizations most often scope a partner, because they touch security boundaries and licensing.

Branding deserves an early decision. Under the Open WebUI License, altering or removing branding in deployments above 50 users in a rolling 30-day period requires an enterprise license or written contributor permission. Confirm your expected user count and the branding you need before the interface is configured, because that determines whether the work is in scope at all. Enterprise pricing is not published and is quoted after contacting Open WebUI's sales team with an expected seat count.

Before you start, list the presets, tools, retrieval collections and groups you expect in the first year, and name an owner for each. Test tools and functions in a non-production instance, since they can run code or call internal systems. The scope boundaries covered on this page do not include installation, SSO setup, high availability or cost of ownership, which are covered on their own pages.

What the work includes

Every deliverable below is listed in the written scope before work starts, so you can check what you receive against what was agreed. The items cover configuration, build, access, branding and operations.

Configuration baseline with model presets

A documented baseline of model presets, system prompts and provider visibility, showing which users can see Ollama, OpenAI, Anthropic or OpenAI-compatible connections. Check that provider keys stay in administrator settings and that each preset names the model, its intended group and its owner.

Tools and functions built and reviewed

Custom tools and functions written and tested in a non-production environment, then reviewed before promotion. Review covers what each one can call, which secrets it reads and who may enable it, since tools and functions execute code with the permissions of the server they run on.

Retrieval settings per knowledge collection

Retrieval parameters set for each knowledge collection, including the vector database, hybrid search and reranking choices where they apply. Confirm the settings against sample questions from each collection, because the right chunking and reranking depend on the documents, not on a single default.

Group and permission matrix

A matrix that maps Open WebUI groups to models, knowledge collections, tools, and administrative roles. Each row should name who approves changes, so access decisions can be traced when a user moves teams or leaves the organization.

Branding decision and implementation path

A written decision on whether branding stays as shipped or changes, with the implementation path for each option. Changing branding in a deployment above 50 users in a rolling 30-day period requires an enterprise license or written contributor permission under the Open WebUI License, so confirm this before design work begins.

Runbook and handover session

A runbook covering how administrators add models, manage groups, promote tools and rotate keys, plus a handover session where your operators run those tasks themselves. The runbook records which settings change through the admin interface and which require a configuration or database change.

What drives customization effort

This table lists the factors that change how much customization work an Open WebUI deployment needs, why each one matters, and how to keep it contained.

Driver	Why it changes the effort	How to keep it down
Groups and roles	Each group needs its own permissions, model access and knowledge visibility, and each mapping must be tested for every role combination.	Start from a small set of roles, map groups from your identity provider only where access truly differs, and document the intent of each group.
Custom tools and functions	Each tool is code that runs inside the platform, so it needs design, review, testing and maintenance across every upgrade.	Reuse a tested tool template for common patterns and limit the first release to tools with a confirmed business owner.
External systems called by tools	Every external system adds credentials, network paths, error handling and a separate test environment to validate.	Phase integrations, start with read-only calls, and confirm early which systems have test instances available.
Model providers	Each provider needs its own connection, key handling, model list, rate-limit behavior and usage rules for users.	Connect only the providers your approved use cases need and hide keys from end users through administrator-managed connections.
Knowledge collections	Document volume, file types, extraction quality and access rules determine indexing time, retrieval tuning and review effort.	Scope collections to a clear purpose, load a representative sample first and set per-collection permissions from the start.
Branding scope and user count	Altering or removing branding in deployments above 50 users in any rolling 30-day period requires an enterprise license or written contributor permission under the Open WebUI License.	Confirm the user count with counsel or licensing before design, and limit branding changes to what the license terms allow if no enterprise license is held.
Environments and release process	Each environment needs its own configuration, data handling and promotion steps, and each Open WebUI release requires a regression pass.	Keep the number of environments to what your change process needs and use the same configuration files across them.
Compliance review requirements	Assessors may ask for evidence of access control, change records, tool review and data handling, which adds documentation and testing work.	Agree the evidence list before build, and ask whether your reviewers accept configuration exports and change tickets as evidence.
Enterprise license requirement	Enterprise terms add white-labeling and dedicated support, and pricing is quoted after contacting Open WebUI enterprise sales with an expected seat count.	Decide early whether branding or support needs justify the license, and request a quote using your expected seat count.

How the project runs

The work moves from understanding how people will use Open WebUI to a tested, handed-over configuration that your team can operate.

Inventory use cases and user groups
DeployOpen interviews your sponsors and group leads to list the tasks people will do in Open WebUI, the model providers each task needs and the data each group may touch. The output is a use-case inventory signed off by your project owner, which sets the scope for every later phase.
Design the permission matrix and presets
Using the inventory, DeployOpen drafts a permission matrix that maps groups to roles, model access, tool and function rights, knowledge base visibility and API key use. Model presets and default settings are written alongside it. The step closes when your security and business owners approve the matrix in writing.
Build tools and functions in a non-production instance
Custom tools, functions and model presets are built and reviewed in a separate non-production Open WebUI instance that mirrors your intended configuration. Each item is checked against its documented purpose, its access rules and the data it can reach. The step closes with a review record for each tool and function and a promotion checklist.
Tune retrieval on representative documents
DeployOpen loads a representative sample of your documents into the knowledge setup and tests retrieval settings such as chunking, embedding, hybrid search and reranking against questions your users actually ask. Results are recorded with the settings used, so your team can repeat the tests after changes. The step closes when agreed questions return answers your reviewers accept.
Decide branding and license terms
Your team and DeployOpen confirm the license position for the expected user count, which determines whether the Open WebUI branding clause applies. If branding changes are planned, the enterprise license route is raised with Open WebUI's sales team, and the final decision is recorded before any visual work starts. The step closes with a written license and branding decision.
Test with named accounts per group
Named test accounts are created for each group in the permission matrix, and each account runs the agreed scenarios, including attempts to reach resources outside its role. Failures are logged, fixed in the non-production instance and retested. The step closes with a test report listing each scenario, its result and the owner who accepted it.
Release and hand over
The approved configuration is promoted to production, the permission matrix and presets are verified against the live instance, and your operators receive runbooks for changing groups, presets, tools and retrieval settings. Handover ends with a walkthrough and a signed acceptance record. Timelines for each phase are set in the written scope.

What teams keep in-house and what they outsource

This table compares the Open WebUI customization work teams usually run themselves with the work they often hand to a partner, and lists the skills each part needs so you can match tasks to people.

Work item	Usually in-house	Often outsourced	Skills required
Model presets and model visibility	Yes. Admins change which models appear and how presets are named as needs shift.	No. Rarely outsourced unless the model catalog is being redesigned.	Open WebUI administration, basic knowledge of the approved model list
Day-to-day group membership	Yes. Team leads or IT staff add and remove people as roles change.	No. Only outsourced when group membership is tied to identity automation.	Open WebUI administration, identity administration
Knowledge base uploads and updates	Yes. Content owners upload documents and retire outdated files.	Partly. Outsourced when the document structure itself needs redesign.	Information architecture for knowledge bases, document ownership practices
Prompt libraries	Yes. Subject matter teams write and maintain shared prompts.	No. Usually written in-house because they reflect local terminology and policy.	Domain writing, Open WebUI administration
Custom Python tools and functions	No. Usually built by engineers, then reviewed before release.	Yes. Often outsourced because they run server-side code and call internal systems.	Python, Open WebUI internals, API integration, secure coding
Permission design across many groups	No. Hard to get right without a model of who needs which resource.	Yes. Often outsourced because mistakes expose knowledge bases or models to the wrong users.	Identity administration, role-based access control design, information architecture
Retrieval tuning	No. Depends on chunking, embedding, hybrid search and reranking choices.	Yes. Often outsourced because results must be measured against real documents and questions.	Retrieval engineering, vector database administration, evaluation design
Branding implementation	No. Requires a decision on the enterprise license before changes are made.	Yes. Often outsourced when white-labeling must be applied consistently across deployments.	Brand design, frontend customization, licensing review
Code review of customizations	No. Peer review inside the team is the usual first step.	Yes. Outsourced when an independent reviewer is needed before tools reach production.	Python, application security review, Open WebUI internals

What usually goes wrong

Most Open WebUI customization problems are not technical surprises. They come from decisions made quickly, changes nobody reviewed, and knowledge that lives in one place. Each card below names a pattern and the step that prevents it.

Unreviewed tools and functions

Functions and tools run with server-side access, so a poorly reviewed one can read data, call internal services or change responses for every user. Before enabling any tool or function, require a named reviewer, a code review of its source, a list of the network hosts and secrets it can reach, and a test run on a non-production instance.

Permission drift as groups grow

Groups and per-resource permissions set for a pilot of a few people often remain unchanged as teams join, leave and share knowledge bases. Schedule a recurring review of group membership and model or knowledge access, and use SCIM 2.0 provisioning where your identity provider supports it so membership changes flow from the source system.

Branding changed without a license

The Open WebUI License prohibits altering or removing branding in deployments above 50 users in any rolling 30-day period unless the operator holds an enterprise license or written contributor permission. Count active users against that threshold before any logo, name or interface change, and confirm the license position with Open WebUI enterprise sales before the change goes live.

Retrieval tuned on unrepresentative documents

Chunking, embedding and reranking settings tested on a handful of clean PDFs often perform poorly on scanned files, long spreadsheets or the documents people actually ask about. Build a test set from real knowledge base content and questions, record which answers are correct, and re-run it after every change to extraction, chunking or vector database settings.

Customizations broken by new releases

Custom templates, CSS overrides and functions that depend on internal behavior can stop working when a new release changes that behavior. Keep a written inventory of every customization with its version, test it against each candidate release on staging, and read the release notes on the GitHub releases page before upgrading.

Configuration held only in the admin interface

Model presets, prompt templates, tool settings and permissions that exist only in the admin interface cannot be reviewed, restored or reproduced on a second instance. Export what the platform allows, store the export in version control, back up the database alongside it, and record every manual change in a change log.

Dependence on one developer

When one person wrote the functions, tuned the retrieval settings and holds the only admin credentials, a leave or departure stalls every change and every incident. Assign a second maintainer, store credentials in an approved secrets manager, and document each customization with its purpose, owner and rollback steps.

How the work changes by starting point

A single host or a small Compose stack is the simplest starting point, and most of the work happens in configuration choices made before users arrive. Confirm the database and storage layout first, because the scaling guidance on SQLite depends on it.

Testing: Test sign-in, model connections and a knowledge upload on the same host you plan to keep, so results carry over to production.
Branding: Branding changes are simple to make at this stage, but they fall under the license's branding clause once the deployment passes 50 users in a rolling 30-day period.
Tools: Keep tool and function code in version control and review it before enabling it for any group.
Storage: If you keep SQLite, place the database file on locally attached SSD or NVMe storage, not on network storage.

What you need to provide

The customization work depends on inputs that only your organization can supply. Before we start, you need a named business owner for each group that will use Open WebUI, along with the model providers and models that are approved for use. Each owner should be able to say which models their users may select, which prompts reflect real work, and who signs off on changes to model presets. Without those names, presets and permissions tend to be configured by guesswork and then reopened after launch.

For tools and functions, provide API documentation and test credentials for every system a tool will call, plus a non-production environment where those calls can run safely. Identity group names should match the groups you plan to map to Open WebUI roles and per-resource permissions, so the access model can be tested against the directory you already run. Also decide who approves new tools and functions before any are built, since each one runs code or calls internal systems on behalf of users.

Retrieval testing needs representative documents, ideally a small set that includes the formats, languages and sensitivity levels your knowledge bases will contain. Supply them with the owner who can confirm which content may be indexed and which groups should see each collection. Expect to rerun retrieval tests after document sets change.

Branding needs a decision from you early. Provide your brand assets and state your organization's position on the branding clause in the Open WebUI License. The clause applies once a deployment exceeds 50 users in any rolling 30-day period, so supply your current rolling 30-day user count and confirm whether you hold an enterprise license or will keep Open WebUI branding unchanged. Confirm both figures with your licensing contact before design work begins.

Frequently asked questions

What drives the cost of Open WebUI customization and how is the quote built?

Cost follows the written scope: the number of model presets, tools and functions, group and permission rules, retrieval settings, and any branding work. Each item is priced by the effort to design, build, test and document it, plus the complexity of the environment it runs in. Ask the quote to separate one-time work (design, build, validation and handover) from recurring items (upgrades, support and testing retainers). Enterprise license fees, if they apply, are quoted by Open WebUI's enterprise sales team from an expected seat count, so ask which lines depend on that quote.

How long does an Open WebUI customization project take to complete?

No duration is fixed until the scope is agreed in writing, because most engagements are fixed-scope with deliverables and timelines set before work starts. The main timeline drivers are how many customizations you need, whether tools or functions must be written and reviewed, how many identity groups map to permissions, and how quickly your team answers design decisions and tests in staging. Approvals from security, branding sign-off and change windows for production cutover often set the critical path. Ask for a schedule with named milestones and the dependencies your team must clear.

What does our team need to provide for an Open WebUI customization engagement?

Expect to provide a named business owner who signs off on presets, groups and permissions, plus an administrator who can grant access to the running instance, the identity provider and any systems that tools call. You also need a staging environment close enough to production to test, access to your model provider accounts or approved endpoints, and written rules for who may use each preset or tool. Security or compliance reviewers should be available before release. Confirm these items in the scope so access requests do not stall the build.

Can our administrators create model presets and set permissions themselves?

Yes for most day-to-day settings, once the design is agreed and administrators hold the right role. Open WebUI's role-based access control supports groups and per-resource permissions, so administrators can typically manage presets, user groups and access to models and knowledge within those controls. Custom tools and functions usually need developer work and review before administrators can deploy them. During scoping, confirm which settings your administrators will own, and ask for a handover session and a written runbook so later changes stay consistent with the design.

When does branding Open WebUI require an enterprise license?

Open WebUI's license forbids altering or removing its branding in deployments that exceed 50 users in any rolling 30-day period, unless the operator holds an enterprise license or written contributor permission. Enterprise licenses allow white-labeling and custom branding, along with dedicated support options. Read the Open WebUI license documentation for the exact terms, then contact Open WebUI enterprise sales with your expected seat count, since pricing is not published. Check the rolling 30-day window against your actual user counts before assuming a pilot is exempt.

How are Open WebUI customizations handled when you upgrade to a new release?

Customizations are tested against each new release in staging before production, and any that touch internal code paths, database schema or interface behavior are reviewed first. Presets and permissions stored in the application often carry forward, but you must verify this in your environment. Tools and functions depend on the APIs of a given release, so each one needs a regression check. Keep configuration under version control where possible, and agree in scope who owns upgrade testing, rollback and the release calendar. Review the release notes for each version you plan to adopt.

Do custom Open WebUI tools and functions need a security review before release?

Yes, we recommend a security review before any custom tool or function reaches users, because these components run code and can call internal systems with the permissions they are given. The review should cover input handling, secrets storage, outbound network calls, which groups can invoke each tool, and logging. DeployOpen's security testing covers applications, APIs and AI integrations, while independent auditors issue any audit report or certification. Ask the quote to include the review gate, the test evidence you will receive and who signs off on release.

How DeployOpen delivers Open WebUI customization

DeployOpen scopes, configures and documents Open WebUI customization inside your own infrastructure, from model presets and tools to group permissions and retrieval settings. Engagements are fixed-scope, with the written scope, deliverables and timeline agreed before work starts.

How we scope

The written scope lists which model presets, tools, functions, retrieval settings and group permissions are included.
We confirm which model providers (Ollama, OpenAI, Anthropic or OpenAI-compatible services) each user group may reach.
We confirm whether branding changes are in scope and whether your deployment needs an enterprise license under the Open WebUI License.

How we build

We configure model presets and provider connections so users see only the models your organization has approved.
We build and review tools and functions against your data sources, testing them in a non-production instance first.
We set retrieval options such as vector database, hybrid search and reranking, then check results against representative documents.

How we hand over

We document each preset, tool, function, group permission and retrieval setting with its owner and reason for existing.
We provide a test plan that your team can rerun after each change, covering permissions and model access by group.
We walk your administrators through the change process so future customizations follow the same review steps.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial work.
Changes to customizations are re-tested against each new Open WebUI release before they reach production users.
Ask any provider to confirm in writing which post-go-live tasks are covered by the retainer and which are billed separately.

Open WebUI customization