Open WebUI security hardening guide

Open WebUI security hardening starts before the first user signs in

Hardening a self-hosted Open WebUI is a set of configuration decisions plus a few infrastructure requirements, and the defaults do not stop a determined insider or a misconfigured network path. A team that has connected staff to local or remote models now needs to decide who can create accounts, how long sessions live, what API keys can reach, and where the service can be reached from. This page covers those platform settings and their operational consequences. Single sign-on, high availability, customization and upgrades each have their own page, so they are referenced here only where a hardening choice depends on them.

The work is harder than it looks because several controls depend on each other. Signing out does not revoke tokens unless Redis is configured as the shared state store. Without it, a token stays valid until it expires, and by default that is 4 weeks, according to the Open WebUI scaling guide. A user who signs out on a shared workstation may still hold a working session. Treat Redis as a security dependency, not a performance add-on, and test revocation directly: sign in, sign out, then replay the old token against the API and confirm it is rejected.

API keys and tools also widen what a user can reach. An API key lets a person or script call Open WebUI outside the browser, so it inherits whatever that account can see. Tools and functions can call external systems on the user's behalf. Before enabling either for a regulated group, decide which roles may create keys, whether keys expire, and who reviews the tools and functions that are installed. Confirm in your own environment which key settings are exposed to administrators, since the exact options depend on the release you run.

Per-resource permissions only protect what was actually assigned. Models, knowledge collections and other shared resources are visible according to their access grants, so a collection shared with a broad group before review becomes a data exposure. Build a short inventory of models, knowledge bases and prompts, record who owns each one, and check the grants against your data classification. Role-based access control with groups is the mechanism to rely on, and the check should be repeated after every onboarding wave.

Network exposure is the last layer. Decide which networks can reach the web interface and API, terminate TLS in front of the service, and keep the database and any vector store off public addresses. Ask your team to confirm how the deployment method you chose handles these settings, and record the answers before the first user signs in. A short written baseline covering sign-up, session lifetime, Redis, keys, tools, grants and network paths gives reviewers something to test against.

Which Open WebUI settings and extension points carry security weight

A hardening review of a self-hosted Open WebUI touches a small set of places where a default or a loose setting changes who can reach the interface, what they can do once inside, and which upstream credentials they can use. The cards below cover each of these areas and what to confirm in your own version before changing anything.

Sign-up and account creation

This controls whether a person who reaches the login page can create an account without an administrator approving it. Open WebUI's sign-up behavior and the default role assigned to new accounts determine who gets access the moment the URL is reachable. Check that open sign-up is disabled for production, that new accounts receive the least-privileged role, and that accounts come from your identity provider or an approved invitation process. Confirm the exact setting names and locations in the admin settings for your version.

Sessions and token lifetime

Sessions and bearer tokens decide how long a stolen or forgotten login stays usable. Without Redis, signing out does not revoke tokens, which remain valid until they expire, by default after 4 weeks. For multi-replica or security-sensitive deployments, confirm that Redis is configured as the shared session store so sign-out and revocation take effect across every instance. Also review the configured token expiry and test that a sign-out actually invalidates an existing token.

API keys and their scope

API keys let scripts and integrations call Open WebUI without an interactive login, so they often outlive the person who created them. Review who may create keys, whether that capability is enabled for all roles, and how keys are rotated and revoked when an owner leaves. Check whether keys can be limited in scope and whether key use is logged. Confirm the feature names and availability in the features documentation for your release before writing policy around them.

Groups and per-resource permissions

Role-based access uses groups and per-resource permissions to decide who can use models, knowledge collections, tools and prompts. Permissive defaults can expose a model or knowledge base to every signed-in user. Map groups to business roles, remove broad grants on sensitive resources, and test access with a non-administrator account. Groups provisioned from an identity provider through SCIM 2.0 should be reviewed as well, since a group change upstream can widen access silently.

Network path to the interface

The network path determines who can reach the login page, the API and the websocket endpoints at all. Decide which networks and users may connect, terminate TLS at a controlled proxy or load balancer, and keep the container or service off public addresses unless it is intended to be exposed. Check that administrative paths are not reachable from general user networks and that forwarded client headers are handled by a trusted proxy only. Confirm the required proxy settings for your deployment method.

Provider connections that hold upstream keys

Connections to Ollama, OpenAI, Anthropic or other OpenAI-compatible providers store credentials that grant spend and data access at the provider. If a standard user can view or extract these keys, a single account can misuse the organization's provider account. Restrict provider configuration to administrators, use dedicated keys with spending limits where the provider supports them, and confirm that keys are not returned in API responses or user-visible settings. Verify the exact behavior in your version.

Tools and functions that run code

Tools and functions extend Open WebUI with code that runs on the server or calls external systems, so they carry the highest risk in the product. Limit who may install or edit them, review every imported function before enabling it, and assign access only to the groups that need it. Treat third-party code as untrusted until it has been read and tested, and keep an inventory of what is installed and who approved it. Confirm the permission settings and sandboxing behavior in the features documentation for your release.

Which hardening options fit your risk and what each one costs to run

This table compares the main Open WebUI hardening choices, when each one fits and what it asks your team to run and maintain. Read each row against your user population, your need for immediate session revocation and the number of replicas you plan to run. The main takeaway is that Redis, PostgreSQL and a private access path add services to operate, so each security gain also carries a recurring running cost.

Decision	When it fits	What it costs to run
Closed sign-up with invitations or SSO onboarding	Internal or regulated deployments where access must follow an approved user list.	Admins manage invitations or identity-provider group sync. Ongoing effort to onboard and offboard users.
Redis for token revocation	Deployments where sign-out must end access at once, or where several replicas share sessions.	A Redis service to run, patch, back up and monitor. The scaling guide requires it for multiple replicas.
PostgreSQL as the database	Multi-instance deployments and any production service with concurrent writes.	A database to size, back up and restore-test. Recurring administration time and storage growth.
SQLite on locally attached SSD or NVMe	Single-replica, evaluation or small-team use where the database file stays on local disk.	Lowest footprint, but backups and disk failure fall to the host. Not suitable on network storage.
API keys restricted to a named group	Teams running scripts or integrations that need programmatic access to the platform.	Group membership reviews, key rotation and revocation steps. Each key is a standing credential to log.
Tools and functions admin-installed only	Most regulated deployments, where extensions pass review before any user can run them.	Admin review, testing and re-review at each upgrade. Slower delivery of new capabilities to users.
Tools and functions open to users	Teams where users build their own extensions and the organization accepts the code risk.	Review burden moves to users who may not be equipped for it. Unvetted code can reach providers and internal systems.
Public exposure behind a reverse proxy	Users outside the corporate network who need access without a VPN client.	TLS management, proxy hardening, rate limits and monitoring of an internet-facing service.
Private network path with VPN or zero-trust access	Internal assistants handling sensitive data that should not be reachable from the internet.	VPN or zero-trust licensing and access policy upkeep. Support for remote staff connectivity.

How to harden an Open WebUI deployment in the right order

This sequence starts with the controls that stop unauthorized access, then adds the shared state, permissions and exposure controls a multi-user deployment needs. Each step names the check that closes it, so the team can record evidence as the work progresses. It is written for the administrators and platform engineers who will run the service.

Pin and record the running version
Confirm which Open WebUI release is running in each environment and record the exact version in your change log. Check that the version is a current release on the project's GitHub releases page before you continue, since the later hardening steps assume a supported build. The platform owner signs off on the recorded version. Done when the version string, install date and image digest are in the runbook and match the running container.
Disable open sign-up and attach identity
An administrator turns off open self-registration in the admin settings, then connects the identity provider through OIDC or LDAP and enforces MFA before users reach the service. The SSO and identity topic covers the connection and group mapping in detail. Test by opening a private browser session as a new visitor and confirming that no account can be created and that sign-in redirects to your identity provider. Done when the test visitor is refused.
Add Redis and confirm sign-out revokes tokens
Add Redis as the shared state store for sessions and websocket connections. Without Redis, signing out does not revoke tokens, which remain valid until they expire, by default after 4 weeks. Sign in, copy the session token, sign out, then replay that token against an API call. The platform engineer configures Redis and the security engineer runs the test. Done when the replayed request is refused, and repeat the test on each replica if you run several.
Move to PostgreSQL before running several instances
Move from SQLite to PostgreSQL before any second instance runs. The scaling guide requires PostgreSQL for multi-instance deployments because SQLite does not handle concurrent writes from several processes well. SQLite remains acceptable for a single replica only on locally attached SSD or NVMe storage. The same guide warns that the default ChromaDB crashes in multi-process setups, so confirm an external vector database is in place. Done when writes made through one replica are visible from the others.
Build group permissions and scope API keys
Create named groups that match your access model, assign users to groups, and set per-resource permissions on models, knowledge bases and tools. Allow API key creation only for a named group, then confirm which users hold keys. Test denial by signing in as a user outside the group, attempting to create a key, and attempting to read a restricted model or knowledge base. Done when both requests are refused and the denial results are recorded in the runbook.
Restrict tools and functions to administrators
Limit tool and function installation to administrators, because these artifacts run code on the server. Before enabling any new tool or function, a reviewer reads the full code, checks any outbound network calls, file access and credentials it requests, and records the approval. Confirm that a non-administrator account cannot install or import one. Done when every enabled artifact has a review record and the non-administrator install attempt fails.
Place the service behind TLS and a controlled path
Terminate TLS at a reverse proxy or load balancer your team manages, and route all user traffic through that path. Keep the application port off public networks. From outside the network, run a port scan you are authorized to perform and confirm that only the intended ports answer, typically the HTTPS port on the proxy. Done when the application port does not respond directly and the certificate chain validates from a clean client.
Store provider keys server-side with restricted access
Keep credentials for Ollama, OpenAI, Anthropic or OpenAI-compatible services in server-side configuration, and keep them out of user-level settings. Limit which administrators can view or edit these values, and rotate keys through your existing secrets process. Confirm that a standard user cannot read a provider key through the interface or an API response, and that keys do not appear in logs or exported configuration. Done when all three checks pass and the admin access list is recorded.

Why sign-out only means something once Redis is in place

Without Redis, signing out of Open WebUI does not revoke the tokens that were issued to the session. Those tokens remain valid until they expire, and the Scaling Open WebUI guide states that the default lifetime is 4 weeks. For a security team, this means a sign-out button can leave a working credential in circulation for up to a month. The gap matters most when a laptop is lost, a shared workstation is left unlocked, or an employee leaves and their browser session is the only thing that was closed.

Test this before you rely on it. Use a non-production instance on a single replica. Sign in as a test user, copy the bearer token from a captured API request or browser session, then sign out through the interface. Replay the captured token against an authenticated endpoint. Without Redis configured, expect the request to still succeed. Record the result, the Open WebUI version and the exact configuration, because this is the evidence your reviewers will ask for later.

After Redis is configured as the shared state store and the instance is restarted with that configuration, repeat the same test. The captured token should be rejected once the user has signed out. Confirm this with a fresh sign-in as well, so you know the new behavior comes from the revocation path and not from an unrelated failure. Check the Redis connection settings in the deployment's environment variables and in the container logs, because a silent fallback to local state would reproduce the gap without any visible error.

Redis is also required for session state once you run several replicas, as the scaling guide explains. The revocation requirement is separate from that decision. A single instance that allows captured tokens to outlive sign-out has the same exposure as a cluster. Do not defer Redis until you plan a scale-out. Add it to the first hardened build and treat it as a baseline control.

Shortening the token lifetime is a second lever, but only change it after you have confirmed the setting name, its default and its effect in the exact version you run. Check the release notes for your version and test the change in staging. A shorter lifetime reduces the window for a stolen token, but users will re-authenticate more often, which affects people working in long sessions and any integrations that depend on a long-lived token. Agree on the trade-off with the business owners before you change it. High availability design for multiple replicas is covered in the Open WebUI high availability topic.

What makes Open WebUI hardening take longer or cost more

This table lists the factors that most change how much work Open WebUI hardening takes, who carries each item, and what keeps it contained. Read each row against your own environment before asking for a quote, because the same control can be quick in one estate and slow in another. The main takeaway is that identity maturity, the number of provider keys and the evidence your assessors expect usually decide scope more than the software itself.

Driver	What raises effort	How to keep it down	Who usually pays
Users and groups for per-resource permissions	Many users with overlapping access needs, no agreed group model, and models, knowledge bases or tools shared case by case	Define a small set of groups by role before configuration, then grant per-resource permissions to groups rather than individuals	Internal staff decide the access model; a partner under a fixed-scope agreement configures and tests it
Number of model providers and keys to move server-side	Each provider adds a credential that users or admin panels may currently hold, plus separate rotation and testing	Inventory every provider and key first, move them to server-side configuration in one pass, and limit which models each group sees	Both: internal staff own key rotation and vendor accounts; a partner handles the server-side move and verification
Identity provider complexity and MFA status	Multiple directories, LDAP plus OIDC, group claims that need mapping, or no MFA enforcement in place yet	Confirm which identity provider is authoritative, agree group claim names early, and enforce MFA at the identity provider where possible	Internal identity team usually pays for IdP changes; a partner integrates and tests Open WebUI's side
Custom tools and functions	Locally written code that runs with server privileges, unclear owners, and no review history before it is enabled for users	Freeze an approved list, require a code review record for each item, and restrict who can create or import new ones	Internal developers and security reviewers pay for review; a partner can perform a one-time audit of the existing set
Number of environments that must match	Separate development, staging and production configurations that drift apart, with secrets and settings copied by hand	Keep one configuration template under version control and promote the same settings through each environment	Mostly internal platform staff for ongoing parity; a partner may set up the template as part of the fixed scope
Network path and private access	Reverse proxies, load balancers, TLS termination, VPN or private access requirements, and exposed admin endpoints	Document the request path end to end, close direct access to the application port, and test sign-out and session behavior through the proxy	Both: internal network teams own firewall and DNS changes; a partner validates the exposure and configuration
Evidence requirements from internal audit or external assessors	Requests for specific logs, configuration exports, access reviews or change records in a particular format, often discovered late	Agree the evidence list before hardening starts, map each item to the control it supports, and collect it during the work	Internal compliance and audit teams set requirements; a partner prepares the evidence. Assessors and certification bodies, not DeployOpen, issue any audit opinion
Token revocation and session handling	Multiple replicas or a single container without Redis, where sign-out does not revoke tokens and they remain valid by default for 4 weeks (Open WebUI scaling guide)	Decide on the shared state store and session lifetime early, then test revocation across every instance	Internal platform staff run Redis; a partner configures Open WebUI and verifies revocation

How hardening changes across single-node, multi-replica, Kubernetes and private networks

A single Docker container or Docker Compose stack on one host is the most common starting point. Most access controls apply directly, and the main changes concern where state lives and how the one host is protected. Because one node holds the application, the database and the uploaded files, its disk, backups and patching carry the whole service.

Secret handling: Keep the secret key and provider keys in a restricted environment file or a secrets manager. Keep the Compose file under version control without credential values.
TLS termination: Run a reverse proxy in front of the container and terminate TLS there. Publish only the proxy port so the application port is reachable from the proxy alone.
Database storage: SQLite is acceptable on one replica only when the database file sits on locally attached SSD or NVMe storage. Confirm the storage type of the host before go-live.
Backups: Back up the SQLite database and the data volume that holds uploads and knowledge files on the same schedule, and test restores on a separate host.
Stays the same: Disabling open sign-up, API key scope, per-resource permissions and review of tools and functions apply unchanged. Without Redis, sign-out does not revoke tokens, which remain valid until they expire, by default after 4 weeks.

Check that the host firewall, operating system patching and volume mount paths are documented, because the single host is also the single point of failure.

How to test that Open WebUI hardening holds and fails safely

This section gives your team a test plan that checks whether each hardening control refuses what it should, and records what happened. Run these checks first in a staging copy that matches production configuration, then repeat them on production after each change, upgrade or permission update. The checks are verification steps your team performs and documents. They show how the system behaves, but auditors decide whether those controls meet a framework's requirements. DeployOpen can prepare the systems, settings and evidence for that review, but does not issue audit reports or attestations.

Start with identity and sessions. As an unauthenticated visitor, attempt self-registration in a private browser window. A fail-safe result is a refusal, with no account created and no session issued. Next, sign in as a standard user, copy the session token from browser storage or a proxied request, and sign out. Replay that token against the web interface and then against an API call. Without Redis, signing out does not revoke tokens, and they stay valid until they expire, by default after 4 weeks. A token that is still accepted is therefore the expected result before Redis is in place. Once Redis is configured across replicas, the same replay should be refused on both paths. Repeat the test after a restart and with a token from a second browser to confirm that revocation is shared.

Next, test authorization boundaries with a non-privileged user. Issue an API key to that account, then call an endpoint or model outside the groups it belongs to. A fail-safe result is an authorization error with no model output or resource content in the response. As the same standard user, attempt to install a tool or function, and attempt to open a knowledge base and a model restricted to another group, using both the interface and direct URLs. Record the account's group memberships and the per-resource permissions at the time of each test, because a pass only means something against a known permission state. Repeat the tool and function test after any upgrade, since admin-only settings are the kind of control that can change between releases.

Then test exposure from outside the trusted network. From a host outside that network, run an authorized port scan against the public address and hostnames of the deployment. The intended result is that only the intended reverse proxy or load balancer endpoint answers. The application, database, Redis and vector store ports should not respond from outside. Scan again from inside the trusted network to confirm the internal path still works. Finally, confirm that the provider key is absent from browser traffic and user-visible settings. Inspect page source, network requests in developer tools, the settings screens a standard user can open, and any exported configuration. A pass means the key never reaches the browser or any screen a user can see.

For every test, record the date, the build or version under test, the configuration reference, the account or source used, the exact step, the expected result, the observed result and the person who witnessed it. Keep screenshots and request and response captures with secrets redacted, and store scan output in a change-controlled location. A fail-safe result means the control refuses the action and fails closed: no account created, token rejected, data withheld, port silent and key absent. If a test appears to pass for the wrong reason, such as an error page that still leaks content, record it as a failure. Agree in writing which checks are in scope and who signs off each result before go-live.

What to monitor, back up, review and document after hardening

Hardening settings only hold if someone checks them on a schedule. The cards below cover access reviews, credential hygiene, log monitoring, recovery testing, upgrade checks and the record that ties them together, so each review can be compared against the same baseline.

Administrator and group membership

Review who holds administrator roles and which groups grant access to models, tools, knowledge and settings. Open WebUI uses role-based access control with groups and per-resource permissions, so a user added to a broad group can gain reach that nobody approved. Compare the current list with your identity provider's groups, remove accounts for leavers, and confirm that SCIM 2.0 provisioning still maps groups to the intended roles.

API key owners and scope

List every API key with its owner, scope and last use, then revoke keys that belong to departed staff, shared accounts or integrations nobody uses. A key is only as narrow as its owner's permissions, so a key issued to an administrator carries that administrator's reach. Confirm in the current documentation how each key's permissions are determined, and repeat the review on a fixed schedule.

Authentication failures and sign-in events

Review failed sign-ins, lockouts, new MFA enrollments and sign-in events in the identity provider alongside Open WebUI and reverse proxy logs. Correlate entries by user and source address to spot password spraying or activity from an account that should have been disabled. Also test that sign-out revokes sessions. Without Redis, tokens stay valid until they expire, by default after 4 weeks, so confirm that the shared state store is in place.

Database and file storage backups

Back up the database and the file storage that holds uploads and knowledge documents on the same schedule, so the two stay consistent. Multi-replica deployments need PostgreSQL and shared file storage, and both must be included. Confirm whether the external vector database can be rebuilt from source files or must be backed up. A backup has no value until a restore has run in a separate environment and users can sign in and open a knowledge document.

Release notes and tool review

Before each upgrade, read the Open WebUI release notes on the GitHub releases page for security fixes, database changes and changes to authentication or permissions. After each upgrade, review installed tools and functions, because they run code inside the platform and need the same owner and permission check as new code. The upgrade steps and rollback plan are covered in the Open WebUI upgrades and support topic.

Hardening record and exceptions

Keep one document that holds the settings baseline, including sign-up mode, token lifetime, network exposure, default permissions and running versions. Add test evidence for each control and a register of exceptions with the reason, owner and review date. This record is what internal reviewers and external auditors will ask for. DeployOpen prepares the evidence, while independent auditors and certification bodies issue any assessment outcome.

What buyers and engineers ask before hardening Open WebUI

How much effort does hardening Open WebUI take, and what drives it?

Effort depends mostly on how much of the deployment is still undecided and how many systems Open WebUI must trust. The main drivers are the identity model (local accounts, OIDC, LDAP or SCIM provisioning), whether open sign-up is disabled, how many model providers and API keys are connected, which users can reach tools, functions and knowledge bases, and how the service is exposed to the network. A single instance with local accounts is a smaller job than a multi-replica deployment with SSO, group-based permissions and a reverse proxy. No public effort figure applies to every environment, so ask any partner to break its estimate into these drivers in the written scope.

How long does an Open WebUI hardening engagement usually take?

Duration follows the same drivers as effort, plus the lead time for your own teams. Scheduling is often the longest part, because identity owners, network teams and change boards each add waiting time that the engineering work does not control. The scope should state which environments are covered (test, staging, production), whether a retest after fixes is included, and what your team must deliver before work starts. Most DeployOpen engagements are fixed-scope, so the timeline is agreed in writing before work begins. Ask for milestones tied to each deliverable, and record any scope change as a change to the timeline.

Can our own team harden Open WebUI without an outside partner?

Yes, many teams can, if they have engineers comfortable with Linux, containers, reverse proxies and identity protocols. Open WebUI's documentation covers the settings involved, including sign-up control, API key handling, SSO, MFA and the Redis requirement for multi-replica sign-out. The harder part is verification: proving that token revocation works, that group permissions hold for each resource, and that tools and functions cannot be used beyond their intended users. Consider whether your team has time to test those paths, keep the configuration current through frequent releases, and document the results. A partner can carry that work under a written scope while your team keeps ownership of the decisions.

What do we need from our identity, network and security owners?

Hardening needs named owners in three areas, and their input should be agreed before work starts. Identity owners decide how users, groups and roles map from your directory, and they approve the OIDC or LDAP settings and any SCIM provisioning. Network owners confirm how traffic reaches the service, including the reverse proxy, TLS termination, allowed inbound access and outbound access to model providers. Security owners set the policy for API keys, MFA, tool and function use, logging, and the test evidence they will accept. Also name an application owner who can approve permission changes, and a platform owner for backups and access to the database and Redis.

Does hardening Open WebUI make our deployment compliant with audits?

No. Hardening prepares controls and collects evidence, and independent auditors decide whether those controls are met. Evidence can include configuration records, test results and access reviews that an assessor may later examine. Auditors and certification bodies determine compliance for your full environment and issue any report or certificate. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications. Ask your assessor which framework applies, which evidence they expect, and who in your organization owns each control, because hosting, data handling, provider contracts and operating procedures also shape the outcome.

Do we need Redis if we run a single Open WebUI instance?

Redis is not required for a single instance, but its absence changes how sign-out works. Redis is the shared state store that lets multiple replicas agree on sessions and websocket connections. Without Redis, signing out does not revoke tokens: they stay valid until they expire, which by default is 4 weeks according to Open WebUI's scaling guide. On one instance you can shorten session lifetimes, document an offboarding procedure that disables accounts, and run a periodic access review. Test that a disabled user actually loses access in your version. If your policy requires immediate revocation after sign-out or offboarding, plan for Redis even with one instance and confirm the behavior before go-live.

What should we ask a partner to include in a hardening quote?

A useful quote is built from a written scope that names the version, install method, environments and controls. List the covered controls, such as sign-up, API keys, SSO, MFA, permissions, network exposure, and tools and functions. Ask how each control is verified, what test evidence is delivered, and whether a retest after fixes is included. Confirm which items you must supply, such as directory access, certificates, hosting accounts and named owners, and what happens if they arrive late. Clarify who runs backups and restore tests, how later upgrades are handled, and which ongoing support or retainer work is excluded. Ask for assumptions and exclusions in writing so that any later change is visible.

Does DeployOpen issue security certifications for Open WebUI deployments?

No. DeployOpen does not issue certifications, attestations or audit reports. DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms, and it runs security testing. Those deliverables can support a compliance assessment, but the assessor or certification body makes the determination and issues any certificate. When a vendor or proposal mentions a certification, ask which body issued it, for what scope, and when it expires. For DeployOpen work, ask for the written scope and the evidence the engagement will produce.

How DeployOpen works on Open WebUI security hardening

DeployOpen plans and implements Open WebUI security hardening inside your own infrastructure, from disabling open sign-up and setting token revocation to scoping API keys and tightening per-resource permissions. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory how users reach Open WebUI today, including sign-up settings, identity sources and any existing API key use
Confirm the deployment shape, since multi-replica installs need Redis for sign-out revocation and PostgreSQL rather than SQLite
Agree in writing which controls are in scope: sign-up, sessions, API key scope, permissions, network exposure and tools

How we build

Configure sign-up, session and token settings, then verify that signing out revokes tokens when Redis is in place
Restrict API keys and per-resource permissions by group, testing that users cannot reach resources outside their role
Review network exposure and the use of tools and functions, documenting which ones are enabled and who may change them

How we hand over

Provide a written configuration record covering each hardened setting, its default and its chosen value
Deliver test evidence showing sign-out revocation, permission boundaries and blocked open registration
Walk your operations team through the runbook for changing settings, rotating keys and reviewing access

How we support

Ongoing support, upgrades and continuous testing are available as retainers after go-live
Re-check hardened settings when Open WebUI releases new versions, since the project ships frequently
Confirm with your team how support, change requests and security retesting will be handled before the engagement starts

Open WebUI security hardening