Open WebUI offline and air-gapped deployment

Build a complete staging manifest before the network is cut, because a missing dependency usually surfaces only when a user first triggers the feature that needs it. An offline install must carry the Open WebUI container image or the pip package, the chat model weights, the embedding and reranking models used for retrieval, the document extraction components that parse uploads, and the image for the vector database you chose. It must also carry a verified network path to the identity provider for SSO through OIDC or LDAP. Record each artifact with its version and checksum, then reconcile that list against a test installation on a connected build host.

Model storage is where offline installs most often fail. If you run Ollama, the default model directory depends on the operating system, and the OLLAMA_MODELS variable moves it to another location. Confirm the target path on the air-gapped host, set the variable before the first start, and load each model once inside the boundary to confirm it runs. Treat the transfer itself as a controlled process: verify the integrity and authenticity of every package, container image and model file before it crosses, and keep a signed record of each check. This is the kind of control NERC CIP-013-2 addresses for regulated utilities, which requires supply chain procurement processes to verify software integrity and authenticity.

Optional features are the second source of failure, because several of them can make outbound calls. Confirm with the Open WebUI documentation which features reach external services in the version you deploy, including web search, speech, image generation and model catalogs. For each one, either disable it in the administrator settings or pre-stage what it needs inside the boundary, such as speech models or a search backend you host. Record the decision for each feature, so that a reviewer can see every outbound path was closed on purpose and tested rather than discovered later in production logs.

Identity and state services need the same discipline. The SSO provider must be reachable from the Open WebUI network segment, its certificate chain must be trusted by the host, and group claims should be tested with a dedicated account. If you run several replicas, the external vector database, Redis and shared file storage from the scaling guide must come across as versioned images or packages. Test the staged set on an isolated network with the outbound route blocked by running a sign-in, a file upload, a retrieval query and a chat against each configured model. Any failure at that stage points to a missing dependency, and finding it before the cut is far cheaper than finding it afterward.

The topology you choose sets the size of your offline bill of materials, so settle it before you stage any images. The Open WebUI scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments, because SQLite does not handle concurrent writes from multiple processes well. For multiple replicas, the guide also requires Redis as a shared state store for sessions, websocket connections and application state, plus shared file storage so that uploads and knowledge stay reachable from every replica. In a connected environment these are routine services to add. Inside an isolated boundary, each one becomes a component you must deploy, patch, back up and restore without pulling anything from the internet, and each one's images or packages must be carried across the boundary and checked before use.

The scaling guide also warns that the default ChromaDB will crash in multi-process setups, so an external vector database is required when you run several workers or replicas. Open WebUI's retrieval features support 13 vector databases, including PGVector, Qdrant, Milvus and Elasticsearch, and the choice should follow what your team can already operate. Pick the option early and confirm that its install method works with no internet access. Hybrid BM25 plus vector search and cross-encoder reranking also depend on models and assets that must be staged inside the boundary, so confirm with your Open WebUI version which of those assets the retrieval pipeline downloads on first use. A reranker that fetches its weights at runtime will fail quietly in an air-gapped network.

Redis also changes how sign-out behaves, and this matters for offboarding in a restricted environment. Without Redis, signing out does not revoke tokens. They stay valid until they expire, by default after 4 weeks. A user who leaves the organization, or whose device is lost, can keep a working session for that window unless you act on it. For a multi-replica deployment, treat Redis as a security control rather than only a performance component, and test sign-out on two replicas before go-live. If you run a single instance, confirm with your identity team how session expiry and account disablement reach Open WebUI, and document the procedure for ending active sessions when an account is disabled in your identity provider.

SQLite remains an option, but only in narrow cases. The scaling guide accepts it for single-replica deployments, evaluation and small teams, and only when the database file sits on locally attached SSD or NVMe storage rather than network storage. Offline sites often mount shared volumes from a storage array or network file system for convenience, and that is the setup this rule excludes. Check the storage type of the host that will hold the database with your infrastructure team, and record the answer in the design. If the site later adds a second replica, the PostgreSQL, Redis and shared storage work described above starts from zero, so plan the migration path now rather than treating SQLite as a permanent choice.

An offline Open WebUI installation still needs a reachable identity provider for sign-in. Open WebUI documents single sign-on through OIDC and LDAP, so the first decision is which of these protocols your directory supports and where that provider runs. The identity provider must sit inside the same boundary as Open WebUI, or it must be reachable through an approved, documented path such as a controlled gateway. If neither holds, users cannot sign in, and no fallback should quietly reintroduce an outside dependency. Record the chosen provider, its network location, and the owner who can change its configuration before any other SSO setting is touched.

Confirm three things in your own environment before go-live. First, the redirect URLs registered in the OIDC client must match the exact external hostname, scheme and port that users will type in the isolated network, because a mismatch fails at the callback step. Second, the certificate trust chain for the internal certificate authority must be present in the runtime trust store of every Open WebUI host or container, so discovery and token requests succeed without disabling verification. Third, for LDAP, test connectivity from the Open WebUI network segment to the directory over the TLS-protected port you intend to use, with the bind account and search base you plan to keep. Each of these checks depends on local firewall rules and certificates, so none can be assumed from the software documentation.

SCIM 2.0 provisioning is a separate concern from sign-in. Sign-in answers whether a person can log in, while provisioning creates, updates and deactivates user accounts and group memberships ahead of or after login. Open WebUI documents SCIM 2.0 user and group provisioning, so decide whether your identity provider will push accounts into the offline instance or whether accounts will be created at first sign-in. If SCIM is used, confirm that the identity provider inside the boundary can reach the Open WebUI SCIM endpoint and that deprovisioning is tested. Groups then carry the access model. Open WebUI uses role-based access control with groups and per-resource permissions, so a group that appears in the directory should map to a deliberate set of models and knowledge collections. Review every group mapping before users are granted access.

Sign-out and session lifetime need explicit planning. The scaling documentation states that without Redis, signing out does not revoke tokens, which then stay valid until they expire, by default after 4 weeks. A disabled user in the identity provider can therefore keep an active session for that period unless revocation works in your deployment. Multi-replica deployments need Redis as a shared state store for sessions, so the Redis placement and its persistence fall under the same boundary review as the identity provider. Ask the team to test a sign-out and a disabled-account login on the exact topology you will run, and set the token lifetime with the security owner rather than accepting the default.

Test multi-factor authentication before users depend on it. Open WebUI documents authenticator-app MFA, and the enrollment flow must work with no internet access. Run a dry run on a network with no egress: enroll a test account, confirm that the enrollment page loads its assets locally, check that no step calls an external font, script or messaging service, and sign in with a generated code. Also test recovery codes or the administrator reset path, and confirm who can clear an enrollment when a device is lost. Record the results as evidence, because an enrollment that depends on an outside service will fail silently in the isolated environment.