Self-hosted ChatGPT Enterprise alternative for air-gapped networks

Why an air-gapped network cannot use ChatGPT Enterprise

A team on an isolated network may want the features of ChatGPT Enterprise, such as a shared chat interface, admin controls and document grounding, but it cannot send prompts or files out of its enclosure. The short answer is that ChatGPT Enterprise runs only as an OpenAI-hosted service. The documented controls are SAML SSO, admin retention settings, regional data residency and SOC 2 Type 2 audits, and none of them lets you deploy the service inside your own network. The practical alternative is a self-hosted chat interface connected to models that run on hardware you control. Open WebUI is the main candidate because it runs fully offline and works with Ollama and OpenAI-compatible APIs. LibreChat, Onyx and AnythingLLM are secondary options, each covering a different main use.

The first decision is the model runtime. Ollama runs models locally and binds to 127.0.0.1 on port 11434 by default, and its local API does not require authentication, so it must sit behind a controlled proxy before other users can reach it. vLLM is the better fit for multi-user throughput on GPUs, and its documentation warns that --api-key alone is not enough: it does not protect /metrics or /health, so a reverse proxy should allowlist only the endpoints users need. Confirm that the GPU hardware, drivers and container images can be carried into the enclosure and updated from an approved internal mirror.

Plan for the offline lifecycle before go-live. Model weights, container images, Python packages and interface releases must be brought in through a controlled transfer process, and each one should be checked against the vendor's license terms. Open WebUI's license adds a branding clause above 50 users in a rolling 30-day period, so confirm how it applies to your user count. Logging, access reviews and patch cycles also become your responsibility, because no vendor console will collect them for you. Ask your implementation partner to document each of these steps as part of the scope.

What an air-gapped deployment requires

An isolated network removes the easy defaults: no hosted inference, no vendor telemetry, no pulled updates. Each card below is a component or decision that has to work without internet access, and each one should be verified in your own environment before cutover.

No outbound calls for inference

Start by deciding where inference runs. Ollama binds to 127.0.0.1 on port 11434 by default, and when it runs locally, it does not see your prompts or data. Set OLLAMA_NO_CLOUD=1 so cloud features stay off, and confirm that no model pull or cloud route is reachable from the server. Direct cloud inference at ollama.com requires an API key, so a network with no egress should never be able to reach it. Test with a network capture, not just the configuration file.

Local model and image distribution

Models and container images must arrive through an approved transfer path, then be staged on internal storage. Ollama keeps models in a directory you can move with OLLAMA_MODELS, so plan that location on encrypted storage with backups. For vLLM, the model weights and container images are copied in the same way and pinned by version. Record checksums for every artifact so the team can prove what was loaded into the isolated network.

Offline updates and patching

Open WebUI, Ollama and vLLM all ship frequent releases, so an air-gapped team needs a repeatable import process rather than ad hoc downloads. Open WebUI v0.12.3 was published on October 16, 2026, and vLLM ships new minor releases about every two weeks. Decide who reviews each release, who tests it in a staging copy, and how the approved build is carried across the boundary. Confirm which vendor security notices reach you and through what channel.

Identity through the internal directory

Users should sign in with the accounts your directory already manages. Open WebUI documents SSO through OIDC and LDAP, plus SCIM 2.0 user and group provisioning, so joiners, leavers and group changes flow from your identity provider without local accounts. Map directory groups to Open WebUI roles, then confirm that a disabled account loses access to existing sessions and API keys.

Internal logging and retention

Conversation history, uploads and audit events stay in your database, so logging and retention become your responsibility. Keep Open WebUI on PostgreSQL for multi-instance deployments, back it up with the rest of the stack, and forward application and inference logs to an internal collector. Set a retention period in writing, then test deletion, including vector index entries and shared file storage.

Access reviews on a fixed cycle

Access reviews need evidence that the isolated network can produce on demand. Use Open WebUI role-based access control with groups and per-resource permissions, export the group membership and API key inventory each review period, and have a named approver sign off. Vendor-side admin consoles are not available in an air gap, so the review must cover every local admin account and service credential. Confirm with your assessor which review frequency your control framework expects.

Which open-source components meet the constraint

Open WebUI is the chat interface most teams would put in front of users in place of ChatGPT Enterprise. The project documents that it can run entirely offline and connects to Ollama and any OpenAI-compatible provider from one interface. It installs with Docker and Docker Compose, with Kubernetes and Helm, or with pip install open-webui followed by open-webui serve, so you can pick the method your platform team already operates.

Offline operation: The documented offline mode means the interface itself does not need outbound internet access, but you must stage the container images or Python packages inside the enclave.
Identity: Documented SSO through OIDC and LDAP, SCIM 2.0 provisioning, groups, per-resource permissions and authenticator-app MFA cover most enterprise access rules.
Scaling: Multiple replicas require PostgreSQL instead of SQLite, plus Redis and shared file storage.
License clause: Since v0.6.6 (April 19, 2025), code is under the Open WebUI License. Above 50 users in any rolling 30-day period, altering or removing branding requires an enterprise license or written contributor permission. Code through v0.6.5 remains BSD-3-Clause.
Release pace: Confirm the current release, for example v0.12.3 published October 16, 2026, and test upgrades in a staging enclave before rolling them out.

Confirm the license terms with your legal team before rollout and confirm the offline install steps against the version you plan to run.

Ollama is the local model runtime most often paired with Open WebUI on a single GPU or CPU host. It is MIT licensed, runs on macOS, Windows, Linux and Docker, and exposes a REST API on port 11434 with OpenAI compatibility. Ollama states that running models locally does not expose your prompts or data to it, and it can be told to disable its cloud features.

Default binding: The server binds to 127.0.0.1 on port 11434, so other hosts cannot reach it until you change OLLAMA_HOST and place a proxy in front.
No API authentication locally: The local API at localhost:11434 does not require a key, so network segmentation and a reverse proxy with authentication are your controls.
Model storage: Models live in a default directory per operating system. Set OLLAMA_MODELS to a managed volume so you can back up and copy model files into the enclave.
Cloud features: Set OLLAMA_NO_CLOUD=1 or the server configuration file so no call leaves the network.
Concurrency: OLLAMA_NUM_PARALLEL defaults to 1 per model, OLLAMA_MAX_LOADED_MODELS and OLLAMA_MAX_QUEUE (default 512) shape load under concurrent users.

Confirm that model weights are transferred through an approved, scanned channel, and test that the server cannot reach external hosts from the enclave.

vLLM is the serving engine to consider when several users need throughput on NVIDIA, AMD or Intel GPUs, or when a model is too large for one card. It is Apache-2.0 licensed according to its repository and has no paid edition, so the cost comes from accelerator capacity, infrastructure and the people who run it. The server started with vllm serve exposes OpenAI-compatible endpoints, including chat completions, responses and embeddings, so Open WebUI can point at it directly.

Parallelism: Tensor parallelism works within a node and pipeline parallelism across nodes, with Ray or the built-in multiprocessing backend.
Multi-node risk: Node-to-node communication is insecure by default, without authorization or encryption, so place GPU nodes on an isolated network.
API key limits: --api-key does not protect /metrics, /health or several control endpoints. Put a reverse proxy in front that allowlists only the endpoints users need.
Observability: Prometheus metrics at /metrics cover request counts, token throughput, latency and KV cache use.
Hardware support: Confirm your GPU, driver and CUDA or ROCm combination against the installation documentation before buying hardware.

Frequent minor releases, such as v0.31.0 on October 5, 2026, mean a tested upgrade path and a pinned version are essential in an isolated environment.

Where the commercial product stops and self-hosting starts

The first design boundary is deployment location. ChatGPT Enterprise runs only as an OpenAI-hosted service, and the controls OpenAI documents for it are SAML SSO, admin retention settings, regional data residency and SOC 2 Type 2 audits. Customer-hosted deployment is not among them, so a network with no route to OpenAI cannot run the product at all. This is a design boundary of a hosted service, not a shortcoming to argue with. For an air-gapped network, the practical decision is which parts of the stack must sit inside the enclave: the chat interface, the user store, the model runtime, the retrieval index and the logs.

The second boundary is export. Workspace admins can view, export and delete end user conversations, and the documented audit path for conversations and GPTs is the Enterprise Compliance API, which reads from OpenAI's service. If your records policy requires that conversation history be held in your own store from day one, confirm with OpenAI how and when that data can be pulled, and plan an offline copy in the self-hosted stack before any cutover. Also confirm what happens to logs on the isolated side, since no vendor service will hold them for you.

Microsoft Copilot and Glean Customer Hosted have their own boundaries. Copilot grounds work-based answers in Microsoft Entra and Microsoft 365 content and requires a Copilot license. Glean's Customer Hosted model still leaves infrastructure and application management, including upgrades, patching and monitoring, with Glean. Before you shortlist either, ask each vendor, in writing, which outbound endpoints, licensing checks, telemetry and update channels their product needs, and whether any of them can be cut off while the product still works. Those answers decide whether either option fits the enclave at all.

Open WebUI with Ollama versus vLLM on local GPUs

This table compares the two serving paths an air-gapped team usually weighs for Open WebUI: Ollama as a single-node runtime and vLLM as a high-throughput inference server. Read each row as a question to answer for your own hardware and user count, not as a ranking. The main takeaway is that Ollama asks less of operators, while vLLM gives finer control over concurrency, metrics and multi-GPU scaling, and both need a proxy and network isolation before users reach them.

Decision factor	Ollama	vLLM
Concurrency controls	OLLAMA_NUM_PARALLEL (default 1 per model), OLLAMA_MAX_LOADED_MODELS and OLLAMA_MAX_QUEUE (default 512) set parallelism and queue depth	Scheduling is set through server options; confirm the batching and queue settings for your vLLM version in its serving docs
GPU scaling	Loads models onto available GPUs; no native multi-node model sharding in the supplied docs	Tensor parallelism within a node and pipeline parallelism across nodes, with Ray or its own multiprocessing backend
Metrics	No Prometheus endpoint described in the supplied docs; confirm logging and monitoring options before relying on them	Prometheus-format metrics at /metrics covering request counts, token throughput, latency and KV cache use
API key scope	Local API at localhost:11434 has no authentication by default, so network isolation and a proxy carry the access control	--api-key protects /v1 and related paths but not /metrics, /health or /invocations, so a reverse proxy must allowlist user endpoints
Node-to-node security	Single-host design; no multi-node communication to protect in the supplied docs	Inter-node traffic is unauthenticated and unencrypted by default, so nodes must sit on an isolated network
Operational burden	Lower: one runtime, frequent releases to track, model files moved with OLLAMA_MODELS	Higher: GPU driver and container stack, multi-node topology, Kubernetes options and a biweekly minor release cadence to track
Model and API compatibility	OpenAI-compatible API plus Python and JavaScript SDKs; models pulled as packaged artifacts	OpenAI-compatible endpoints including chat, completions, responses, embeddings and transcription for applications built on the OpenAI API
Offline model distribution	Models stored in a directory you can copy to an isolated host; confirm the pull workflow for your mirror	Weights are loaded from local paths or a mirror you stage; confirm the transfer and verification process with your team
Decision question	Is a single-server deployment with modest concurrency enough for your user count and model size?	Do you need multi-GPU or multi-node throughput, detailed metrics and tighter control of the serving layer?

How to deploy Open WebUI and local models without internet access

This sequence takes an isolated network from approved transfer media to a working chat interface backed by local models, with each step closing on a check that confirms the stack runs without outbound traffic.

Stage installers, images and model files
The platform team, working with the security team, downloads the Open WebUI and Ollama packages or container images, the PostgreSQL and Redis images if you plan multiple replicas, the reverse proxy image and the model files you approved, then verifies checksums on the staging host. Everything moves across the approved transfer medium into an internal artifact store or registry. Done means every component installs from internal sources only, and the change record lists each artifact with its version and checksum. Confirm with your own change process how transfers are logged and who signs off on them.
Install Ollama with an internal model store
On the inference host, install Ollama from the staged package and set OLLAMA_MODELS to an internal directory on a volume your team controls, then copy the approved model files into that directory. Set OLLAMA_NO_CLOUD=1 in the server configuration so cloud features stay off. Ollama binds to 127.0.0.1 on port 11434 by default, so keep that binding for a local-only service or set OLLAMA_HOST deliberately if other hosts must reach it. Done means the server lists the staged models and answers a local generation request without any external connection.
Deploy Open WebUI with PostgreSQL and shared storage
Deploy Open WebUI from the internal registry using Docker Compose, Kubernetes with Helm, or the pip install method, pointing its model connection at the local Ollama endpoint. For more than one instance, the scaling guide requires PostgreSQL instead of SQLite, and multiple replicas also need Redis for shared sessions and websocket state plus shared file storage so uploads and knowledge stay reachable from every replica. Done means a user can sign in locally, select a staged model, and send a prompt that returns a response, and the database and file store sit on storage your team operates.
Place a reverse proxy that allowlists user endpoints
Put a reverse proxy in front of Open WebUI and any model endpoint that users reach, and allowlist only the paths your users need. Block direct access to Ollama's port from user networks, and for vLLM also block /metrics, /health and other operational paths from users, since its --api-key option does not protect every route and the vendor recommends this proxy pattern. Done means a request to an operational or administrative path from a user subnet is refused, while the chat path succeeds, and the proxy logs record both outcomes.
Connect the internal identity provider
Configure Open WebUI's SSO against your internal identity provider using OIDC or LDAP, then enable SCIM 2.0 provisioning if your directory supports it so users and groups sync automatically. Map groups to Open WebUI roles and per-resource permissions, and enable authenticator-app MFA where your policy requires it. Confirm with your identity team which directory attributes feed group mapping. Done means a test user from each group gets only the roles and models assigned to that group, and a disabled account can no longer sign in.
Verify no outbound traffic occurs
From a host in the isolated segment, run a test that attempts outbound connections to public internet addresses and package registries, and confirm that the firewall or network policy drops them. Then check Open WebUI and Ollama logs for any attempt to reach external model providers during a full chat session, document, and model load. Done means the test shows zero successful egress, the logs show only internal addresses, and the results are filed with the change record for your assessor. Repeat this check after every update.

How updates, releases and model files reach an isolated network

Open WebUI, Ollama and vLLM all ship frequent releases, so an air-gapped stack needs a controlled path for every new version before it reaches users. The supplied release history shows the cadence: Open WebUI published v0.11.0 in July and v0.12.0 on October 10, then v0.12.3 on October 16, 2026; Ollama released v0.40.5 on October 14, 2026 and published v0.40.6 as a pre-release on October 16; vLLM shipped minor releases on August 26, September 9, September 22 and October 5, 2026. Pulling these directly from the internet is not an option on an isolated network, so each release has to be downloaded on a connected staging system, verified, and carried across through your approved transfer process. Treat pre-releases as a separate track that stays out of production unless you explicitly test them.

Model weights and container images need the same treatment, and the license check comes first. Before importing a model, confirm its license terms, acceptable use restrictions and any attribution duties, and record the decision alongside the file's checksum. Ollama stores pulled models in a directory set by OLLAMA_MODELS, so an approved model set can be staged there and copied to each inference host. For vLLM, models usually load from a local path, and the container images for vLLM, Open WebUI and Ollama should be mirrored into your internal registry with pinned tags rather than latest. Ask each project and your model providers to confirm their release cadence, support windows for older versions and how security fixes are published, since those answers decide how often your change process will run.

Write the change process before the first import, not after the first incident. It should name who approves a new image or model, which test environment runs the release notes check and a regression run against your own prompts, and how a rollback works if a release changes the API surface that Open WebUI calls. Scheduling is a decision you own: a monthly window with an emergency path for critical fixes is a common pattern, but the right rhythm depends on your risk appetite and staffing. Also confirm with the project maintainers which components a given release changes, because an Open WebUI update may not require a vLLM restart and the reverse is also true.

What auditors and assessors will ask to see

An assessor reviewing an isolated AI assistant will want proof that nothing leaves the network, that access is granted and removed through documented groups, and that every change to the stack is traceable. The cards below list the artifacts that connect those claims to the running system. DeployOpen prepares this evidence as part of implementation; independent auditors and certification bodies are the ones who issue any opinion on it.

Network diagrams showing no egress

Start with a diagram that shows every host, container network and model endpoint, and the absence of any route to the internet. Include the Ollama or vLLM listener, the Open WebUI front end, the database, the vector store and the reverse proxy. Pair the diagram with firewall rule exports and a test log showing that outbound connections from the application tier are refused. Ask the team to confirm whether any package manager, telemetry or update check still points outside the enclosure.

Ollama bind and cloud settings

Assessors will look for the configuration that keeps the model runtime local. Ollama binds to 127.0.0.1 on port 11434 by default, and the OLLAMA_HOST variable changes that address, so the captured configuration should show exactly what it is set to. Record OLLAMA_NO_CLOUD=1 in the service file or server configuration, and keep the config under version control so changes leave a history. The unauthenticated local API is only acceptable when it is reachable from the application tier alone.

Access review records from SSO and SCIM

Access reviews show who can sign in and which groups they belong to. Open WebUI documents OIDC and LDAP sign-in, SCIM 2.0 provisioning and role-based access control with groups, so export the group membership and role assignments from the identity provider at each review date. Compare those exports with the users present in Open WebUI and flag orphaned accounts or API keys. Confirm with the identity team how the directory reaches the isolated network, since that path is often a one-way sync.

Conversation and admin audit logs kept internally

Assessors will ask whether conversations and administrative actions can be reconstructed without the vendor. Because the stack runs in your environment, the logs are yours to retain, forward to an internal SIEM and protect. Define which events are recorded, including sign-ins, role changes, model changes and deletions, and who can read or alter those logs. Test that a sample event appears in the central store, and document the retention period your policy requires.

Update and patch records from the offline mirror

Each upgrade needs a trail: which release was pulled into the mirror, when it was verified, who approved it and when it reached production. Open WebUI, Ollama and vLLM publish releases frequently, and vLLM has documented minor releases about every two weeks in 2026, so the process needs a fixed cadence and a rollback plan. Keep checksums, the approved change ticket and the image or package digest for each version. Confirm how security advisories will reach the team when no internet connection exists.

Retention settings in the database

Retention is enforced where the data lives, so assessors will ask to see the database schema, the scheduled deletion jobs and the file storage cleanup for uploads and knowledge collections. Verify that deleted conversations are removed from the primary database, the replicas, backups and the vector index, and document how long backups keep them. Run a deletion test and capture the query results before and after. Ask the team to confirm whether the PostgreSQL and Redis instances used for multi-replica deployments follow the same rule.

Questions buyers ask before deploying offline

What does an air-gapped Open WebUI deployment cost, and what drives it?

Most of the cost sits in GPU capacity, implementation and the people who operate the stack, while the software itself carries no license fee for ordinary use. Open WebUI is distributed under its Open WebUI License, Ollama is MIT licensed, and vLLM is Apache-2.0 with no paid edition, so the recurring lines are hardware, staff time and any support contract you choose. The main drivers are how many users you serve, which models you run, how much concurrency you need and how many GPUs you buy or lease. Ask for a quote that lists GPU hardware, implementation, offline update procedures, backup, monitoring and ongoing operations as separate lines, with one-time and recurring costs marked.

How long does an offline deployment take to implement?

Duration depends on the network design, the hardware already in place and how much integration you need with identity, logging and document sources, so no fixed timeline applies across environments. Plan separately for hardware delivery, model and container image transfer into the enclave, identity integration and acceptance testing. Confirm the duration, milestones and dependencies in a written scope before work starts, since most engagements are fixed-scope and the agreed document is the only reliable timeline.

What must our team provide before the work starts?

Your team needs to supply the environment and the people who know it. Typical inputs include:

Isolated network segments, with a documented path for moving approved software and models in and out
GPU servers or accelerators sized for the models you select, with drivers your platform team can support
Identity provider details for SSO through OIDC or LDAP, and group mappings for role-based access
Named staff for approvals, operations and access reviews, plus someone who owns the offline update process

Confirm each item with your security and infrastructure leads before scoping, because gaps here usually extend the work.

Can our own team run an air-gapped AI stack without an outside partner?

Yes, if you have people who can operate Linux, containers, GPU drivers and an identity integration, and who can run a repeatable process for offline updates. The stack is built from open-source components with documented install methods, including Docker, Kubernetes with Helm and pip for Open WebUI, and the vLLM docs describe the operational settings you will manage. The harder parts are capacity planning, patching model and image bundles, and keeping logs and access reviews running without internet access. Many teams hire outside help for the first deployment and then take over operations, while others keep a retainer for upgrades and testing. Decide which of these fits your staffing before you ask for a quote.

Does the Open WebUI license require us to keep its branding above 50 users?

Yes, the Open WebUI License forbids removing or altering Open WebUI branding in deployments that exceed 50 users in any rolling 30-day period, unless you hold an enterprise license or get written permission from the copyright holder. Code through v0.6.5 remains under BSD-3-Clause, and the license applies to later releases from v0.6.6. Open WebUI offers enterprise licenses that allow white-labeling and custom branding, with dedicated support options, but pricing is not published and is quoted after you contact enterprise sales with an expected seat count. Have your legal team read the license text and check it against your user count before you roll out the interface.

Can Ollama be configured so cloud models are disabled in an isolated network?

Yes, Ollama states that cloud features can be turned off with the OLLAMA_NO_CLOUD=1 environment variable or in the server configuration file. Running models locally means your prompts stay on the host, and the local API at port 11434 does not require authentication, so you should restrict it with network controls and a reverse proxy. Verify the setting on the exact version you deploy, and test from inside the enclave that no outbound calls to ollama.com are possible. Document the test result as part of your evidence for the access and change reviews.

What does a team need to confirm about vLLM in an isolated network?

Confirm that your vLLM deployment is protected by network placement and a reverse proxy, since the vLLM security docs state that the --api-key option does not cover every endpoint and recommend allowlisting only the endpoints meant for users. Multi-node communication is insecure by default, so nodes must sit on an isolated network. Also confirm your GPU driver and CUDA or ROCm versions against the release you choose, because vLLM ships minor releases about every two weeks and you will need a tested offline upgrade path. Ask your implementation partner to show how metrics at /metrics are collected and kept inside the enclave.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. For an air-gapped assistant, that means scoping the model runtime, chat interface and retrieval stack together, then delivering them as a set you can run without internet access.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope lists the chat interface, model runtime, GPU hardware, identity integration and document sources in your enclave.
We confirm which users, groups and sensitivity levels the assistant must serve, and which logs your audit team needs.

How we build

We install Open WebUI with Ollama or vLLM on your GPUs, using the install methods your platform team already runs.
We prepare offline bundles for container images, model weights and packages, and verify them inside the isolated network.
We configure SSO, group-based access, PostgreSQL and shared storage, and test the deployment against your written acceptance criteria.

How we hand over

You receive documentation covering installation, configuration, backup, restore and the offline update procedure.
We document the access review steps, log locations and retention settings your compliance team can inspect directly.
Handover includes a walkthrough with your operators so they can run patches and model changes without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover staged updates of the chat interface and runtime, with each release tested in a non-production enclave first.
Ask any provider which vendor support, license and branding terms apply to your user count before you commit to a scope.