Telemetry

The varlock CLI collects anonymous telemetry data about usage to help us understand how the tool is being used and to make it better. Participation is optional, and you may opt-out at any time.

What We Collect

We track general usage information, and the environment in which varlock is being used. Specifically we collect anonymous information about:

• Which varlock command is being invoked
• Which framework integration invoked the CLI (if any), such as Vite, Next.js, or Astro: official @varlock/* package name and version only
• Which plugins are installed in the project: @varlock/* plugin names and versions are sent as-is; third-party plugin names are hashed (SHA-256) and versions are omitted
• Anonymous, non-sensitive usage attributes that official @varlock/* plugins report about how they are used (for example which authentication mode is active, or whether a feature is enabled): booleans, short enum strings, and counts only; collected for official plugins only and strictly sanitized (never secret values, item references, hostnames, or paths)
• Anonymous schema feature signals when a project is loaded: for example root settings like @redact, cache mode, safe resolver/decorator identifiers in use, and data source type counts (not config keys, values, file paths, or error messages)
• Whether the env graph was loaded (graph_loaded) and a coarse error category when the run failed (error_code: e.g. parse_error, plugin_error, schema_error, validation_error, resolution_error, load_error): no error messages or file paths
• Version information for varlock and Node.js
• JavaScript package manager in use (if detectable from lockfiles or runtime env): npm, pnpm, yarn, bun, or deno only
• General system/machine information
• Anonymous user, project, and org IDs (see Anonymous IDs below)
• A random per-run ID, so the events from a single command can be grouped together. It is generated fresh in memory each time the CLI starts, is never written to disk, and cannot be used to link one run to another

We will never collect any of your config files or environment variables.

How Events Are Sent

Sending telemetry never delays a command. The CLI does not wait for the network before printing its output or exiting, so the time varlock load or varlock/auto-load takes is the same with telemetry on or off.

Events are sent in the background while a command runs. Long-running commands such as varlock run or varlock proxy run confirm delivery while they run and nothing else happens.

If a command finishes before delivery is confirmed (as varlock load usually does), the CLI hands the events off and exits immediately:

1. A detached copy of the CLI is started as varlock --flush-telemetry, with the pending events passed in its environment (__VARLOCK_TELEMETRY_EVENTS) and its stdin/stdout/stderr closed, so it never holds open the pipes or terminal of whatever started varlock. You may briefly see it in ps output. Nothing is written to disk.
2. That process sends the events in one request (giving up after 10 seconds) and exits. It records no telemetry of its own (VARLOCK_TELEMETRY_DISABLED is set on it) and never starts another process.

Each event carries a random id, so if one reaches us twice (once from the original process and once from the handoff) the duplicate can be recognized and dropped.

This is the same approach used by the Vercel, Netlify, Expo, and Prisma CLIs and by next dev. If you would rather varlock never start that background process, opt out using one of the methods below: when telemetry is off, no events are recorded and nothing is spawned.

How to Opt Out

You can opt out of analytics in three ways:

Using the CLI

Run the following command to permanently opt out:

npm

npm exec -- varlock telemetry disable

pnpm

pnpm exec -- varlock telemetry disable

bun

bunx varlock telemetry disable

vlt

vlx -- varlock telemetry disable

yarn

yarn exec -- varlock telemetry disable

standalone binary

varlock telemetry disable

This will create/update a configuration file saving your preference at $XDG_CONFIG_HOME/varlock/config.json (defaults to ~/.config/varlock/config.json).

You may re-enable telemetry by running varlock telemetry enable

Using an Environment Variable

You can also opt out temporarily by setting the VARLOCK_TELEMETRY_DISABLED environment variable:

export VARLOCK_TELEMETRY_DISABLED=true

This could be set in a specific terminal session, while running a specific command, in a Dockerfile, or in a CI/CD pipeline.

varlock also honors DO_NOT_TRACK, a convention shared by many command line tools such as Homebrew, Deno and Turborepo. The convention is described at donottrack.sh. Setting it opts you out of every tool that supports it, so you do not need to remember a separate variable for each one:

export DO_NOT_TRACK=1

With a project config file

You can also opt out at the project level by creating a .varlock/config.json file in your project root with the following content:

my-app/.varlock/config.json

{
  "telemetryDisabled": true
}

Anonymous IDs

We never track who you are. To count distinct users and projects, events include a few IDs:

• User ID: a random UUID generated on first run and saved in your user config file. It is not derived from anything about you or your machine.
• Project ID: a SHA-256 hash of your repo’s host/owner/repo (from the git remote, or from CI env vars like GITHUB_REPOSITORY), so all clones and CI runs of the same repo share one ID.
• Org ID: a SHA-256 hash of host/owner.
• Git host: e.g. github.com, only for well-known public hosts. Anything else is reported as self-hosted.

Project and org IDs are not salted, since a salt would give every user a different ID for the same repo. This means someone who already knows a repo or org name could hash it and check for a match, but the IDs reveal nothing on their own. We do not attempt to reverse them and only use them to count and group usage.

Privacy

• All analytics data is anonymous
• No personal or sensitive information is collected
• Data is only used to improve the product
• You can opt out at any time
• Events are sent to our own endpoint on Cloudflare, and a sample is forwarded to PostHog, a privacy-friendly analytics platform

Data Usage

The anonymous usage data helps us:

• Understand which features are most used
• Identify areas for improvement
• Make informed decisions about future development
• Prioritize bug fixes and new features

If you have any questions about our analytics or privacy practices, please start a discussion on GitHub.