Tabnine's air-gapped option still needs one outbound connection

The setup

Tabnine is one of the older AI code-completion products, predating the current chatbot-driven coding-assistant wave, and its architecture documentation leads with a choice most competitors treat as an afterthought: SaaS, virtual-private-cloud, or fully on-premises. The on-premises path runs the whole Tabnine cluster, inference service included, on a Kubernetes cluster the customer controls, inside the customer's own data center. That is the setup this note tracks: what standing up that on-prem cluster requires, and what stays inside the building once it is running.

What the documents show

The private-installation documentation states this option is offered to Tabnine Enterprise customers as either a VPC deployment on AWS, GCP or Azure, or a genuinely on-premises one, deployable in a fully air-gapped environment. Tabnine's own staff have no access to a customer's private-installation servers once deployed, though its professional-services team works with the customer to set it up and push updates. The hardware-requirements page lists minimum specs by user count, from 64 CPUs and 10 TB of SSD storage for up to 200 users, up to 96 CPUs and 32 TB for over 2,000, Tabnine's own published minimum, not an independent benchmark.

The friction

The same requirements page lists a required outbound connection to Tabnine's own container registry, at a named host and port, plus an optional connection to a logs gateway. Nothing explains how a deployment marketed as fully air-gapped satisfies that documented requirement to reach an external registry, a gap between the marketing claim and the infrastructure list for anyone planning a genuinely offline install. There is a separate constraint on model choice: for private installation, the architecture page states only the vendor's own Tabnine Protected model is currently available, while a related hybrid tier can additionally reach outside models such as Claude, ChatGPT or Gemini. On-prem buys code privacy at the price of a shorter model list than a cloud subscriber gets, an editorial read of the trade-off.

What changed in the work

For a team barred from sending code to a third-party cloud, the documented on-prem path is the difference between using an AI coding assistant and not using one. It does not support a claim that this removes all external dependency: registry access, an update cadence and vendor involvement stay part of the picture even after the cluster sits inside the firewall. Whether the hardware burden is worth it depends on team size and threat model, which the vendor's pages do not evaluate; that trade-off is kept or dropped case by case, not settled by the documentation.

• Does the compliance requirement actually demand air-gapping, or would a VPC deployment already satisfy it?
• Who on the team will own the Kubernetes cluster and its storage once it is running?
• Which model list does the chosen tier actually unlock, and does it match what the team needs day to day?

Tabnine's own documents make a specific case for on-premises AI coding as a real option, not a marketing slide, but the same documents are the source of its costs: a named external host, a restricted model roster, and a hardware bill that scales with headcount.