Tabnine in a Private Codebase: Getting Useful Suggestions Without Leaking IP

Your team is evaluating AI code completion, and then legal sends a reminder about data residency requirements. Suddenly the conversation shifts from "how do we set this up" to "are we even allowed to use this." It's a fair concern — pasting proprietary business logic into a cloud AI is a genuine risk, and the defaults on most tools don't protect you.

Tabnine is one of the few AI coding assistants built with this problem in mind. It ships with options for fully local inference, private cloud deployment, and team-trained models. But none of that works out of the box without deliberate configuration. This guide walks you through what you actually need to do.

What You'll Learn

• How Tabnine handles your code by default and what that means for IP
• How to run the model entirely on your own hardware
• How to train a team model on your private repos without exposing code externally
• Which IDE settings reduce accidental data leakage
• How to verify your configuration is doing what you think it is

Prerequisites

This guide assumes you're using Tabnine for Teams or Tabnine Enterprise. The free tier runs a smaller model with fewer privacy controls. You'll also need admin access to your Tabnine organization console and, for local deployment, a machine with enough RAM to run a local model (8 GB minimum, 16 GB+ recommended for decent latency).

Understanding What Tabnine Sends by Default

Before you configure anything, you need to know what the default behavior actually is. When you install Tabnine and start typing, it sends a context window around your cursor to its inference endpoint. That context typically includes the current file, sometimes adjacent open files, and any snippets it uses for completion scoring.

For most SaaS products, this is fine. For code that contains trade secrets, customer data references, proprietary algorithms, or anything covered by an NDA, this is a problem. Tabnine's privacy policy says it doesn't use your code to train its base models without explicit opt-in, but "not used for training" and "never leaves your network" are different guarantees. Make sure you know which one you need.

The three deployment modes Tabnine offers are:

• Cloud mode — inference happens on Tabnine's servers. Fastest setup, least control.
• Local mode — inference runs entirely on your machine. No code leaves your system.
• Self-hosted / private cloud — you run Tabnine's server on your own infrastructure. Best of both worlds for teams, but requires setup.

Running Tabnine Locally

Local mode is the simplest way to guarantee nothing leaves your machine. The tradeoff is that the local model is smaller than the cloud model, so suggestions may be less impressive on complex patterns. For most day-to-day completions — boilerplate, repetitive patterns, common library calls — the difference is smaller than you'd expect.

To enable local mode in VS Code, open the Tabnine plugin settings and find Tabnine: Cloud. Disable it. The plugin will download a local model binary the first time you do this, which takes a few minutes depending on your connection. After that, all inference is local.

In JetBrains IDEs (IntelliJ, PyCharm, etc.), go to Settings → Tabnine and look for the Run Tabnine locally option. Enable it, restart the IDE, and the status bar indicator will show you which mode is active.

You can verify local mode is active by temporarily disabling your network connection and checking that completions still appear. If they do, you're running locally.

Setting Up a Self-Hosted Tabnine Server for Your Team

If you have a team and need everyone to benefit from the same private model, a self-hosted deployment is the right path. Tabnine Enterprise ships as a Docker image you can run inside your VPC or on-premises infrastructure.

The basic setup looks like this:

# Pull the Tabnine Enterprise image (your account must have Enterprise access)
docker pull tabnine/tabnine-enterprise:latest

# Run with the required environment variables
docker run -d \
  --name tabnine-server \
  -p 5555:5555 \
  -e TABNINE_LICENSE_KEY=your_license_key_here \
  -v /data/tabnine:/tabnine-data \
  tabnine/tabnine-enterprise:latest

Once the server is running, point each developer's IDE plugin to it. In VS Code, set the Tabnine: Cloud Url setting to your server's internal address (e.g., http://tabnine.internal:5555). In JetBrains IDEs, the equivalent setting is under Tabnine → Enterprise → Server URL.

From this point on, all inference traffic goes to your server, not Tabnine's cloud. Your network team can verify this with a packet capture or firewall log.

Training a Team Model on Your Private Repos

This is where Tabnine goes beyond generic code completion. You can train a model specifically on your team's codebase so it learns your conventions, internal library APIs, naming patterns, and architecture decisions.

Training happens through the Tabnine admin console. You connect your version control system — GitHub, GitLab, Bitbucket, or a self-hosted Git server — and select which repositories to include. The training process runs on your infrastructure (or Tabnine's isolated tenant environment if you're on the managed Enterprise tier with tenant isolation).

A few things to get right before you kick off training:

• Exclude secrets and credentials — run a secrets scan on your repos before connecting them. Tools like trufflesecurity/trufflehog or gitleaks can find anything that slipped through. Training a model on a repo containing API keys is a bad day waiting to happen.
• Choose repos deliberately — don't just include everything. Start with your most actively developed repos in the primary language your team uses. More data isn't always better if it comes with a lot of dead or legacy code that teaches bad patterns.
• Set a retraining schedule — as your codebase evolves, the model should too. Most teams retrain weekly or biweekly.

After training completes, developers on the team automatically get suggestions influenced by your codebase patterns — without any code leaving your defined perimeter during inference.

Configuring IDE Policies to Reduce Accidental Leakage

Even with local or self-hosted inference, there are IDE-level settings worth locking down, especially if you manage a team where not everyone thinks about these things.

In VS Code, you can push workspace settings to restrict Tabnine behavior for everyone who opens your repo:

{
  "tabnine.experimentalAutoImports": false,
  "tabnine.cloud": false,
  "tabnine.useProxySupport": false
}

Commit this to .vscode/settings.json in your repo. It won't override user settings in all cases, so pair it with documentation that explains what settings developers should have and why.

For JetBrains, you can distribute a shared IDE settings profile through the Settings Sync feature or via a .idea directory in your project. The same principle applies — document the expected config and give developers a way to verify they're compliant.

If your organization uses device management (MDM, Intune, Jamf), you can also push IDE configuration via policy so there's no room for individual variation.

Common Pitfalls

Assuming "no training" means "no transmission." Tabnine's default cloud mode still sends code for inference even if it doesn't use that code to update its base model. These are separate concepts. If your concern is data leaving the building, you need local or self-hosted mode regardless of training policy.

Forgetting about context window breadth. Tabnine uses nearby files to build better suggestions. If a developer has a file open that contains a database password or a hardcoded secret, that content may be included in the context sent to the inference endpoint. This is another reason to run a secrets scan across all open files in your dev environment and enforce .env file hygiene.

Training on a repo that has a broad contributor base. If contractors or third parties have committed code to a repo, check your agreements before including it in training. You may be feeding someone else's IP into your model.

Not validating the server URL after migration. When you switch from cloud to self-hosted, the IDE plugin may cache the old endpoint. Always verify the active server in the plugin status panel after making changes.

Neglecting model refresh cycles. A team model trained on six-month-old code starts suggesting deprecated internal patterns. Automate retraining or put it on a calendar so it actually happens.

Verifying Your Privacy Posture

Configuration is only useful if you can confirm it's working. Here are three practical checks:

1. Network inspection — use a proxy like mitmproxy or your corporate firewall logs to confirm that Tabnine traffic from developer machines hits your internal server address, not *.tabnine.com cloud endpoints.
2. Offline test — disconnect a developer machine from the internet entirely. Completions should still appear at full speed if you're on a local or self-hosted setup. Any degradation suggests some fallback to cloud is happening.
3. Admin console audit — Tabnine Enterprise's admin console shows active connections and inference routing. Check it periodically and after any plugin updates, since updates can sometimes reset settings.

Wrapping Up

Getting Tabnine to work well in a private codebase isn't complicated, but it does require making deliberate choices instead of accepting defaults. Here's what to do next:

• Decide which deployment mode you need based on your actual risk model — local for individual developers, self-hosted for teams with strict data residency requirements.
• Run a secrets scan on any repositories you plan to connect for team model training before you connect them.
• Set up and validate the self-hosted Docker deployment, then point your team's IDE plugins at it.
• Commit workspace IDE settings to your repos so everyone on the team inherits a consistent baseline configuration.
• Schedule a recurring task to retrain the team model as your codebase evolves and to audit network logs quarterly.

Once the infrastructure is in place, the day-to-day experience is seamless — developers get context-aware suggestions that reflect your actual codebase, and your IP stays where it belongs.