Air-Gapped AI Coding Environments That Keep Proprietary Logic Inside Your VPC
Run coding AI models inside your VPC to keep proprietary logic off the internet.
A self-hosted alternative to v0 and other hosted app-building tools for internal apps needs three things inside the VPC, namely model inference, an agent harness, and network controls that block unapproved traffic.
Why the default AI coding tool deployment is a data exfiltration event by design
With the default cloud-hosted deployment, an AI coding assistant sends source code, prompts, and repository context over the public internet to servers that the vendor controls. That is where the model runs. This means proprietary algorithms, unreleased product logic, and regulated data can leave with a completion request. The transfer is the architecture doing its job, even when that job conflicts with the company’s security requirements.
Turning off a setting cannot relocate the model. Keeping the request inside requires a change in where the system runs, which a stronger promise about what happens after data leaves cannot do. That choice is becoming more practical as open-weight coding models narrow the quality gap and GPU hardware costs fall. At the same time, stricter data-residency mandates make it harder to ignore where those requests go.
Which teams actually cannot use cloud-hosted AI coding tools — and why the legal exposure differs by framework
Defense contractors, healthcare software teams, and financial institutions do not face one interchangeable compliance rule. The applicable framework determines the restriction, so a regulated label alone does not establish that all cloud use is prohibited. HIPAA, for example, calls for Business Associate Agreements and the right safeguards to protect Protected Health Information. The plan is part of the distinction. OpenAI and Anthropic offer HIPAA-compliant BAAs for enterprise and qualifying API tiers, while ChatGPT Free/Plus/Business and Claude Free/Pro/Team do not qualify for use with PHI.
A startup with a proprietary algorithm has a trade secret to protect. Sending its core logic to a cloud model can expose that trade secret, even when no rule bans it. Yet for most software teams, VPC-local inference is overkill. A managed service such as AWS Bedrock or Azure OpenAI in a dedicated tenant with a BAA can achieve most regulatory gains at lower operational cost. Full containment serves the narrower group whose requirements rule out that middle ground too.
The three-layer architecture that keeps every token inside the VPC
The first layer is inference serving, which includes the model weights and the API the coding assistant calls. Both must sit inside the network boundary. The second layer is the agent harness and orchestration, which reads the codebase, issues tool calls, runs tests, and writes files. Installing an extension locally does not show where those decisions happen. If its orchestration depends on a cloud control plane, the agent loop is still outside.
The third layer is the private network that contains the other two and enforces their access rules. Picture the model server and agent runtime inside a boundary that rejects unapproved outbound connections. Each layer needs its own containment test. An internal model cannot compensate for external orchestration, and internal orchestration cannot compensate for a public model gateway. A license server or telemetry endpoint can also break the air-gap, even when the main application installs on-premises.
Choosing an inference engine: the Ollama-versus-vLLM decision and what it costs in production
Ollama and vLLM address different operating settings, from a developer workstation to a multi-tenant production cluster. Both have an OpenAI-compatible API, so the coding assistant or agent harness can use the same client interface in either environment. That makes “develop on Ollama, deploy on vLLM” practical. The engine choice still sets throughput limits, the security audit surface, and GPU requirements.
Ollama’s smaller footprint is useful when containment and simplicity take priority. There is less code to audit, fewer CVEs to track, and a simpler dependency surface. Hardware need not always be new. NVIDIA T4 (16 GB) or V100 (32 GB) GPUs can run quantized models effectively for smaller teams. CPU-only inference through llama.cpp is technically possible, but too slow for interactive use.
Production economics require a wider view than the GPU quote. Electricity, cooling, high-speed networking gear, and the labor needed to manage Kubernetes, driver updates, and CUDA stability all belong in the procurement estimate. Those costs do not disappear after installation. The right engine therefore depends on the expected workload and the team’s ability to operate it, rather than a universal claim that local inference is cheaper.
Which open-weight coding models are deployable without legal exposure
CodeGeeX4’s weights use the CodeGeeX4 License (a separate license from Apache 2.0), and commercial users must register and comply with attribution terms. Military use is prohibited. More broadly, an “open” model may have commercial-use restrictions or jurisdiction-based prohibitions that disqualify it from a particular environment. Teams should pull the LICENSE file from the model’s release, inspect its carve-outs, and have legal approve it before regulated deployment. That review applies to each model version within a model family.
Which agent tools run the full coding loop inside your own VPC?
The agent layer is where a local interface can conceal a remote dependency. An extension may run on a developer’s machine while control-plane work, tool calls, and context retrieval pass through a cloud service. Cursor’s official changelog describes self-hosted machines that keep tool execution inside the customer’s network, but inference and the agent loop remain in Cursor’s cloud.
Coder Agents runs the full control plane in-cluster, while open-source harnesses such as Continue and Cline depend on the team’s endpoint configuration for privacy. Their clients introduce no cloud dependency, but an incorrectly configured model endpoint does. For a team building an agent-assisted coding environment inside its own AWS or Azure VPC, the relevant comparison is where the complete agent loop runs. An open-source client paired with an external model is not a self-contained alternative merely because its source is available.
Commercial platforms that offer documented, procurement-ready air-gap tiers
Commercial air-gap tiers serve teams that need vendor support, guarantees about data written into a contract, and an audit trail, and would otherwise have to put the stack together themselves. Their scope still needs close reading. Qodo’s deployment documentation limits air-gapped support to specific Git integrations, including GitHub Enterprise, GitLab Self-Managed, Bitbucket Data Center, and Gerrit. Devin Desktop’s self-hosted enrollment is closed to new customers, which also limits its usefulness as a procurement option.
Tabnine’s Trust Center lists GDPR, ISO/IEC 27001, and SOC 2 compliance documents. Cognition’s live compliance table marks IL5 as “In Process” for Devin Desktop while showing ITAR support, so broader claims about related extensions do not establish the Desktop product’s current status. A certification label is not an architecture diagram. Before signing, the team should obtain documented offline modes for the license server, telemetry endpoint, model update pipeline, and control plane, as well as the applicable hardware requirements and contractual retention terms.
CI/CD and build pipelines that reach no external registry at build time
Contained inference and orchestration do not make a delivery pipeline private. A build that reaches an external package registry still depends on a connection outside the boundary. The reference pattern uses self-hosted Gitea as the internal source of truth, Tekton as the pipeline engine, Kaniko for in-cluster image builds, Harbor as the internal container and artifact registry, and ArgoCD for GitOps sync. Each component runs inside the network. The build must also find its dependencies there.
The key is one dependency-baked builder image per language. Otherwise, an internal pipeline is private in location only. KubeRocketCI documents a Tekton and Argo CD option that keeps the full loop internal, from trigger and pipeline through build, scan, image push, and GitOps sync. Its air-gapped setup uses an internal Git server and registry.
Existing CI/CD investments can change the choice of tooling. Jenkins self-hosted and GitLab Self-Managed both provide full network and compute control. They also bring higher maintenance overhead than a Tekton/ArgoCD stack for teams without a dedicated platform team. The constraint stays the same across these options. Where a pipeline runs does not change the rule against accessing an external registry at build time.
Network controls that make the air-gap verifiable, not just claimed
For security teams, the deployment needs controls that operate independently of the application’s promises. Default-deny egress is the foundation, with every permitted outbound connection requiring an explicit allowlist entry. Unapproved connections are dropped at the network boundary. A containment policy can log an outbound transfer for later review, while an enforced boundary prevents it.
The agent’s sandbox needs restrictions at the process level too. Seccomp profiles, dropped Linux capabilities, and read-only filesystem mounts outside approved paths constrain what a prompt-injected agent can do. Network controls alone are not the whole defense. The agent should inherit the developer’s existing identity-provider permissions so it can read only the repositories and files the developer can access. Without those limits, the AI layer opens a path to privilege escalation even if no data leaves the VPC.
Inference logs, tool calls, file changes, test output, and PR summaries should stream into the organization’s existing security and audit systems rather than remain only in the AI platform’s logging layer. Model weights need a separate integrity check. SHA-256 verification before deployment, followed by read-only mounting at the OS level, addresses modification between transfer and serving. If the weight file changes, the hash fails and deployment halts.
The tradeoffs that determine whether full air-gap is the right answer for a given team
Full air-gap is worth its burden only when the threat model or regulatory requirement demands it. Costs work out differently for a small team that uses the system little and a group that keeps GPUs busy throughout the working day. Utilization changes the answer. On-premises hardware can cost less when it stays busy, while cloud GPU rentals can cost less when usage is low. That comparison should be based on the expected token volume, even if the team generally prefers to own its equipment.
Local open-weight models, even strong coding-specific models, still do less well than leading proprietary API models on complex multi-file reasoning tasks. That gap can change the value of the whole deployment. Teams should test their actual workloads. A legally deployable model that fits the hardware still has to perform the work.
Teams also have to handle serving-framework updates and ML platform engineering on top of the infrastructure work already described. A smaller team has less room to absorb it. For a team that needs a BAA but not full physical air-gap, the managed-cloud route avoids much of that burden, though at a premium over standard API pricing. For teams that require complete containment, that convenience does not resolve the underlying restriction.
Sourcegraph’s documentation says Cody’s default provider uses Cody Gateway, so installing the surrounding platform internally does not by itself establish local inference. Limits on commercial support and closed enrollment can also leave teams with fewer ways to use a tool that seemed to fit, before deployment even starts. “Self-hosted” is a deployment label that still requires a layer-by-layer threat model.
