Telemetry

The self-hosted Dakera engine sends product telemetry to Dakera's PostHog project. It tells us how many engines run, and how they run: which versions, platforms and storage setups, whether they stay up, how often they are upgraded, and how much they are used. We use it to decide what to build, test and support, and to find the crashes and slow paths that users rarely report.

This page is for operators who need to know exactly what leaves their server: every event and property, what is never sent, how to inspect each payload and how to turn telemetry off.

In v0.12.0 the engine sends the machine's hostname, and PostHog keeps the IP address the events come from and derives a coarse location from it (GeoIP). Both stop with one setting: DAKERA_TELEMETRY=0 or DO_NOT_TRACK=1. A memory engine holds sensitive data, so telemetry is built on these rules:

• it never reads what you store;
• everything it sends is listed on this page;
• you can inspect every payload;
• one setting turns it off.

Turning it off

Set either variable, in the server's environment. Nothing is then counted, written or sent.

DAKERA_TELEMETRY=0 ./dakera        # also: false | off | no
DO_NOT_TRACK=1 ./dakera            # the cross-tool convention; also: true

At startup the engine logs one line: what it sends and how to turn it off, or that telemetry is disabled.

Seeing exactly what is sent

With this setting, the engine logs every batch of events (as JSON) before it sends it:

DAKERA_TELEMETRY_DEBUG=1 ./dakera

What is NEVER sent

• Memory content, embeddings, queries, prompts or anything else a user wrote.
• Ids and names: memory, agent, session, namespace and API-key ids, or any name you chose.
• API keys, passwords, tokens or any other secret.
• File paths, URLs, bucket names, endpoints: no text value of any setting.
• Raw User-Agent strings: only the client kind and major.minor version.
• Exact business volumes: request, memory, agent and namespace counts are rounded to two significant digits (12 345 → 12 000).

What identifies a deployment

Telemetry is not anonymous at the network level:

• Hostname: engine_started and engine_heartbeat carry the machine's hostname (hostname), as the operating system reports it.
• IP address: PostHog records the IP address the events come from ($ip), as any web service sees it, and derives a coarse location from it (GeoIP: country, region, city).

Both are used to count and understand deployments, never sold or shared. If you do not want them sent, turn telemetry off (DAKERA_TELEMETRY=0 or DO_NOT_TRACK=1); nothing else changes.

PostHog creates no person profile ($process_person_profile: false).

Identity

Where deployment_id comes from:

• S3 storage: the bucket's .instance_id object. The first start writes it, seeded with this node's id.
• Cluster: the smallest deployment_id gossiped by the live members.
• Otherwise: the node's own id.

When the data root is read-only, the engine falls back in this order:

1. $XDG_STATE_HOME/dakera/.instance_id;
2. an app-specific hash of /etc/machine-id, from which the machine-id cannot be recovered;
3. a random id per process, reported with id_ephemeral: true.

The node also keeps a small record at <data root>/_dakera_cluster/telemetry.json. It holds:

• the version and start time of the last run;
• whether that run stopped cleanly;
• lifetime request totals;
• a random local salt;
• the salted fingerprints.

The engine uses it to tell restarts, upgrades and crashes apart. The record never leaves the machine. If you copy a data directory, delete .instance_id and _dakera_cluster/telemetry.json in the copy to give it its own identity.

When events are sent

All events of a moment go in one HTTPS POST to {DAKERA_TELEMETRY_HOST}/batch/ (default https://eu.i.posthog.com, EU).

A node that has started five times or more in the past hour (a crash loop) sends no start-time events. The next start outside the loop reports how many were suppressed.

Sending never gets in the way:

• Each request times out after 3 s.
• A failed batch is kept (at most 50 events) and retried after 15 minutes, then 30, 60, and so on, up to 6 hours. There are no retry storms.
• Offline or air-gapped, sends fail quietly: a debug log line, nothing else.
• Shutdown waits for telemetry at most 2 s.
• On the request path, counting is an atomic increment.

Properties

On every event

Environment, configuration and health (engine_started, engine_heartbeat)

engine_started

engine_heartbeat

engine_crashed

engine_version_changed and engine_stopped

• engine_version_changed carries from_version, to_version, direction (upgrade / downgrade) and previous_run_id.
• engine_stopped carries uptime_s and ready.

Closed sets

Operator-set labels are sent only when they are one of these words; any other value is sent as custom:

• DAKERA_DEPLOYMENT: k8s, kubernetes, helm, docker, compose, docker-compose, podman, nomad, ecs, cloudrun, fly, railway, render, systemd, binary, source.
• DAKERA_DEPLOYMENT_TYPE: production, staging, development, ci, test, demo, internal.

Configuration reference

No variable is needed. These existed before v0.12; none is new.

Heartbeats from development builds (version 0.0.0) are dropped at the source.