recall
Discuss a pilot

Telemetry

What Recall's CLI and local deployment collect, how it is identified, and how to disable it.

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:

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

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

  • 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

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:

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

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.

Was this page helpful?

View as Markdown