Question regarding the new Enterprise-only "Analytics Opt-out" feature

[alphanull]

While reviewing the new pricing model, I noticed that “Analytics Opt-out” is listed as an Enterprise feature.

I also found the TELEMETRY configuration option in the Directus documentation, which states that anonymized telemetry is enabled by default and sends data to telemetry.directus.io.

What I’m struggling to find is a clear explanation of what exactly is being collected.

Could somebody from the Directus team clarify:

• What data is transmitted to telemetry.directus.io?
• What fields are included in the payload?
• Are collection counts included?
• Are user counts included?
• Are flow counts included?
• Are any license-related metrics included?
• Is telemetry required for license validation?
• What exactly does the Enterprise-only “Analytics Opt-out” feature disable?

As someone building self-hosted solutions for clients and making explicit commitments regarding privacy and data minimization, I need to know exactly what leaves the server and what doesn’t.

I searched the pricing page, documentation, and FAQs but couldn’t find a detailed explanation.

Any clarification would be appreciated.

[alphanull]

Since no one from the Directus team has responded, we went ahead and answered our own questions by reading the v12 RC1 source code directly. I’m sharing the findings here because we suspect many community members — especially self-hosters and agencies — may not be fully aware of the implications. All file paths refer to the public repository at tag v12.0.0-rc.1; one finding comes from the published npm package @directus/license@0.2.0, which is the exact version pinned in the repo’s pnpm-workspace.yaml.

---

What Is Actually Being Transmitted

Every 6 hours (and once on startup), Directus sends a POST request to https://telemetry.directus.io/v1/metrics containing:

Field	Value
url	Your configured PUBLIC_URL (your production domain)
project_id	Unique installation identifier
version	Directus version
database	Database type
admin_users	Admin user count
app_users	App user count
api_users	API user count
roles	Role count
flows	Active flow count
dashboards	Dashboard count
collections	User collection count
items	Total item count across all user collections
fields_total / fields_max	Field counts
files	File count
database_size	Database size in bytes
files_size_total	Total upload size in bytes
extensions	Enabled extension count
mcp_enabled / mcp_allow_deletes / mcp_system_prompt_enabled	MCP configuration booleans
websockets_enabled	Boolean
collaborative_editing_enabled	Boolean
ai_openai_api_key	Boolean (whether a key is configured)
ai_anthropic_api_key	Boolean (whether a key is configured)
ai_system_prompt	Boolean (whether a custom prompt is configured)
api_requests_get/post/patch/delete/put/search	Per-method API request counts
api_requests_cached	Cached request count
api_requests	Total request count

There is a second data stream — POST https://telemetry.directus.io/v1/owner — which transmits project_owner, org_name, and contact email for license compliance. This is not optional and not governed by the TELEMETRY flag.

2. TELEMETRY=false no longer works in v12 — for anyone

In v11, the opt-out is a plain env check (api/src/schedules/telemetry.ts):

if (toBoolean(env['TELEMETRY']) === false) return false;

In v12.0.0-rc.1 the same file reads:

if (!getEntitlementManager().isEntitled('telemetry_required') && !toBoolean(env['TELEMETRY'])) {
    return false;
}

isEntitled() returns override ?? default of the active license’s entitlements. And the built-in Core license — which applies to every installation without a license key — ships with (from @directus/license@0.2.0, CORE_LICENSE):

telemetry_required: { default: true }

Putting these together: in v12, the TELEMETRY=false environment variable is ineffective on every tier, including keyless Core installations, unless the active license overrides telemetry_required. This is consistent with the pricing page, which lists “Analytics Opt-out” exclusively under Enterprise. It directly contradicts the current configuration docs, which still describe TELEMETRY as a freely settable variable for self-hosted projects.

3. License validation includes remote enforcement

Source: api/src/license/manager.ts, api/src/schedules/license.ts, Licensing Overview docs

With a license key active (paid tiers and Open Innovation Grant — grant users receive registration keys too):

• The instance periodically calls the license server, transmitting usage_metrics (seats, collections, flows), project_id, and public_url.
• The check interval (validation_interval) is embedded in the license token, i.e. controlled server-side.
• If the server responds LICENSE_EXPIRED, LICENSE_CANCELED, or LICENSE_SUSPENDED, the instance removes its license and downgrades to Core entitlements across all containers.
• Per the official docs, an instance over its entitlements outside a grace period becomes “locked”: /items and common API operations are blocked, GraphQL/WebSockets/MCP are disabled, non-admin logins are rejected.

I’ll state my assessment plainly, and everyone can judge for themselves: a system that periodically reports usage to a vendor server and accepts remote suspension decisions that render the API non-functional can, in my view, reasonably be described as license DRM with a built-in kill switch. The mechanism applies to every keyed installation — and since Core’s limits (3 seats / 25 collections / 5 flows) are below virtually any production workload, practically every production deployment will be keyed. The OIG terms explicitly reserve the right to revoke grant keys.

4. Owner registration

Source: api/src/schedules/project.ts, api/src/telemetry/lib/send-report.ts

While project_status is pending, a daily job sends project_owner, org_name, project_usage, product_updates, and project_id to COMPLIANCE_URL (default: the same telemetry server, /v1/owner), then clears the status. This transmission includes directly person-related data (owner name, contact email) and is governed neither by TELEMETRY nor by any documented opt-out I could find.

5. GDPR concerns for EU self-hosters

This is where it gets legally uncomfortable for those of us hosting for European clients.

What is being transmitted and where: Identifiable installation data (PUBLIC_URL + project_id), owner contact data, and business metrics are sent to Monospace Inc., a Delaware-incorporated US company.

What I could not find:

• A publicly available Data Processing Agreement (DPA) covering self-hosted deployments. The Trust Center (trust.directus.io) gates its documents behind an access request. The DPA referenced publicly appears to cover Directus Enterprise Cloud only.
• Monospace Inc. in the EU-US Data Privacy Framework participant registry.
• Standard Contractual Clauses (SCCs) or any other Art. 46 GDPR transfer mechanism documented for self-hosters.

If any of these exist, a public pointer would resolve this section immediately — I’d genuinely welcome being corrected here.

The MSCL license compounds the problem: Its anti-circumvention clause prohibits disabling or circumventing the license key functionality. Since telemetry enforcement in v12 is implemented as part of the license entitlement system (telemetry_required), an EU operator who needs to stop these transfers to remain compliant with their own client obligations arguably cannot do so without either violating the license terms or staying on v11.

If you are an EU-based agency or developer hosting Directus instances on behalf of clients under data processing agreements, this is not a theoretical concern. Your PUBLIC_URL — which identifies your client’s infrastructure — is transmitted to a US company on a legal basis I have not been able to determine from public materials.

6. Open questions

1. Is the v12 behavior of ignoring TELEMETRY=false on non-Enterprise tiers (including keyless Core) intended? If yes, please update the configuration docs accordingly.
2. Does “Analytics Opt-out” on the pricing page refer to the telemetry_required entitlement override, or to something else? The term “Analytics” appears nowhere in code or docs.
3. Is there a DPA and an Art. 46 GDPR transfer mechanism for self-hosted deployments? (See section 5.)
4. What is the reference date for the MSCL’s 4-year GPL conversion? “The date we make the Software available” is ambiguous as to whether it refers to each version’s release.

I’d appreciate answers from the team — these are questions any EU-based agency must be able to answer before deploying v12 for clients.

[Beth]

Hey @alphanull, firstly I’m really sorry for the lack of update to your first post, it was shared internally with the right folks and I was waiting on the new docs page on this to be up to be able to point you to. It’s coming shortly but in the meantime I should have let you know that the post definitely wasn’t being ignored.

With regards to the new set of open questions, I’m not the right person to answer these but you’ll be getting answers shortly. In the meantime, I do want to say thanks for your in-depth outline of considerations, I really appreciate the time taken to share your thoughts and will make sure we get you the answers as soon as able.

[alphanull]

Re: Telemetry, GDPR, and v12 — Follow-up

Thanks for the response and the new telemetry documentation, greatly appreciated. Still, for me, a few points still need addressing now that v12 is officially released.

Confirmed: The docs align with the source code, and they confirm that telemetry opt-out is Enterprise-only. For all other tiers — including OIG — TELEMETRY=false has no effect in v12.

The enforcement mechanism

Every keyed instance connects periodically to Directus’s licensing server, transmitting usage metrics. The server controls the check interval and can respond with LICENSE_SUSPENDED, locking the API. You could reasonably call this DRM — and since Core’s limits (3 seats, 25 collections, 5 flows) rule it out for most real projects, practically everyone with a non-trivial setup is affected. As a side effect, these license pings also constitute data transfers to US servers — which leads directly to the next point:

The GDPR gap

From what we have been able to determine, operating v12 with any license key raises some GDPR concerns around third-country data transfers:

• A recurring /v1/owner data stream sends project owner name, organization, and contact email to Directus’s US servers. This is personal data under Art. 4(1) GDPR, is not mentioned in the telemetry docs, and has no documented opt-out.
• Monospace Inc. is apparently not listed in the EU-US Data Privacy Framework (verified on dataprivacyframework.gov). No SCCs or other Art. 46 instrument appear in the current Terms of Service.
• The team’s own response confirms this: “currently working on” Art. 46 mechanisms means none are in place today.

Under GDPR Art. 44, the transfer must not occur until a mechanism exists — regardless of whether Directus considers itself an independent controller. The self-hoster, as exporter, bears that responsibility. For EU self-hosters running v12 with a license key: this gap is a current compliance issue, not a future one.

Open questions

1. What is the legal basis for the /v1/owner stream, and where is it documented?
2. When will an Art. 46 mechanism be in place?
3. What is the recommended path for EU operators in the meantime?

Looking forward to your response!

[Beth]

Hey @alphanull, I wanted to send a quick follow up with the telemetry docs page being out.

[jonathanwagner]

Thank you for taking the time to put together these thorough questions and highlighting these areas for us. We truly appreciate your diligence and feedback, as it helps us ensure our documentation, pricing, and compliance policies are completely clear during this transition to version 12.

1. Telemetry Behavior on Non-Enterprise Tiers
   Yes, this behavior is intended for version 12. The TELEMETRY=false configuration is only available on Enterprise tiers to support the new mandatory license verification and telemetry structure. We have updated our documentation as of June 10 to reflect this behavior. You can review the updated details here: Directus Telemetry Documentation.

2. “Analytics Opt-out” on the Pricing Page
   You are entirely correct—that term was ambiguous. “Analytics Opt-out” did indeed refer to the telemetry_required entitlement override. To keep our wording aligned with our code and documentation, we updated the pricing page on June 10 to change “Analytics” to “Telemetry.” You can view the update here: Directus Pricing.

3. DPA and Art. 46 GDPR Transfer Mechanism
   Data Processing Agreement (DPA): Because Directus still does not have access to your database, client content, or end-user data, we do not act as a Data Processor. A standard DPA is therefore not required or applicable for self-hosted deployments.

Art. 46 Transfer Mechanism: For the mandatory license pings and metadata, Directus acts as an Independent Data Controller. We are currently working with our legal team to formally update our Terms of Service / License Agreement to explicitly incorporate the necessary Article 46 transfer mechanisms. This is a priority action for us, and we will notify you as soon as these updates are published.

4. Reference Date for the 4-Year GPL Conversion
   To clarify the language in the MSCL, “the date we make the Software available” refers strictly to each specific version’s release date. The 4-year timeline to convert to the GPL license is calculated independently for each individual version or update from the day it is publicly released.

Kind regards - The Directus Team