What Manifest stores
Manifest always keeps metadata about each request: model, provider, tier, token counts, cost, latency, and a scrubbed error message. Inline image data is stripped out, and error text is scrubbed for secrets before it lands. The usage and cost views in the dashboard are built from that metadata alone. See Observability for what the record looks like in practice. Message bodies are separate, and optional. With request logs on for a harness, Manifest also stores the request and response bodies of each provider attempt so you can read them back in the dashboard. New harnesses have it enabled; to make sure a harness records its logs, check its Settings → Logs. Recorded bodies are held outside the database, in the object storage your instance is configured for, and deleted on a retention schedule. With recording off for a harness, that harness’s prompts and completions stay between you and the provider, exactly as before.If a harness handles data you’d rather Manifest never hold onto, turn message
recording off on its Settings page. Metadata collection isn’t affected
either way.
Anonymous telemetry
Once a day, each self-hosted install sends us a small anonymous report. That’s how we know whether anyone’s actually using the thing, and which providers are popular enough to deserve more work. It’s aggregates, never content: no prompts, no messages, no keys, nothing tied to a user. Fifteen fields total.This section applies to self-hosted installs only. Manifest Cloud has no
separate telemetry report — your usage is already in your own dashboard.
What gets sent
† Optional. Installs running older Manifest versions omit these fields; receivers should feature-detect on presence rather than on
schema_version. Cost values are derived from the same input_tokens / output_tokens we already ship, multiplied by Manifest’s per-model pricing table — no new data leaves the box, just a rolled-up dollar figure for what’s already disclosed.
Never sent
Tenant IDs, user IDs, emails, API keys, prompts, message contents, model names, custom provider URLs, OAuth client IDs, hostnames, raw IPs. The ingest takes a SHA-256 of your IP and throws the original away; we keep the hash so we can rate-limit bad actors without knowing where they actually live.When
- Once every 24 hours, per install.
- The first report is delayed by a random 0–24h offset, so a fleet of containers rebooted together doesn’t all hit the endpoint at the same minute.
- Off by default when
NODE_ENV != production. Dev machines are never going to accidentally send. - If the endpoint is down, we log it and try again on the next hourly tick. Your proxy keeps serving requests — the sender never gets in the way.
Turning it off
Put this in your.env (or docker-compose.yml) and restart the container:
Sending it somewhere else
If you’d rather run your own fleet dashboard, pointTELEMETRY_ENDPOINT at a URL you control. Add it to .env next to your compose file and restart:
telemetry.manifest.build.
Related
- Observability — what the recorded metadata gets you
- Environment variables —
MANIFEST_TELEMETRY_DISABLEDandTELEMETRY_ENDPOINTin context - Self-hosting with Docker — where to put these variables