Self-hosted GitHub Copilot alternative for air-gapped networks

Why a self-hosted GitHub Copilot alternative for air-gapped networks changes the deployment model

For a defense, finance or industrial team whose source code cannot reach any hosted service, the question is not which assistant has the best suggestions but where the model runs and how it gets updated. The open-source option that fits this constraint is Tabby running on isolated GPU servers, with models and plugin updates carried in through a controlled import path. Everything inference-related stays inside the enclosure, so prompts, code context and completions never leave the network. GitHub Copilot is a hosted service, and this page does not claim it can be configured for air-gapped use. Ask GitHub directly, in writing, whether any deployment of Copilot can operate with no outbound connection to its services, and what telemetry, authentication and model-serving traffic would still need to leave your network. Get that answer before you compare anything else, because it decides whether Copilot is a candidate at all.

Moving to a self-hosted model changes who owns each part of the stack. Your team becomes responsible for the GPU hosts, the model files, the Tabby server, the authentication path and every update. Tabby's README describes a self-contained server that needs no DBMS or cloud service, which keeps the attack surface small, but the models are your responsibility to obtain, verify and store. Plan a sealed transfer procedure with named roles: one group downloads and hashes model and container artifacts on a connected staging host, a second group reviews and scans them, and a third imports them into the enclosure. Plugin packages for VS Code, Vim and IntelliJ need the same path, and you should confirm with the Tabby project how each release is published so you can verify it. The Tabby license is a second decision point. Its LICENSE file places content in the ee/ directory under a separate license and keeps everything else under Apache 2.0, so confirm which features your enclosure needs fall inside the open core before you build around them.

What an air-gapped constraint requires from the coding assistant

An air-gapped network removes the outbound path that hosted assistants depend on, so every part of the coding assistant must run, authenticate and update inside the boundary. The cards below set out the requirements that follow from that constraint and what to verify in your own environment before a pilot.

No outbound code or prompt traffic

Source code, prompts and completions must never leave the isolated segment, so the assistant and its model server need no route to a vendor cloud. Tabby is self-contained and needs no DBMS or cloud service, which makes this a configuration check rather than a product feature. Verify it with egress tests from the GPU host and the developer subnet, and confirm that editor plugins do not call home beyond the Tabby server address. A blocked default route is the simplest proof of isolation.

Models stored and loaded locally

Every model file, including the completion model and the chat model, must be downloaded once, verified and placed on storage the GPU server can read without internet access. The Tabby README's Docker example uses StarCoder-1B for completion and Qwen2-1.5B-Instruct for chat, so both need to be staged in advance. Ask who approves model artifacts, how their checksums are recorded, and how a model is removed when a license or security review fails.

Authentication through the internal directory

Developers should sign in with the same directory accounts they already use, so access ends when their directory account is disabled. Tabby added LDAP authentication in v0.24.0 (February 5, 2025) and GitLab SSO in v0.12.0 (June 6, 2024). Confirm which of these matches your identity store, check that the chosen Tabby plan includes it, and test offboarding by disabling a test account.

Updates that cross the boundary by controlled transfer

Plugin, server and model updates arrive on removable or transfer media after scanning, not by pulling from the internet. Tabby's latest stable release is v0.32.0, and pre-release builds appear on the releases page, so the approved version must be pinned and the change record kept. Define who downloads, hashes and signs each package, which versions are allowed, and how a rollback is performed if an update breaks completions.

Admin logging and access control

Administrators need to see who requested completions, who changed model or user settings, and which accounts can reach the GPU server. Tabby's Enterprise plan adds the group management that controls this, and the Apache-2.0 core covers the basics. Confirm what audit records Tabby writes, where they are shipped inside the enclave, how long they are kept, and whether a separate log host can receive them.

Network isolation of the inference layer

If the model is served with vLLM rather than Tabby's own runtime, the serving layer needs its own controls. vLLM's security docs state that inter-node traffic is insecure by default, and the --api-key option does not cover every endpoint, so a reverse proxy that allowlists only user-facing routes is advised. Confirm that metrics and health routes are reachable only by the monitoring host, and test that unlisted routes return errors from outside it.

Which open-source components fit an isolated GPU environment

Tabby is the component developers actually touch in the IDE. Its README describes it as a self-hosted AI coding assistant and an on-premises alternative to GitHub Copilot, self-contained with no need for a DBMS or cloud service. Its LICENSE file places everything outside the ee/ directory under Apache 2.0, while content in ee/ falls under a separate license in ee/LICENSE, and third-party components keep their own terms.

Core license: The Apache 2.0 core covers the server features most teams start with, so confirm which features your plan actually needs.
The ee/ caveat: Any feature you use from ee/ is governed by a different license, so have legal review it before rollout.
Plugins and API: Editor plugins exist for VS Code, Vim and IntelliJ, and the OpenAPI interface supports integration with cloud IDEs.
GPU support: The README lists consumer-grade GPU support, and its Docker example uses StarCoder-1B for completion and Qwen2-1.5B-Instruct for chat.
Identity: LDAP authentication arrived in v0.24.0 and GitLab SSO in v0.12.0.

Confirm with Tabby which features sit under ee/ for your chosen version, and test the sign-in path against your directory before the pilot.

vLLM is an Apache-2.0 inference and serving engine that can split a model across GPUs with tensor parallelism inside a node and pipeline parallelism across nodes. Its server exposes OpenAI-compatible endpoints, so tools written for the OpenAI API can point at it. The network and authentication behavior is where isolated deployments need the most care.

Multi-node traffic: The security docs state that communication between nodes is insecure by default, without authorization or encryption, so isolate those nodes on a dedicated network.
API key limits: The --api-key option protects only the /v1, /v2, /inference and /cohere paths, not /metrics, /health or /invocations, so do not rely on it alone.
Reverse proxy: The docs recommend a reverse proxy that allowlists only the endpoints meant for users.
Observability: Prometheus metrics at /metrics cover request counts, throughput, latency and KV cache use.
Hardware: NVIDIA CUDA, AMD ROCm and Intel XPU are supported, and the release cadence is frequent, so pin a version after testing.

Verify which endpoints your proxy exposes by scanning the server from the developer network before go-live.

How each option meets the constraint and where it falls short

This table compares Tabby, vLLM, Ollama and Open WebUI on the factors that matter when source code must stay on isolated networks: license, offline operation, authentication, GPU support, IDE coverage and operational burden. Read each row as a question to confirm in your own environment, since most gaps sit in the surrounding work rather than in the software itself. The main takeaway is that Tabby is the only option here that covers IDE completion directly, while the others supply serving or chat layers that you still have to assemble around it.

Factor	Tabby	vLLM and Ollama (serving layer)	Open WebUI (chat interface)
License	Apache 2.0 for the core, with content under the ee/ directory on its own license	vLLM is Apache-2.0; Ollama is MIT. Confirm each model's license separately	Open WebUI License, a BSD-3-Clause style license with a branding clause; confirm terms before rebranding
Offline operation	Self-contained, with no DBMS or cloud service required per its README; confirm model files are staged in advance	Ollama runs locally and does not see prompts by design; vLLM serves weights from local storage	Can run entirely offline per its docs; confirm no plugin or update check calls out
Authentication	LDAP arrived in v0.24.0 and GitLab SSO in v0.12.0; check which plan includes them	Local Ollama API has no authentication by default; vLLM --api-key does not cover every endpoint	Needs its own user model and SSO setup; confirm what is supported in your build
GPU support	Supports consumer-grade GPUs; the README example uses --gpus all and CUDA	vLLM runs on NVIDIA CUDA, AMD ROCm and Intel XPU; Ollama uses the llama.cpp backend	Not a model server; GPU needs sit with the backend it connects to
IDE coverage	VS Code, Vim and IntelliJ plugins, and a JetBrains Marketplace listing	No IDE plugins; applications must call the OpenAI-compatible endpoints	No IDE plugins; web chat only
Operational burden	One server with models, plus updates you must move in through your own approved path	vLLM needs a reverse proxy, network isolation for multi-node runs and metrics collection	Adds a second service to patch, back up and monitor alongside the model server
Where it falls short	Model quality depends on the models you load; confirm hardware sizing with the vendor	Not a coding assistant on its own; you must build the client integration	Does not complete code in the editor; useful for chat and documentation only

What a hosted assistant cannot offer on an isolated network

A hosted assistant cannot run inside an isolated network, and that is the core constraint for a team whose source code must never leave the building. ChatGPT Enterprise runs only as an OpenAI-hosted service. The controls OpenAI documents for it are SAML SSO, admin retention settings, regional data residency and SOC 2 Type 2 audits, and none of them is a customer-hosted deployment option. OpenAI's data residency stores in-scope content at rest in a selected region and can add inference residency in some regions, but a region is still a location within OpenAI's cloud. Residency answers where data sits. It does not answer whether the service can operate with no outbound path at all, and a compliance lead should not treat the two as the same control. Ask any hosted vendor to state in writing which traffic must leave the network for the service to function, and which of those flows can be disabled.

Customer-hosted options narrow the gap but do not close it. Glean's Customer Hosted model still leaves Glean responsible for infrastructure and application management, including upgrades, patching and monitoring. That is a useful operating model, but an isolated environment must confirm how vendor-driven upgrades arrive, who approves them, and whether monitoring telemetry can be fully contained. For Microsoft 365 Copilot, work-based Copilot Chat grounds answers in content that the user's Microsoft Entra account can access and requires a Microsoft Copilot license, so the assistant depends on cloud identity and service-side grounding. Web-based chat only shows internet results. In a network with no cloud identity tenant or internet route, that dependency is the design problem itself. Your security team should map each hosted assistant's identity, grounding and update paths against the isolation boundary before any pilot.

How to deploy Tabby and load models without outbound access

This sequence takes a Tabby server from isolated GPU hardware to a tested internal service, with every image, model file and plugin brought in through a controlled path and verified with egress blocked. The result is a coding assistant that answers developers without any request leaving the enclosure.

Size and provision isolated GPU hosts
The infrastructure team selects GPU servers for the enclosure, sized against the completion and chat models the team intends to run, and confirms that the hosts have the NVIDIA driver and container runtime needed for the GPU flags Tabby expects. Ask the hardware vendor and the Tabby documentation to confirm supported GPU models and driver versions, since these are not fixed by the README alone. Done means each host boots, sees its GPUs from inside a test container, and has no default route to the internet.
Mirror the Tabby image and model files inside
Staff pull the Tabby container image and the model files on a staging network that has access to public sources, scan them under your own policy, then transfer them through an approved media or cross-domain path into the enclosure. Keep checksums with each artifact so the import can be verified later. Confirm the license of every model you bring in, because Tabby's LICENSE file keeps third-party components under their own terms. Done means the image loads into the internal registry and the model files sit on the server's local storage with matching checksums.
Configure the server with the Docker GPU flags
The platform engineer starts the Tabby container using the Docker example from the README, which passes --gpus all and --device cuda and loads StarCoder-1B for code completion and Qwen2-1.5B-Instruct for chat. For a fully offline host, point the model path at the local copy and disable any step that tries to fetch models at startup. Store the configuration in version control and record the image digest. Done means the server starts, reports the GPU as in use, and returns a completion for a test prompt from the host itself.
Connect LDAP or GitLab sign-in
The identity team connects Tabby to the directory your engineers already use. The README notes LDAP authentication arrived in v0.24.0 and GitLab SSO in v0.12.0, so confirm the version you run supports the method you need before planning the change. Test with a standard user, a disabled user and a group that should not have access. Done means only authorized accounts receive tokens, and the access results match the directory's group membership.
Place a reverse proxy in front of model endpoints
The network team puts a reverse proxy in front of Tabby and any model-serving process, such as vLLM or Ollama, so that only the endpoints developers need are reachable from the engineering network. Ollama binds to 127.0.0.1 port 11434 by default and its local API does not require authentication, so keep it on loopback or behind the proxy. For vLLM, the security docs say the --api-key option does not cover every route and recommend a reverse proxy that allowlists user endpoints. Done means a request to any unlisted path is refused and the model server cannot be reached from outside the host.
Install IDE plugins from an internal source
Developer tooling staff distribute the VS Code, Vim and IntelliJ plugins from a source inside the enclosure, such as an internal extension mirror or a file share your change control approves. Point each plugin at the internal server address and token issuer. Confirm with the plugin release notes which versions match your server version before rollout. Done means a pilot developer on an isolated workstation receives completions from the internal server and the IDE shows no failed requests to external hosts.
Test with network egress blocked
The security team blocks outbound traffic from the Tabby hosts and the workstations at the firewall, then runs functional tests for completion, chat, sign-in and plugin behavior. Capture firewall and host logs during the run and check for any denied or unexpected outbound connection, including attempts to download models or telemetry. Document each finding and rerun the tests after fixes. Done means the tests pass with no outbound connection attempts recorded, and the evidence is filed with the system's change record.
Plan multi-node isolation for vLLM
If the design later spans several GPU nodes with vLLM, the platform team follows vLLM's security guidance: communication between nodes is insecure by default with no authorization or encryption, so each node must sit on an isolated network. Ask your architect to confirm the parallelism mode, Ray or the built-in multiprocessing backend, and the metrics exposure at /metrics before adding nodes. Done means the cluster design is reviewed against that guidance and the inter-node network is documented as isolated.

How model and plugin updates enter the enclosure safely

The update path into an isolated network is a change process, not a download. Every Tabby server release, vLLM release, Ollama build or model weight file should pass through the same steps: review the release notes on the external side, verify the checksum or signature the organization has defined for that artifact type, scan it, move it across an approved transfer method, and record the version in change control before anything is deployed. Confirm the exact rules with your security office, including who signs off on each step and which artifact types need which checks. Tabby publishes releases through its GitHub releases page, and nightly and alpha builds appear there too, so your intake policy should say which channel is allowed in.

Cadence is what makes this workable. vLLM ships new minor releases about every two weeks, and Tabby and Ollama also release frequently, so waiting for each release to arrive ad hoc will leave the enclosure drifting. Set a scheduled update window, for example monthly, and batch the releases you choose to adopt during that window. Decide in advance which components are pinned, which are updated on the window, and which security fixes can trigger an out-of-cycle import. Pin the exact vLLM and Tabby versions in your deployment files so an upgrade is a deliberate change, and keep the previous artifacts available so you can roll back.

Transfer is the step most likely to need a decision outside IT. Whether the path is removable media that is scanned and logged, or a one-way data diode, depends on your accreditation boundary and the classification of the enclosure. Ask your security office which method applies, who approves each media item, and how transfers are logged. Model weights are large, so confirm storage capacity on the internal side and the verification method for model files before they are loaded. Plugin updates for VS Code, Vim and IntelliJ need the same intake path, and the plugin build should be tested against the internal Tabby version before developers receive it.

Questions teams ask before running Tabby on an air-gapped network

What drives the cost of running Tabby on an air-gapped network?

The main cost drivers are GPU hardware, staff time and the scope of implementation. Tabby's Apache-2.0 core and its Community plan carry no license fee for up to 5 users, so the spend is on the servers, the people who install and operate them, and any paid plan you add. GPU servers are a one-time purchase or a recurring lease depending on your procurement model. Staff time recurs for patching, model updates and user support. Ask any implementation partner for a quote built from a written scope that lists hardware, integrations, hardening and handover separately.

Does Tabby Community or Team suit our number of developers?

Tabby's pricing page lists Community as free and open source for up to 5 users, and Team at $19 per seat per month for up to 50 users. Enterprise is custom priced with unlimited users and adds enhanced security and group management. For a team of 5 or fewer, Community covers the basic seat count. Above that, Team is listed for up to 50 users, and at 50 or more seats you would need the Enterprise conversation. Confirm current terms with Tabby before committing, because pricing pages change, and check which features you need, such as LDAP or GitLab sign-in, against each plan.

How long does an air-gapped Tabby deployment take?

No timeline is fixed by the product, so the duration depends on the work around it. The main factors are how many GPU servers you have, whether models must be transferred in through a controlled path, how many identity and IDE integrations are needed, and how long your security review and change approvals take. A pilot with one team usually moves faster than a rollout to the whole engineering organization. Ask for a milestone plan in the written scope that separates infrastructure readiness, model import, identity integration, pilot and production handover.

Can our internal team deploy Tabby on an isolated network alone?

A capable platform team can deploy Tabby with Docker, but an air-gapped setup adds work that is easy to underestimate. You need to stage container images and model weights offline, configure GPU drivers, put access controls in front of the server, and create a repeatable process for updates. Tabby's README shows a Docker example with --gpus all and --device cuda, which is a starting point rather than a hardened configuration. Assess whether your team has GPU operations experience, a documented change process and time for testing. Many organizations split the work, with internal staff owning operations and an outside team covering the build and handover.

What do we need to provide before the engagement starts?

Prepare three inputs. First, a network diagram showing the isolated segment, the GPU hosts, the developer subnets and the boundaries where files cross in or out. Second, your identity source, such as LDAP, GitLab or another system, and the group structure that should map to Tabby access. Third, an approved model list that names the completion and chat models your security team accepts, along with their licenses and the path by which they are imported. Tabby's README uses StarCoder-1B for completion and Qwen2-1.5B-Instruct for chat as examples, so confirm which models your policy allows before any build.

How are Tabby and model updates handled without internet access?

Updates arrive through a controlled path you define. Tabby publishes stable and pre-release builds on its GitHub releases page, where v0.32.0 is listed as the latest stable release, so track versions and review release notes before importing them. Each update should be tested on a staging copy, its container image and checksums verified, and then moved across the boundary by an approved process. Model weights and any plugin packages follow the same route. Ask your provider how the update cycle, rollback plan and test evidence are documented, and whether the work is covered by a retainer.

What can a hosted assistant not offer on an air-gapped network?

A hosted assistant sends prompts and code context to a vendor-operated service, which cannot run inside a network with no outbound path. GitHub Copilot is a hosted service, so it cannot meet a requirement that source code never leaves an isolated segment. A self-hosted Tabby server keeps completions, chat and indexed repositories on GPUs you control, and its OpenAPI interface can integrate with internal tools. The trade-off is that you own model selection, hardware sizing, patching and the quality of results on your own models, so confirm those responsibilities with your security and operations leads before the pilot.

Evidence assessors and security teams ask for under this constraint

An air-gapped Tabby deployment is only as credible as the records behind it. The six items below are what assessors and internal security teams typically ask to see, and each one shows how the isolated network, its model files and its updates were controlled. DeployOpen prepares this evidence for your assessment, but it does not issue audit reports or certifications; independent auditors and certification bodies do.

Network boundary documentation

A diagram and written description of the isolated segment: which GPU servers, developer workstations and IDE hosts sit inside it, which ports are open between them, and which routes to the internet or corporate network are absent. Vendor material on vLLM notes that node-to-node traffic in multi-node deployments is unauthenticated and unencrypted by default and must sit on an isolated network, so assessors will expect this boundary to be shown explicitly. Ask your network team to confirm it against live firewall rules, not only the design.

Inventory of model files and licenses

A register of every model Tabby loads, such as the StarCoder-1B completion model and Qwen2-1.5B-Instruct chat model named in the Tabby README, with the file hash, source, download date and license terms for each. Because models are copied in by hand, this register is what proves what is running. Record the license for each model separately from Tabby's own Apache 2.0 terms, since third-party components keep their own licenses.

Update import log

A dated record of each package, container image, model file and plugin that crossed the transfer point, with who approved it, which scan or checksum verified it, and where it was installed. This is the controlled path the air gap depends on. Tabby publishes nightly and alpha builds after its stable release, so the log should show that only approved versions were imported and that pre-release builds were excluded unless a named owner accepted them.

Access control and admin audit records

Evidence of who can reach the Tabby server and its administration interface, how accounts are created, and how changes to users and settings are logged. Tabby's LDAP sign-in arrived in v0.24.0 and GitLab SSO in v0.12.0, so confirm which method your build uses and export its user list. Ask the vendor or your own tests to confirm whether admin actions are logged in a form your assessors can retrieve.

Configuration baselines

Versioned settings for the Tabby server, the inference engine, container runtime and host operating system, stored with the approved release and reviewed after every change. For vLLM, the baseline should include whether the --api-key option is set and whether a reverse proxy allowlists only user-facing endpoints, because the docs warn that the key alone does not cover every route. Keep the baseline in version control so drift can be detected.

Vendor license files used

A copy of each license file that governs a component in the stack, kept with its version and the date it was retrieved. For Tabby, this means the LICENSE file and the ee/LICENSE terms if any ee/ code is deployed, since that directory carries separate terms. Also keep the license for the inference engine and any open-core tool you add. Assessors and procurement teams will ask which files apply, so the record should say which edition each deployed component is.

How DeployOpen deploys Tabby under an air-gapped constraint

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own networks, including air-gapped ones. For a Tabby deployment, the work starts with a written scope that fixes the isolated network, GPU hardware, models and update path before anything is installed.

How we scope

We document which network segments, developer groups and IDEs will use Tabby and which must stay outside its reach.
We inventory GPU servers, storage, identity sources and the models you plan to keep on local disk.
Engagements are fixed-scope, so deliverables, the update path and the handover items are agreed in writing before work starts.

How we build

We install Tabby on isolated GPU servers, load locally stored models and verify completion and chat with your IDE plugins.
We connect the identity sources you already run and test sign-in against your own directory, not a hosted login service.
We move model files, plugin packages and container images through a controlled transfer path and check each artifact before it is used.

How we hand over

You receive configuration, network diagrams, the update procedure and records of what was tested in your environment.
We document how evidence for access control, logging and change management can be collected for your assessors.
We explain what DeployOpen prepares for compliance assessments, while independent auditors and certification bodies issue any reports.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Upgrades to Tabby, models and plugins follow the same controlled transfer path, with a test run before production.
Security testing of the deployed service and its endpoints can be scoped separately and repeated as your environment changes.