Starting with Vendure v3.6.0, the framework collects anonymous usage telemetry to help the core team understand how Vendure is being used. This data helps prioritize development efforts and identify common deployment patterns.
Telemetry collection is designed with privacy as a core principle. No personally identifiable information (PII) is ever collected, and the data is anonymized before transmission.
An initial telemetry event is sent shortly after the server starts up. After that, a lightweight "heartbeat" event is sent roughly every 24 hours for as long as the server keeps running (a small random delay is added to each heartbeat so that many servers restarted together do not all report at the same instant). Each event contains the same categories of data, collected fresh at send time.
The following data is included in each telemetry event:
A randomly generated UUID that identifies your Vendure installation. This ID is:
crypto.randomUUID() (not derived from any system information).vendure/.installation-id in your project root3.6.0)20.10.0)linux x64, darwin arm64, win32 x64)NODE_ENV environment variable value (e.g., production, development)node, bun, or deno)npmpnpmyarnbununknownts-nodeThe type of database being used:
postgresmysqlmariadbsqlite@vendure/email-plugin, @vendure/dashboard)node_modulesRecord counts for core Vendure entities, reported as ranges rather than exact numbers:
| Range | Description |
|---|---|
0 | No records |
1-100 | 1 to 100 records |
101-1k | 101 to 1,000 records |
1k-10k | 1,001 to 10,000 records |
10k-100k | 10,001 to 100,000 records |
100k+ | More than 100,000 records |
For custom entities, only the count of custom entity types is collected (not their names), plus an aggregate record count range.
Range-bucketed counts (never exact numbers) describing the order mix: orders that have been placed, orders that are still active, draft orders, orders placed in the last 30 days, and a breakdown by order type (Regular, Seller, Aggregate only — arbitrary values are never reported).
The number of distinct language codes and distinct currency codes configured across all channels. These are simple counts — the actual language/currency codes are not sent.
A non-sensitive summary of the configuration is collected. This includes the class names of certain well-known built-in strategies, along with booleans, enums and counts derived from the config — never raw configuration values, secrets or credentials:
LocalAssetStorageStrategy, S3AssetStorageStrategy)Booleans and short enums summarizing security-relevant configuration — for example whether GraphQL introspection, the API playground or API debug output are enabled, whether a wildcard CORS origin or trustProxy is in use, the configured token method(s) and cookie secure/sameSite flags, whether auth is disabled or email verification required, and whether the superadmin credentials are still the built-in defaults. Only the flags are sent — never the actual origins, secrets, or credential values.
For single-strategy configuration fields, telemetry records the config path of any strategy that differs from the framework default (e.g. orderOptions.orderCodeStrategy). Only the dotted path is sent — the class name of a custom strategy is deliberately not collected, so project-specific naming cannot leak.
The following data is explicitly not collected:
Telemetry data helps the Vendure team:
Telemetry can be disabled by setting an environment variable:
Or:
Telemetry is automatically disabled in CI environments. The following CI systems are detected:
Travis CI, CircleCI, GitHub Actions, GitLab CI, Jenkins, Bitbucket Pipelines, Azure Pipelines, AppVeyor, Drone, Buildkite, TeamCity, AWS CodeBuild, Heroku CI, Netlify, and Vercel. Any environment setting the generic CI environment variable is also detected.
https://telemetry.vendure.io/api/v1/collectArchitecture reviews, custom plugin work, migrations, ongoing support. Get a hand from the team that builds Vendure.
Talk to the team