Telemetry

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

Elmo collects a small amount of usage data to help us understand which features get used and prioritize work. Telemetry comes from two places, and the same opt-out covers both:

The CLI — events fired by elmo commands you run on your machine.

Your local deployment — events fired by the web app and worker containers when you run elmo start.

What is collected

All events go to PostHog. Across both sources, an event includes some combination of:

Install ID — a random UUID generated by the CLI on first run and stored in ~/.config/elmo/config.json. Your local deployment gets a separate random UUID written to its .env as DEPLOYMENT_ID during elmo init. Neither is 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 elmo init and provide an email address, we record a newsletter_signup event with the email attached as a person property. This is the only path that ever sends an email. The signup runs even if you have disabled telemetry, because typing your email is an explicit action with clear intent; the event still goes to the same PostHog project.

If telemetry is enabled, the event is keyed off your install 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 install 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 elmo init whether to share telemetry. The choice covers both the CLI and your local deployment. You can change your mind at any time:

elmo telemetry status     # show current state and install ID
elmo telemetry disable    # turn off everything
elmo telemetry enable     # turn back on

elmo telemetry disable writes telemetryDisabled: true to ~/.config/elmo/config.json (used by the CLI) and adds DISABLE_TELEMETRY=1 to your deployment's .env (used by the web app and worker). Restart the stack with elmo start to apply the deployment-side change. Setting DISABLE_TELEMETRY=1 in any environment also disables telemetry there unconditionally.

When telemetry is disabled, no events are sent. The newsletter signup path described above is the one exception: if you choose to enter your email during elmo init, that single event is sent regardless of your telemetry setting, since you are explicitly asking to receive updates.

Why we collect this

We use this data to answer questions like:

how many Elmo 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 elmo 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, open an issue at github.com/elmohq/elmo.

Was this page helpful?