# Telemetry (/docs/developer-guide/telemetry)



Recall includes optional telemetry hooks for operators who want usage data
in their own PostHog project. The source distribution does not ship a
vendor API key, so no telemetry is sent by default. To enable it, the
operator must explicitly configure `POSTHOG_API_KEY` for server/CLI
events and `VITE_POSTHOG_KEY` for browser events.

Telemetry can come from two places, and the same opt-out covers both:

. **The CLI** — events fired by `recall` commands you run on your machine.
. **Your local deployment** — events fired by the web app and worker
  containers when you run `recall compose up -d`.

## What is collected [#what-is-collected]

When an operator configures PostHog, events include some
combination of:

* **Deployment ID** — a random UUID generated by `recall init` and written
  to your deployment's `.env` as `DEPLOYMENT_ID`. It identifies both your
  CLI events and your local deployment's web/worker events. Re-running
  `recall init` reuses the existing ID, so the identity is stable. It is
  not derived from your machine, email, username, or any configuration
  value.
* **Version, OS, architecture, Node version**, and **deployment mode**
  (`local`, `whitelabel`, etc.)
* **Command/event name** and a small set of non-secret options (e.g.
  whether Postgres runs in Docker, whether `--dev` was passed, which
  providers are configured)
* **Feature counts** from the web app — e.g. number of prompts edited,
  brands created, reports run. Counts only, never the names or text.
* **IP address** — PostHog records the request IP on each event and uses
  it for approximate geolocation.

If you opt in to product updates during `recall init` and provide an email
address, the CLI can record a `newsletter_signup` event with the email
attached as a person property. This only happens when the deployment
operator has configured `POSTHOG_API_KEY`; the source distribution has
no upstream destination.

* If telemetry is **enabled**, the event is keyed off your deployment ID,
  so the email links to the rest of your CLI events.
* If telemetry is **disabled**, the event is keyed off the email itself
  and is never linked back to your deployment ID.

## What is not collected [#what-is-not-collected]

* API keys, `.env` contents, or any secrets
* Brand names, prompt text, or scraped responses
* File paths, repo paths, or hostnames
* Logs or stack traces

## How to disable it [#how-to-disable-it]

The CLI asks during `recall init` whether to share telemetry. The choice
covers both the CLI and your local deployment. To change your mind
later, edit `.env` and add or remove `DISABLE_TELEMETRY=1`:

```sh
recall edit env             # opens .env in $VISUAL / $EDITOR (fallback: nano)
recall compose up -d        # restart so the web app and worker pick it up
```

Setting `DISABLE_TELEMETRY=1` in any environment also disables telemetry
there unconditionally, which is handy in CI or for one-off runs without
touching the file.

When telemetry is disabled, no usage events are sent. A newsletter
signup remains an explicit action, but it is only delivered to a
PostHog project configured by the deployment operator.

## Why we collect this [#why-we-collect-this]

We use this data to answer questions like:

* how many Recall instances are running in the wild, and on what versions
* how many total prompts are being tracked across all instances
* which model providers are most popular, and which ones produce the most
  errors
* how often `recall init` succeeds end-to-end, and where it drops off
* which Postgres mode (Docker vs. external) is more common
* whether new features actually get used after we ship them

If you have feedback on what we collect, contact the repository owner through
the project's current issue tracker.