Self-hosted Microsoft 365 Copilot alternative for air-gapped networks

Why an air-gapped network cannot use Microsoft 365 Copilot and what replaces it

Microsoft 365 Copilot cannot run on a network that cannot reach Microsoft cloud endpoints. Its answers are grounded in Microsoft 365 services such as Exchange, SharePoint, OneDrive and Teams, and work-based Copilot Chat requires a Microsoft Copilot license tied to a Microsoft Entra account. The facts available to this page do not establish any offline or customer-hosted mode for Copilot, so a disconnected or classified enclave should treat it as out of scope unless Microsoft confirms otherwise in writing for the specific environment. Ask your Microsoft account team to confirm the endpoints, data flows and government cloud options that apply to your network before you rule anything in or out.

The short answer is to run the whole stack inside the network. Onyx serves as the search and chat layer, connecting to the internal sources you are permitted to index and enforcing the permissions it syncs from them. Ollama or vLLM serves the language model on hardware you own, so prompts and retrieved passages never leave the enclave. Onyx documents an air-gappable, self-hosted deployment in which the index, database and processing run in a self-contained set of services. Ollama states that when it runs locally it does not see your prompts or data, and its local API does not require authentication, so access control must come from the layers around it. Confirm with your security team which of those layers, such as a reverse proxy, will enforce it.

What an air-gapped assistant must do

A disconnected assistant has to answer questions without reaching any outside service, index sources from inside the network, and respect the access rules those sources already enforce. Each requirement below ties to a capability in the stack and to a check your own environment must pass before go-live.

No outbound calls at runtime

Every component, including the model runtime, the index, the database and the interface, must work with no route to the internet. Onyx documents an air-gappable deployment in which the document index, database and processing run inside a self-contained set of services. Confirm this with a network test: block egress at the firewall, run a full query and an ingestion job, and check the logs for any attempted outbound connection. Also disable cloud features in Ollama with OLLAMA_NO_CLOUD=1.

Indexing inside the network

Connectors must reach SharePoint, OneDrive, Confluence, Jira and other internal sources from within the disconnected enclave, with no staging copy outside it. Confirm which connectors your sources need, whether each one works against your on-premises or private-endpoint versions, and where the index and object storage physically sit. Any document that leaves the enclave for OCR, embedding or parsing through an external service breaks the air gap, so ask the implementer to list every processing step.

Permission-aware answers

An internal assistant is only safe if answers draw solely on documents the user could already open in the source application. Onyx syncs source permissions, so this must be tested rather than assumed. Build a test set with restricted folders, mailboxes and Teams channels, run queries as users with different access, and confirm that restricted content never appears in answers or citations. Re-run the test after each permission change in the source system.

Local sign-in and identity

Onyx supports SSO through Google OAuth, OIDC or SAML, with SCIM user provisioning, so accounts can come from a directory hosted inside the enclave. The identity provider must be reachable only from the internal network and must hold the group memberships that drive access. Confirm session lifetime, MFA enforcement, and how deprovisioning removes access when someone leaves. Ollama's local API at localhost:11434 has no authentication, so keep it bound to 127.0.0.1 or behind a proxy that enforces login.

Protected model endpoints and logs

Model servers must not be open to any host that does not need them. vLLM's --api-key option does not cover every route, including /metrics and /health, so the docs recommend a reverse proxy that allowlists only the endpoints users need. Multi-node vLLM traffic is unauthenticated by default and must sit on an isolated network. Confirm that query history, usage analytics and access logs are retained inside the enclave, and that the Prometheus metrics endpoint is reachable only by your monitoring host.

Controlled offline updates

A disconnected network cannot pull container images, model weights or Helm charts directly, so updates arrive by approved transfer. Build an internal registry and model store, scan every artifact, and record the version you approved. Onyx publishes releases such as v4.9.2 and a Helm chart at version 0.9.17, while Ollama and vLLM release often, so agree a cadence and a rollback plan in writing. Confirm which dependencies, such as Postgres, Vespa or OpenSearch, Redis and model servers, must also be mirrored.

Which open-source components meet the constraint

Onyx Community Edition is the component that replaces Copilot's grounding in company content. It is MIT licensed and covers RAG, AI chat, agents and actions. Pointed at Ollama, the model runs on hardware inside your network, so prompts and retrieved passages never leave it. Ollama is also MIT licensed and binds to 127.0.0.1 on port 11434 by default, which you must change deliberately for other hosts to reach it.

Data path: The document index, database and processing run in a self-contained set of services that Onyx documents as air-gappable, deployable with Docker, Kubernetes, Helm or Terraform.
Licensing: Onyx CE is MIT, but code in ee directories falls under the Onyx Enterprise License. Ollama is MIT.
Connectors: Onyx ships connectors for SharePoint, OneDrive, Outlook, Teams, Confluence and Jira, but a disconnected network can only reach sources hosted inside it.
Enterprise features: RBAC is part of the self-hosted Enterprise Edition, not the Community Edition. Confirm whether SCIM and SSO options work with your identity provider without internet access.
Model limits: Ollama's default parallelism is one request per model, so size OLLAMA_NUM_PARALLEL and hardware for your user count.

Confirm with Onyx which Enterprise features run with no outbound connections, and test the offline update path before go-live.

vLLM is an Apache-2.0 licensed serving engine for organizations that need GPU throughput for many concurrent users. It exposes OpenAI-compatible endpoints, so Onyx can call it as a model provider without code changes. Because vLLM has no paid edition, the cost sits in accelerators, infrastructure and the staff who run it. In an air-gapped network, the model weights must be copied in ahead of time, since the server cannot fetch them from the internet.

Data path: Inference stays on GPUs inside the enclosure, and metrics are exposed at /metrics for your own Prometheus stack.
Access control: The --api-key option does not protect /metrics, /health or /invocations. The vLLM docs recommend a reverse proxy that allowlists only the endpoints users need.
Multi-node security: Node-to-node traffic is insecure by default, so place multi-node clusters on an isolated network.
Hardware support: NVIDIA CUDA, AMD ROCm, Intel XPU, x86, ARM and Apple silicon are listed, but confirm driver and CUDA versions against your accelerator inventory.
Release cadence: vLLM ships minor releases about every two weeks, so plan a controlled offline patch process.

Ask your team to confirm the exact endpoint allowlist and how weights, container images and driver packages will be transferred across the air gap.

How to deploy Onyx and a local model without outbound access

This sequence takes an air-gapped network from staged software and hardware to an Onyx assistant that answers from internal sources, runs its model locally and is verified to make no outbound connections. Each step ends with a check you can record for your own change or security review.

Size hardware for the model server
The network architect and the platform team choose the model server first, because it sets the GPU or CPU requirements for the whole stack. Ollama suits small teams and smaller models on modest hardware, while vLLM is built for GPU serving with concurrent users and supports tensor parallelism within a node. Confirm memory, accelerator type and storage with the vendor documentation for the exact model you plan to use. The step is complete when you have a written hardware bill of materials and the model file sizes are recorded for storage planning.
Stage container images and the Helm chart offline
Someone with access to an internet-connected staging environment pulls the Onyx container images and the Helm chart at versions you have tested, then transfers them through your approved media process. Onyx v4.9.2 and Helm chart 0.9.17 are the versions dated in the research for this page, so confirm they are still the versions you want before staging. Also stage the model server images, the Ollama or vLLM binaries, and any model weights. The step is complete when every artifact has a checksum recorded, and a registry inside the network serves all of them.
Deploy Onyx with Docker, Kubernetes or Helm
The platform team deploys Onyx inside the network using Docker, Kubernetes with Helm, or Terraform, depending on your standard. Onyx documents a self-contained set of services covering the document index, database and processing, so choose a footprint that matches your concurrency needs. Use Onyx Lite if you do not need a vector database or background workers, and Onyx Standard if you do. Confirm that the Postgres, index, Redis and model server pods or containers start and report healthy. The step is complete when the web interface loads from an internal address only.
Point Onyx at the local model server
The platform engineer configures Onyx to use the internal Ollama or vLLM endpoint as its model provider. For Ollama, the API listens on port 11434 and binds to 127.0.0.1 by default, so set OLLAMA_HOST deliberately if other hosts must reach it. Set OLLAMA_NO_CLOUD=1 in the server environment or configuration file so cloud features stay off, and keep model files in a directory you control through OLLAMA_MODELS. The step is complete when a test question returns an answer generated by the local model.
Lock vLLM behind a reverse proxy
If you run vLLM, the security engineer places a reverse proxy in front of it that allowlists only the endpoints users need, such as /v1/chat/completions and /v1/embeddings. The vLLM documentation states that the --api-key option does not protect every route, including /metrics, /health and /pause, so do not rely on the key alone. Keep the metrics endpoint reachable only from your monitoring network. Multi-node vLLM traffic is unauthenticated and unencrypted by default, so isolate those nodes on a protected network segment. The step is complete when requests to non-allowlisted paths are refused at the proxy.
Connect internal sources and configure access
The Onyx administrator configures connectors for the internal sources that matter, such as SharePoint, Confluence or file shares where supported, and confirms that the connector credentials are issued from your identity system. Set SSO through OIDC or SAML, and enable SCIM provisioning if your directory supports it, so that Onyx follows your group membership. Onyx syncs source permissions, so check that a test user sees only the documents they can open in the source application. The step is complete when a permission test passes for at least one restricted document and one shared document.
Test that DNS and egress are blocked
The network security team runs a controlled test from the Onyx and model server hosts to confirm they cannot reach the internet. Attempt DNS resolution and outbound connections to public addresses, and confirm each attempt fails at the firewall or resolver, and record the results. Then confirm that Onyx chat and indexing still work using only internal addresses. Repeat this test after every update, because a new image or chart version can introduce a new external dependency. The step is complete when the test log is signed off by the security owner and filed with the change record.
Stage future updates through the offline process
The platform team defines how updates reach the network, using the same staging, checksum and transfer process used at deployment. Ask Onyx and your model server vendor how they publish release notes, security advisories and chart changes so you can review them before transfer. Plan a rehearsal in a non-production environment for each update, and keep the previous versions available for rollback. The step is complete when a documented update runbook exists and one update has been rehearsed end to end.

How offline updates and model refreshes work in a disconnected network

In a disconnected network, every update to the assistant stack has to be brought in on purpose, so the first decision is who owns the mirror-and-verify process. Ollama and vLLM both ship frequently: the supplied release history lists Ollama v0.40.5 on 14 October 2026 and vLLM v0.31.0 on 5 October 2026, with new vLLM minor releases about every two weeks. Each release can change container images, Python dependencies, model runtime behavior and API details, so pulling updates ad hoc into an enclave is not a control. Set up a change-control step that records which component versions are approved, who signs off, and which upstream sources are allowed to feed the transfer media. Cover five artifact types: container images, Helm charts, model weights, Python dependencies and the Onyx connector and index images themselves.

Verify each artifact before it enters the enclave. Pin versions and digests in your own registry, keep checksums or signatures alongside the transferred files, and scan images with the vulnerability tooling you already run. Model weights deserve the same care as code, because a changed weight file changes answers without changing any version string. Run every candidate update in a staging enclave that mirrors production's model, index and permission configuration, and test with a fixed set of internal questions whose correct answers you already know. Confirm that Onyx still respects the permissions synced from its connectors after the upgrade. The vLLM security guidance on the OpenAI-compatible endpoints also means a changed endpoint surface should trigger a review of the reverse proxy allowlist.

Plan rollback before the upgrade window opens. Keep the previous image tags, chart versions and model files in the enclave until the new version has run through a full business cycle, and record the exact commands that restore them. Ask Onyx directly whether its releases include offline update tooling, how database migrations are reversed, and whether its Helm chart versions can be pinned and rolled back in a disconnected cluster. The facts available for this page do not describe Onyx's offline update process, so treat that answer as an open item for the vendor and for your own proof-of-concept rather than as a given. Ask the same questions of any implementation partner, and write the answers into the runbook that your change board approves.

Questions buyers ask before choosing an air-gapped Copilot alternative

What does a self-hosted air-gapped assistant cost to run, and what drives it?

Expect costs in four buckets: accelerator hardware or capacity for inference, hosting for the index and database, connector setup, and ongoing operations. Hardware is usually the largest variable, and it depends on the model size, the number of concurrent users and whether you use Ollama on modest hardware or vLLM on GPUs. Onyx Community Edition is MIT licensed, so software licensing is not the line item; Enterprise Edition features are a separate question. vLLM has no paid edition, so its cost comes from GPUs, surrounding infrastructure and the people who operate it. Ask any implementation quote to separate one-time setup from recurring hardware, support and upgrade work, and to state which models and user counts it assumes.

How long does an air-gapped deployment take, and what sets the schedule?

No researched figure exists for a duration, so treat any timeline as something to confirm in a written scope. The main drivers are how many source systems you connect, whether SharePoint, Teams and Outlook permissions must sync exactly, how quickly you can source and install GPU hardware inside the network, and how many models you validate. Offline delivery also adds time: images, model weights and Helm charts must be staged through an approved transfer process before anything is installed. Ask for a milestone plan that shows when the first connector returns permission-filtered results and when the model is accepted for production use.

What does our team need to provide for an air-gapped rollout?

The team must supply the target infrastructure, approved hardware or accelerator capacity, a secure transfer path for software and model artifacts, and access to identity (such as OIDC or SAML) and the source systems to be indexed. Security and compliance staff need to agree on retention, logging and how audit evidence is kept inside the network. Someone must own the model choice and the update cadence, since Ollama and vLLM both ship releases often. Ask the implementation partner to list these inputs in writing before work starts, along with who approves each one.

Can our own engineers build and run this without an outside partner?

Yes, the components are open source, so a capable platform team can deploy them. The harder parts are permission-aware connectors, model serving hardened for internal use, offline patching and evidence for audits. Onyx documents Docker, Kubernetes, Helm and Terraform paths, and vLLM publishes Kubernetes options, but the vLLM security docs state that node-to-node traffic is insecure by default and that its --api-key option alone is not enough. Assess your team's experience with GPU operations, identity integration and air-gapped update processes before deciding. Many organizations split the work, keeping operations in-house and buying scoped testing or hardening for specific milestones.

Can Microsoft 365 Copilot run on a disconnected network at all?

No. Microsoft 365 Copilot depends on Microsoft cloud services, and Microsoft Learn describes work-based Copilot Chat as grounded in content a user's Microsoft Entra account can access, which requires a Copilot license and connectivity. Web-based Copilot Chat only shows internet results, so it adds no value on a disconnected network. Confirm the current deployment and connectivity requirements directly with Microsoft for your tenant and environment, since product behavior changes. The practical alternative is an assistant that runs entirely inside your network, such as Onyx with a local model.

Do we need Onyx Enterprise Edition features for an air-gapped deployment?

Not necessarily. Onyx Community Edition is MIT licensed and covers RAG, AI chat, agents and actions, and Onyx documents an air-gappable deployment with its document index, database and processing running inside a self-contained set of services. Enterprise Edition adds features such as role-based access control, which Onyx lists among its enterprise features. Decide based on your access model: if you need fine-grained roles beyond what synced source permissions provide, price the Enterprise Edition and its license terms. Confirm the license scope for any ee directory code before deployment, since it falls under the Onyx Enterprise License.

Evidence assessors will ask for under an air-gap constraint

An air-gapped assistant is only as credible as the records behind it. The cards below cover the evidence that assessors and internal audit typically request, mapped to the components in a self-hosted Onyx stack with Ollama or vLLM. DeployOpen prepares this evidence for your environment but does not issue audit reports, attestations or certifications; independent auditors and certification bodies do.

Network diagrams showing egress controls

Assessors will want a current diagram that shows every path into and out of the enclosure, including which hosts can reach the Onyx services, the database, the index, the model servers and the update mirror. Mark the points where egress is blocked, where connectors pull from internal systems, and where the offline update media enters. Ask your network team to show that the disconnected segment has no default route to the internet, and capture firewall rule exports that match the diagram. A diagram that does not match the rule set is a finding in its own right.

Ollama and vLLM bind and auth configuration

Record the bind address and authentication state of each model server. Ollama listens on 127.0.0.1 port 11434 by default, and its local API does not require authentication, so the configuration showing any change to OLLAMA_HOST and the proxy in front of it is central evidence. For vLLM, the --api-key option does not cover every endpoint, so keep the reverse proxy configuration that allowlists only the endpoints users need. Export the effective configuration and the proxy rules, not only the intended settings.

SSO and access logs from Onyx

Show how users sign in and what they did. Onyx supports SSO through Google OAuth, OIDC or SAML, and lists SCIM provisioning, role-based access control and query history auditing among its enterprise features. Confirm which of these your chosen edition includes, since the Enterprise Edition carries premium features such as RBAC. Keep the identity provider logs, the Onyx authentication logs and the query history together, and test that a removed user loses access on the next sign-in attempt.

Connector permission sync records

Onyx answers only from documents the user can already see in the source application, so assessors will ask for proof that permission sync works inside the enclosure. Keep the connector configuration for each source such as SharePoint, OneDrive, Confluence or Jira, the sync run logs, and test results from accounts with different access levels. Document any source where permissions are not synced and the compensating control, such as restricting that connector to a limited group. Re-run the tests after each connector or source change.

Update and patch records

Air-gapped systems fall behind unless updates are brought in deliberately. Keep a dated log of each release brought across the boundary, the checksum or signature verification performed on it, the approval record and the test results before production use. Onyx publishes frequent releases, and its Helm chart is versioned separately, so record both. Ollama and vLLM also ship releases on their own schedules, so track each component's version and the date it was applied in a single register.

Software bill of materials for mirrored images

Every container image and package mirrored into the enclosure needs an inventory. A software bill of materials lists the components, versions and licenses in each image, including Onyx, its database and index services, Redis, the model servers and their Python dependencies. Pair it with the licenses: Onyx Community Edition is MIT licensed, but code in ee directories falls under the Onyx Enterprise License, so the inventory should flag which components came from those directories. Generate the inventory at the time of mirroring and store it with the image digests.

Where Copilot and open-source options differ on control and audit

Copilot's work-based chat depends on Microsoft cloud services, so it cannot run inside a network with no outbound path. Microsoft Learn states that work-based Copilot Chat grounds answers in content the user's Microsoft Entra account can access and requires a Microsoft Copilot license, while web-based chat only shows internet results. That grounding and the license model are the reasons a disconnected network needs a different architecture. Before you rule out Copilot for an enclave, confirm with Microsoft which tenant, region and endpoints your licensing and sovereignty terms would require, and whether any feature you need works without them.

With Onyx, the document index, database and processing run inside your own boundary, and Onyx documents an air-gappable deployment built from Docker, Kubernetes, Helm or Terraform. Model inference can sit on Ollama or vLLM on your hardware. Permissions come from the source systems through Onyx's permission sync, and query history auditing is listed among its enterprise features, so you can keep your own logs. Check that the Enterprise Edition features you need, such as RBAC, are included in the edition you license.

The control you gain comes with duties the vendor would otherwise carry. Glean's customer-hosted model, for comparison, still leaves upgrades, patching and monitoring with Glean, and in a self-hosted stack those tasks fall to your team. Plan for offline update handling, including how you pull Onyx, Ollama and vLLM releases into the enclave and test them before promotion, and for log retention and access review for the audit trail. Ask any implementation partner to write down who patches each component, who reviews query logs and how often, before you commit to the architecture.

How DeployOpen plans and deploys an air-gapped assistant

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For an air-gapped assistant, the work starts with a written scope that defines which sources, models and users are in play, then moves through build, testing and handover.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We inventory which internal sources, such as SharePoint, Confluence or Jira, the index must reach inside the network.
We confirm the model hosting path, whether Ollama or vLLM, and the hardware the client already owns or must procure.

How we build

We deploy Onyx with its index, database and processing services inside the client's environment using Docker, Kubernetes, Helm or Terraform.
We configure connectors and permission sync so answers only draw on documents each user can already see.
We set up SSO, provisioning and access controls, and put the model endpoints behind a reverse proxy that allowlists only user-facing routes.

How we hand over

We document the architecture, data flows, configuration keys and the offline update procedure the client's team will run.
We prepare evidence for the controls in scope so the client's auditors can assess the deployment, since DeployOpen does not issue audit reports or certifications.
We walk the client's operators through backup, restore, model updates and monitoring before the handover is closed.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Security testing of the application, APIs and infrastructure can be scoped separately, including red teaming of the assistant.
Upgrades are planned against the release cadence of each component, and changes are tested in a staging copy first.