How to Configure Tabnine for On-Premises Code Completion Without Source Code Leakage

Enterprise engineering teams operating under strict regulatory mandates—such as defense contractors, financial institutions, and healthcare providers—face a critical dilemma: developers want the productivity boost of AI code completion, but security teams cannot permit proprietary source code to leave internal firewalls or be retained for third-party model training.

Tabnine solves this conflict by offering an on-premises and air-gapped enterprise deployment architecture. By hosting the Tabnine Kubernetes cluster within your private network or Virtual Private Cloud (VPC), code completions execute entirely behind your perimeter. When combined with Tabnine's zero data retention policy and permissively trained foundational models, enterprise teams eliminate the risk of intellectual property leakage while delivering real-time coding assistance across development teams.

High-Level Architecture: How Isolation Works

In a standard SaaS AI coding assistant, code snippets, surrounding files, and workspace context travel over the public internet to third-party cloud APIs. Tabnine Enterprise replaces this cloud dependency with a self-hosted, private service architecture.

+-----------------------------------------------------------------------+
| Enterprise Intranet / Air-Gapped Network Perimeter                   |
|                                                                       |
|  +-----------------------+           +-----------------------------+  |
|  | Developer Workstations|           | Internal Tabnine K8s Cluster|  |
|  | - VS Code Plugin      |  HTTPS    | - Ingress Controller (TLS)  |  |
|  | - JetBrains Plugin    |---------->| - Model Inference Pods (GPU)|  |
|  | - Eclipse / CLI Tools |  (mTLS)   | - PostgreSQL & Redis State  |  |
|  +-----------------------+           | - Enterprise Context Engine |  |
|                                      +-----------------------------+  |
|                                                    |                  |
|                                      +-------------v---------------+  |
|                                      | Private Internal Storage    |  |
|                                      | - Custom Fine-Tuned Models  |  |
|                                      | - Local Image Registry      |  |
|                                      +-----------------------------+  |
+-----------------------------------------------------------------------+
                           X [Blocked Egress]
                      Public Internet / External APIs

The enterprise setup relies on three core security boundaries:

1. Network Boundary: The entire Tabnine inference cluster runs inside your Kubernetes environment. All client-to-server traffic uses internal HTTPS. In air-gapped deployments, egress firewall rules block all outbound internet traffic.
2. Data Boundary: Tabnine operates under a strict Zero Data Retention (ZDR) policy. Inference requests are processed ephemerally in GPU memory to generate completions and are immediately discarded. Prompts are never written to disk or pooled for model retraining.
3. Intellectual Property (IP) Boundary: Tabnine’s foundational models are trained exclusively on open-source code with permissive licenses (such as MIT, Apache 2.0, and BSD-2/3-Clause). This prevents copyleft licensing contamination (such as GPL infection) in generated suggestions.

Prerequisites and Infrastructure Requirements

Before deploying Tabnine Enterprise in an on-premises or air-gapped cluster, ensure your infrastructure meets the following baseline requirements:

Step 1: Deploying the Private Tabnine Cluster

Enterprise platform teams can deploy Tabnine using official Helm charts provided during onboarding.

1. Mirror Container Images (Air-Gapped Environments)

For strictly isolated environments without outbound web access, pull the required images from Tabnine's registry in a staging area and push them to your internal registry:

# Authenticate to Tabnine container registry
docker login registry.tabnine.com -u <ORGANIZATION_KEY> -p <ORGANIZATION_SECRET>

# Pull core inference and service images
docker pull registry.tabnine.com/tabnine/enterprise-server:latest
docker pull registry.tabnine.com/tabnine/inference-engine:latest
docker pull registry.tabnine.com/tabnine/context-engine:latest

# Retag for your internal Harbor / Artifactory registry
docker tag registry.tabnine.com/tabnine/enterprise-server:latest internal-registry.corp.internal/tabnine/enterprise-server:latest
docker tag registry.tabnine.com/tabnine/inference-engine:latest internal-registry.corp.internal/tabnine/inference-engine:latest
docker tag registry.tabnine.com/tabnine/context-engine:latest internal-registry.corp.internal/tabnine/context-engine:latest

# Push to internal repository
docker push internal-registry.corp.internal/tabnine/enterprise-server:latest
docker push internal-registry.corp.internal/tabnine/inference-engine:latest
docker push internal-registry.corp.internal/tabnine/context-engine:latest

2. Configure the Helm Values File

Create a tailored values.yaml file configuring database connections, resource allocations, and network isolation:

global:
  domain: "tabnine.corp.internal"
  imageRegistry: "internal-registry.corp.internal/tabnine"
  airGapped: true

ingress:
  enabled: true
  className: "nginx"
  annotations:
    cert-manager.io/cluster-issuer: "internal-ca-issuer"
    nginx.ingress.kubernetes.io/proxy-body-size: "64m"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "120"
  hosts:
    - host: "tabnine.corp.internal"
      paths:
        - path: /
          pathType: Prefix
  tls:
    - secretName: tabnine-tls-cert
      hosts:
        - "tabnine.corp.internal"

database:
  postgresql:
    host: "postgres-ha.database.svc.cluster.local"
    port: 5432
    database: "tabnine_enterprise"
    user: "tabnine"
    existingSecret: "tabnine-db-credentials"
  redis:
    host: "redis-master.database.svc.cluster.local"
    port: 6379
    existingSecret: "tabnine-redis-credentials"

telemetry:
  enabled: false
  externalEndpoint: "" # Disables logs-gateway.tabnine.com

inference:
  resources:
    limits:
      nvidia.com/gpu: 2
      cpu: "16"
      memory: "64Gi"
    requests:
      nvidia.com/gpu: 2
      cpu: "8"
      memory: "32Gi"

3. Install the Cluster

Deploy Tabnine into your cluster namespace:

helm upgrade --install tabnine-enterprise ./tabnine-helm \
  --namespace tabnine \
  --create-namespace \
  -f values.yaml

Once running, verify that ingress routing and GPU worker nodes report healthy statuses:

kubectl get pods -n tabnine -l app.kubernetes.io/part-of=tabnine
kubectl get ingress -n tabnine

Step 2: Administrative Hardening and SSO Integration

Once the server endpoint (https://tabnine.corp.internal) is operational, the platform team must configure administrative guardrails via the Tabnine Admin Console.

1. Enforce Corporate Single Sign-On (SSO)

Navigate to Authentication & Security in the Tabnine Admin Console:

• Configure SAML 2.0 or OIDC integration with your identity provider (such as Okta, Microsoft Entra ID, or PingFederate).
• Restrict registration strictly to authorized corporate identity groups.
• Set session timeouts and enforce multi-factor authentication (MFA) upstream.

2. Disable External Telemetry

In air-gapped and high-security VPC modes:

• Verify that outgoing metrics to logs-gateway.tabnine.com are toggled off.
• Forward audit logs and resource usage statistics exclusively to internal SIEM collectors (such as Splunk, Elastic, or Datadog private agents).

3. Model Governance and Codebase Context

• Base Models: Select the protected, open-weight enterprise models vetted for permissive licensing.
• Context Engine Permissions: If connecting internal Git repositories to build RAG-grounded suggestions, configure read-only service tokens with granular repository scoping. All indexed embeddings remain stored in your local database and storage volumes.

Step 3: Configuring Developer IDEs

To direct code completion queries to the internal server rather than public endpoints, developers or desktop management tools must configure IDE extensions.

Visual Studio Code Configuration

Method A: Graphical Interface Setup

1. In the VS Code Extensions Marketplace, install the Tabnine Enterprise extension (or install the .vsix package distributed through your internal artifact repository).
2. Upon startup, VS Code prompts: "Tabnine: Please set your enterprise server URL."
3. Enter your private URL: https://tabnine.corp.internal.
4. Click Sign In, which opens your default browser to authenticate against internal SSO.

Method B: Managed Policy (settings.json)

For automated workstation rollout via MDM (Jamf, Microsoft Intune, or Ansible), push the following setting to user or workspace configuration files:

{
  "tabnine.cloudHost": "https://tabnine.corp.internal",
  "tabnine.receiveBetaChannelUpdates": false
}

JetBrains IDEs (IntelliJ IDEA, PyCharm, WebStorm, GoLand)

Air-Gapped Plugin Installation

In environments without internet access to the JetBrains Marketplace, host the plugin descriptor internally:

1. Open Settings / Preferences (Ctrl+Alt+S or Cmd+,).
2. Go to Plugins > Gear Icon ⚙ > Manage Plugin Repositories....
3. Add your internal update repository URL:

   https://tabnine.corp.internal/update/jetbrains/updatePlugins.xml
   

4. Search for Tabnine Enterprise and click Install.

Configuring Server Host in JetBrains

1. Go to Settings > Tools > Tabnine.
2. Locate the Server URL input field.
3. Input https://tabnine.corp.internal.
4. Save and restart the IDE when prompted. Authenticate through the browser SSO prompt.

Corporate Proxy and Internal CA Certificates

Enterprise networks that inspect TLS traffic or run private root CAs may encounter SSL handshake errors in IDE plugins. Prevent certificate verification failures by configuring trusted certificates:

• For VS Code (Node.js runtime): Set the operating system environment variable:

  export NODE_EXTRA_CA_CERTS="/etc/ssl/certs/corporate-root-ca.pem"
  

• For JetBrains (JVM runtime): Import the corporate root certificate into the IDE trust store under Settings > Tools > Server Certificates > Accept non-trusted certificates automatically (or import the PEM into the JVM cacerts keystore).

CLI and Automation Environments

For build scripts, CI runners, or local automation scripts, define the global environment variable:

export TABNINE_HOST="https://tabnine.corp.internal"

Leakage Prevention: Architectural Safeguards

To satisfy legal, compliance, and cybersecurity audits, enterprise architects must prove how data is isolated. Tabnine prevents leakage through four structural mechanisms:

+-------------------------------------------------------------------------------+
|                        Code Leakage Prevention Layers                         |
+-------------------------------------------------------------------------------+
| 1. Physical / Network Isolation                                               |
|    - Cluster runs inside LAN / VPC; egress blocked by firewalls              |
|    - Offline air-gapped support eliminates API exfiltration vectors          |
+-------------------------------------------------------------------------------+
| 2. Ephemeral In-Memory Inference                                              |
|    - Prompts processed exclusively in volatile GPU memory                     |
|    - Zero Data Retention: prompt context discarded immediately post-response |
+-------------------------------------------------------------------------------+
| 3. Model Training Isolation                                                   |
|    - Customer code is never ingested into Tabnine global models               |
|    - Local fine-tuning and embeddings remain in private enterprise volumes    |
+-------------------------------------------------------------------------------+
| 4. IP Cleanliness & Permissive Licensing                                      |
|    - Base models trained solely on MIT, Apache 2.0, and BSD repositories      |
|    - Immune to copyleft GPL contamination risks                               |
+-------------------------------------------------------------------------------+

1. In-Memory Processing Without Disk Persistence

When a developer types in their IDE, the local plugin gathers immediate context (current file tokens, cursor position, adjacent imports). This payload is transmitted over internal HTTPS to the on-premises inference pod. The model computes next-token logits in volatile GPU VRAM and streams back candidate completions. The moment the connection closes, the prompt context is cleared from memory. No source code is appended to log files or persisted to disk.

2. Elimination of Training Contamination

Many public coding tools collect customer completions to fine-tune future model iterations. Tabnine contractually and technically guarantees that customer code is never used to train Tabnine's foundational models. If an enterprise opts to create a customized model tailored to its private coding patterns, training occurs exclusively on dedicated compute resources inside the organization's infrastructure, and the resulting weights are stored solely in internal storage.

3. Intellectual Property and License Safety

Even when code does not leak outward, external models can inject proprietary code snippets with restrictive licenses into your repositories. Tabnine mitigates this inbound legal risk by training foundational models only on permissive open-source licenses. Enterprise codebases remain safe from unexpected GPL copyleft obligations.

Deployment Models Compared: Which Should You Choose?

Recommendations for Enterprise Teams

• Choose Private VPC if your organization already operates workloads in AWS, Azure, or Google Cloud and requires network isolation without the capital expenditure of purchasing physical server hardware.
• Choose On-Premises Air-Gapped if your development workloads handle classified data, trade secrets, critical infrastructure code, or operate in air-gapped test labs where network egress is strictly forbidden.
• Leverage Standard SaaS only if corporate compliance permits outbound ephemeral processing over TLS and your primary goal is minimizing operational maintenance.

Operational Verification Checklist

Before opening Tabnine to all engineering teams, complete this verification checklist:

1. Network Egress Audit: Verify via network monitoring (e.g., tcpdump or VPC flow logs) that no traffic leaves developer workstations or inference nodes to public IP addresses during active completion requests.
2. DNS & TLS Validation: Ensure developer machines resolve tabnine.corp.internal to internal ingress IPs and that TLS handshakes complete without untrusted certificate warnings.
3. SSO Enforcement: Confirm that non-authenticated developers cannot query the inference API and that new accounts require identity provider approval.
4. Telemetry Suppression: Inspect Kubernetes logs to verify that outbound reporting to logs-gateway.tabnine.com is disabled.
5. IDE Configuration Standard: Push tabnine.cloudHost settings to all developer machines via central device management or standard workspace configurations.

By pairing private Kubernetes infrastructure with disciplined IDE management and Tabnine’s zero-retention architecture, enterprise engineering organizations can safely deploy AI code completion at scale without exposing their proprietary intellectual property.

References

• Tabnine Deployment Options
• Tabnine Private Installation Guide
• Tabnine System and Hardware Requirements
• Tabnine Pricing and Enterprise Plans
• Tabnine AI Assistant for Software Developers