Telemetry & Privacy

Starting with Plugwerk 1.1.0, the server sends a small, opt-out, privacy-respecting telemetry beacon so the maintainers can size the install base, see which versions and deployment types are in use, and prioritise work. It fires once on first server start and once per day thereafter.

This page describes exactly what the beacon sends, where it goes, the legal basis for it, and how to switch it off. If you would rather send nothing, turn it off — it is one environment variable.

You are the controller for everything else

Plugwerk is self-hosted software. For everything that happens inside your instance — accounts, namespaces, plugins, uploads — you are the data controller, and none of that data is ever part of the telemetry beacon. The beacon is the single thing the software reports back to its maintainers.

What the beacon collects

The payload is exactly four fields, and there is no code path that adds a fifth:

Field	Example	What it is
installId	7c9e6f… (UUID v4)	A random identifier generated once per installation and stored locally. Synthetic — not derived from anything and unlinkable to a person.
version	1.1.0	The Plugwerk version the instance is running.
installType	docker-compose	How it is deployed: docker-compose, jar, k8s, or unknown. Tells the maintainers how it runs, never where.
event	server_start	The lifecycle event: server_start or heartbeat (later activation events may add namespace_created / plugin_published).

What is never collected

No hostnames, IP addresses, namespaces, usernames, plugin names, account data, or request contents are ever collected. The payload is the four fields above and nothing else — enforced by construction, with a test asserting the serialized JSON carries exactly those keys so a future change cannot silently widen it.

As with any HTTPS request, your instance’s IP address is visible as transient connection metadata to the reverse-proxy provider that routes the request. It is never part of the payload, is not forwarded to the analytics processor, and is not used for analytics. The events carry no person profiles ($process_person_profile: false).

Where it goes

Beacons are sent over HTTPS only to a Plugwerk-operated reverse proxy — a Cloudflare Worker that validates the payload against the four-field allowlist — and forwarded from there to the analytics backend.

Role	Who
Controller	devtank42 GmbH (Plugwerk maintainers)
Processor	PostHog, on PostHog EU Cloud — telemetry is stored and processed within the EU. A signed Data Processing Agreement (DPA) is in place before any production data is ingested.
Sub-processor (transport)	Cloudflare, operating the telemetry reverse proxy under its standard DPA. It processes the connection (incl. source IP) transiently to route the request; the IP is not forwarded to PostHog.

Request bodies are never logged in transit. Because the payload contains no personal data, there is nothing personal to erase; resetting an instance’s installId (or a fresh install) detaches all future beacons from any prior series.

Legal basis (GDPR)

The signal is pseudonymous product/activation analytics — not advertising or profiling. Insofar as the synthetic installId is treated as personal data at all, the legal basis is the maintainers’ legitimate interest (Art. 6(1)(f) GDPR) in understanding adoption of their own software, balanced against a strictly PII-free payload and a one-line opt-out.

For the full, authoritative statement — purpose, processor, residency, retention, and data-subject contact — see the project’s Privacy Policy. Questions about the beacon or the DPA go to devtank42 GmbH at privacy@plugwerk.io.

Turning it off

Telemetry is opt-out. Disabling it stops everything — no install ID is generated, no heartbeat is scheduled, and no HTTP call is ever made:

export PLUGWERK_TELEMETRY=false

Related environment variables

Variable	Default	Description
PLUGWERK_TELEMETRY	true	Master switch. Set to false to fully disable — no install UUID, no schedule, no HTTP.
PLUGWERK_TELEMETRY_ENDPOINT	(live Plugwerk proxy)	HTTPS-only analytics endpoint. Leave empty to build the payload but never send it; set PLUGWERK_TELEMETRY=false to disable entirely.
PLUGWERK_INSTALL_TYPE	(auto-detected)	Override the auto-detected deployment type: docker-compose, jar, or k8s.
PLUGWERK_TELEMETRY_CRON	0 30 3 * * * (03:30 daily)	Spring cron expression for the daily heartbeat, staggered from other scheduled jobs.

These variables also appear in the full .env.example reference.

Verify it is off

Setting PLUGWERK_TELEMETRY=false gates the scheduler bean itself, so after a restart there is no heartbeat job and no outbound call. You can confirm no beacon is emitted by watching outbound connections, or simply trust the switch — with telemetry disabled the code path is never constructed.

It cannot affect your server

The beacon is fail-open. It runs off the startup and request paths with short (2 s) connect/read timeouts, and any failure — unreachable endpoint, timeout, error response — is silently ignored and logged at debug level. Telemetry can never affect startup, health, or readiness. A blank or non-HTTPS PLUGWERK_TELEMETRY_ENDPOINT simply means the payload is built and never sent, which is a harmless no-op.

Learn more

• Privacy Policy — the authoritative controller/processor statement.
• Telemetry & Privacy in the README — the upstream summary shipped with the server.
• Configuration — the telemetry environment variables in the wider config reference.