Telemetry in self-hosted AI tools: what vLLM, Hugging Face and vector databases send

Which parts of a private LLM stack send data out

Several components of a self-hosted LLM stack report usage data by default. vLLM sends anonymous hardware, model and engine data to its developers until VLLM_NO_USAGE_STATS=1 or DO_NOT_TRACK=1 is set; Hugging Face libraries, the Chroma and Qdrant vector databases, n8n and NeMo Guardrails do the same, each with its own switch. The fields that vLLM, Chroma, Qdrant and NeMo Guardrails document contain no prompts or answers, but a data-protection or air-gap requirement usually asks for no unplanned outbound connection at all.

Telemetry is one class of outbound traffic. Version checks, model downloads and cloud features are others, and the same settings often cover them. This article goes through each component as documented in October 2026, with the switch that turns it off and the parts that need a firewall instead. Installing a stack without internet access is the subject of our guide to an air-gapped LLM server, and inbound exposure that of securing a GPU server.

Each project's documentation or source code, read on 24 October 2026; details and caveats in the sections below.

vLLM usage stats: what is collected and how to disable it

vLLM's documentation states that "vLLM collects anonymous usage data by default". The current field list is in vllm/usage/usage_lib.py. It covers the cloud provider, number and type of processors, total memory, platform, CUDA runtime, number, type and memory of the GPUs, the model architecture, the vLLM version and an anonymous ID, with the values of five vLLM environment variables. The example record in the documentation, taken from v0.4.0, also lists engine settings: data type, tensor-parallel size, block size, GPU memory utilisation, quantisation, KV cache data type, LoRA, prefix caching and others. Model names and prompts are not among the fields.

The code sends the first report from a background thread and then a heartbeat with the ID and a timestamp every ten minutes (time.sleep(600)). The receiving server is VLLM_USAGE_STATS_SERVER, by default https://stats.vllm.ai in envs.py of v0.32.0. A local copy is written to ~/.config/vllm/usage_stats.json, and the documentation suggests tail on that file to see what is collected.

The documentation lists three ways to opt out:

• export VLLM_NO_USAGE_STATS=1
• export DO_NOT_TRACK=1
• an empty file ~/.config/vllm/do_not_track

The exact value matters. In envs.py, VLLM_NO_USAGE_STATS counts only when it equals "1", and VLLM_DO_NOT_TRACK, which falls back to DO_NOT_TRACK, likewise only when it equals "1". By our reading of the code, DO_NOT_TRACK=true leaves vLLM reporting. Hugging Face accepts "true", and the Open WebUI image sets DO_NOT_TRACK=true, so a value copied from one service's configuration to the vLLM container does not do what it seems to. Set VLLM_NO_USAGE_STATS=1 in the environment of every vLLM container or systemd unit. The file in the home directory works only for the user vLLM runs as, and inside a container it has to be in the image or on a mounted volume.

A vLLM deployment across several servers uses Ray. Ray's documentation states that "Starting in Ray 1.13, Ray collects usage stats data by default (guarded by an opt-out prompt)". RAY_USAGE_STATS_ENABLED=0 is the variable NVIDIA sets for it in its NIM images, so set it on every Ray node as well.

Hugging Face libraries and the Hub

Hugging Face describes its libraries' telemetry in the huggingface_hub documentation: "By default, some data is collected by HF libraries (transformers, datasets, gradio,..) to monitor usage, debug issues and help prioritize features." Each library defines what it reports, and HF_HUB_DISABLE_TELEMETRY=1 disables telemetry globally. DO_NOT_TRACK is listed as equivalent. Boolean variables count as true for 1, ON, YES or TRUE in any case.

Telemetry is only part of the traffic. Downloading a model from the Hub is a connection by design, and even with a cached file hf_hub_download sends a request to check for a newer version. HF_HUB_OFFLINE=1 stops that: "no HTTP calls will be made to the Hugging Face Hub", and only cached files are used. A logged-in host sends its token with every request by default; HF_HUB_DISABLE_IMPLICIT_TOKEN=1 limits it to write calls. The hf command line tool checks PyPI for a new release at most once a day, which HF_HUB_DISABLE_UPDATE_CHECK=1 stops.

On a production server that serves models from a local path, HF_HUB_OFFLINE=1 is the setting that covers the most, since telemetry, version checks and downloads all go to the Hub.

Open WebUI and its vector store

Open WebUI's Dockerfile sets SCARF_NO_ANALYTICS=true, DO_NOT_TRACK=true and ANONYMIZED_TELEMETRY=false, and writes an all-zero ID into Chroma's telemetry file. These are image settings. A Python installation of Open WebUI does not get them, so set them yourself there. Open WebUI as the staff front end of a private LLM is described in our private ChatGPT alternative.

The application has a version update check, ENABLE_VERSION_UPDATE_CHECK, on by default. OFFLINE_MODE=true turns it off and also sets HF_HUB_OFFLINE=1, which means embedding and speech models must already be in the cache or the image. The non-CUDA image downloads its default embedding and Whisper models at build time. OpenTelemetry export is off by default; when switched on, its default endpoint is http://localhost:4317, a collector you run yourself.

Community sharing, ENABLE_COMMUNITY_SHARING, is on by default; it is the precondition of the High-severity advisory GHSA-vpq8-f445-hcq7 of 27 September 2026, fixed in Open WebUI 0.11.4. Switch it off unless staff are meant to publish to Open WebUI's community site, as our article on Open WebUI security hardening explains.

We set these variables when we install the platform on servers we supply; send us the components your stack runs, and our team replies with the settings and the outbound connections each one needs.

Vector databases: Chroma and Qdrant

Chroma's telemetry page states "We use Posthog to store and visualize telemetry data." It collects the Chroma version and environment details, use of embedding functions and, for collection commands, an anonymised collection UUID and item counts; "We do not collect personally-identifiable or sensitive information", such as usernames, hostnames, file names or environment variables. Set ANONYMIZED_TELEMETRY to False in the server environment, or anonymized_telemetry in the client settings.

Qdrant's open-source container "collects anonymized usage statistics from users in order to improve the engine by default": system information such as CPU, RAM and disk type, performance timings and counters, and critical error reports. Each start generates a random UUID that is not stored, and names and URLs are hashed. IP addresses, collection names and stored data are not collected. Turn it off with QDRANT__TELEMETRY_DISABLED=true, telemetry_disabled: true in the configuration file or the --disable-telemetry flag. The local /metrics and /telemetry endpoints stay available. Qdrant Cloud has collection disabled by default. Our vector database comparison covers the choice between them.

Workflow and application tools: n8n, Dify, NeMo Guardrails

n8n's isolation page opens with "By default, a self-hosted n8n instance sends data to n8n's servers." To stop it, set N8N_DIAGNOSTICS_ENABLED, N8N_VERSION_NOTIFICATIONS_ENABLED and N8N_TEMPLATES_ENABLED to false, and leave EXTERNAL_FRONTEND_HOOKS_URLS, N8N_DIAGNOSTICS_CONFIG_FRONTEND and N8N_DIAGNOSTICS_CONFIG_BACKEND empty. Our guide to n8n with a local LLM covers the rest of the setup.

Dify's console checks CHECK_UPDATE_URL, by default https://updates.dify.ai, for newer versions; the documentation says leaving it empty turns the check off and suits air-gapped environments. Error reporting to Sentry is off until a DSN is set. Our article on Dify with a local LLM covers the model connections.

NVIDIA's NeMo Guardrails library "collects anonymous telemetry" about deployment patterns, sends "periodic heartbeats" to NVIDIA and keeps a local copy in usage_stats.json under ~/.config/nemoguardrails. Prompts, completions, credentials, model names and IP addresses are excluded. NEMO_GUARDRAILS_NO_USAGE_STATS=1, DO_NOT_TRACK=1 or a do_not_track file in its configuration directory stop it, and the setting has to be in place before the library starts, because a running heartbeat thread does not stop. Guard models themselves are sized in our guide to guardrail models.

Ollama and NVIDIA NIM containers

Ollama's FAQ states: "Ollama runs locally. We don't see your prompts or data when you run locally." For its cloud models, prompts are processed by Ollama's service, and it collects "basic account info and limited usage metadata". OLLAMA_NO_CLOUD=1, or disable_ollama_cloud set to true in ~/.ollama/server.json, makes Ollama local-only, without cloud models and web search; after a restart the log shows Ollama cloud disabled: true. The automatic updates the FAQ describes are those of the macOS and Windows apps.

NVIDIA's environment variable reference for NIM for LLMs 2.0.4-pb6, updated on 17 September 2026, gives DO_NOT_TRACK and VLLM_NO_USAGE_STATS the default 1 in PB6 images and states that these images also set HF_HUB_DISABLE_TELEMETRY=1 and RAY_USAGE_STATS_ENABLED=0. That statement is for the PB6 images; for any other NIM version, read its own reference. A NIM container downloads its model from NGC at start with NGC_API_KEY, unless NIM_DISABLE_MODEL_DOWNLOAD is set and the cache under NIM_CACHE_PATH, by default /opt/nim/.cache, is already filled.

Egress filtering as the backstop

Settings are per component and per version: a new release can add a report, and a container started without the variable reports again. A firewall that denies outbound connections from the GPU servers and the application hosts, with exceptions only for your package mirror, registry and model store, catches what a setting misses. Its log of denied connections shows which component tried to reach which host, and that list is worth reviewing after every upgrade.

Before the platform goes live, start each service once with its final configuration on a host whose outbound connections are logged, and leave it running for more than ten minutes, long enough for a vLLM heartbeat to have been sent. Every connection in the log should go to a host you planned for, such as your registry or model store. Repeat the test after each upgrade of vLLM, Open WebUI or the vector database, since defaults can change between releases.

Our summary of the documentation cited above.

Vendors describe these reports as anonymous. Whether usage data of this kind counts as personal data, and whether its transfer needs an entry in your records of processing, is for your data-protection officer to assess; our article on a DPIA for an internal LLM covers the assessment, and shadow AI policy and controls the tools staff install themselves. For foreign access to data held by providers, see our article on the CLOUD Act and EU data residency.

What we supply

You can buy the servers for this stack from us: our team sizes the configuration to your workload and budget and replies within one business day. We build AI servers to order, assembled and tested before delivery, with the operating system, drivers, CUDA and a container runtime installed on request. Setting up vLLM, Open WebUI, retrieval and the platform with the opt-outs in place is part of our Private AI/ML service. Ask us for the outbound-connection list of the components you plan to run.

FAQ