Open-source product analytics and error tracking in one self-hostable binary.
Keep the Sentry, PostHog and OpenTelemetry SDKs you already ship. Point them at Tracelet.
Quick start · Why Tracelet · Features · Resource usage · Docs
Most teams run two products to answer one question. An error shows up in Sentry, the people it hit live in PostHog, and someone copies an ID from one tab into the other. Self-hosting both means two stacks, two upgrade cycles and two sets of servers.
Tracelet is one product built for that question. Every error links to the people, releases, sessions and feature flags behind it, because they live in the same database. Open an issue and you see who it affected, which release brought it and the flags they had on.
You don't change your code. Tracelet speaks the real Sentry envelope protocol, the PostHog capture and flags API and OTLP. Change the DSN or the host, deploy, and your existing SDKs, old versions included, send to Tracelet instead.
It's small enough to run anywhere. PostHog's self-hosted guide asks for 4 vCPUs and 16 GB of RAM, and its compose file starts 39 services. Sentry's asks for 4 cores, 16 GB of RAM and 16 GB of swap across 28 services. Tracelet is one Go binary next to Postgres and ClickHouse. The whole stack stayed under 1.8 GB of memory while ingesting over a thousand requests a second (measured).
Enterprise features are free. SSO, SCIM, custom roles and audit logs ship in the open-source build. There's no paid tier hiding the login page your security team needs.
Note
Tracelet is in early development. It works end to end against the official SDKs and every feature below is built and tested, but expect rough edges before 1.0.
git clone https://github.com/tracelet-dev/tracelet
cd tracelet
docker compose -f deploy/docker-compose.yml up -dOpen http://localhost:3420, create your organization and copy the project key from Settings, Client keys. Then point an SDK at it:
Sentry SDKs: errors, tracing, logs
Sentry.init({
dsn: "http://<public key>@localhost:3420/1",
release: "shop@1.4.0",
tracesSampleRate: 1.0,
});Any official Sentry SDK works, in any language.
PostHog SDKs: events, people, flags, replay, surveys
posthog.init("phc_<public key>", { api_host: "http://localhost:3420" });Flags use the same hashing as PostHog, so a person gets the same variant on every SDK.
OpenTelemetry: traces and logs
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:3420
OTEL_EXPORTER_OTLP_HEADERS=X-Tracelet-Key=<public key>More in Sending data and Self-hosting.
Issues grouped by cause, with stack traces mapped back to your source through uploaded source maps, breadcrumbs, tags and the release each issue first appeared in. Resolve an issue in the next release, assign it or ignore it. Alerts go to email or webhooks. Cron monitors come from Sentry check-ins, and uptime checks probe your URLs on a schedule.
Trends, funnels, retention, stickiness, lifecycle and paths, built from your events and split by any property or cohort. Trends draw as lines, areas, stacked areas, bars, ranked totals, pies, big numbers, tables or an hour-by-weekday heatmap, and compare against the previous period. Put any insight on a dashboard and switch every tile to the same date range at once.
 |
 |
| Ten chart types for every trend | Paths: where people go after any page |
Also in the box:
- Feature flags with property and cohort targeting, rollouts and multivariate variants.
- A/B experiments with Bayesian results and the chance each variant is best.
- Surveys for posthog-js, built on their own page with a live preview.
- Cohorts, people and web analytics, and a sandboxed SQL editor with CSV export.
OpenTelemetry and Sentry spans in one waterfall, with the logs written inside each span shown under it. Session recordings from the PostHog SDK play back with an activity log, and inputs can be masked.
Explain an issue or ask a question in plain language through any OpenAI-compatible API, Anthropic or a local model. AI is off until an admin turns it on, it's never on the ingest path, and you can preview exactly what would be sent before anything leaves your server.
flowchart LR
subgraph SDKs["Your apps, unchanged"]
S[Sentry SDK]
P[PostHog SDK]
O[OpenTelemetry]
end
S -- envelopes --> T
P -- capture, flags --> T
O -- OTLP --> T
T["tracelet<br/>one Go binary"] -- write-ahead log --> W[(WAL on disk)]
W --> CH[(ClickHouse<br/>events, spans, logs)]
T --> PG[(Postgres<br/>accounts, issues, flags)]
T --> UI[Dashboard and API]
Requests are written to a local write-ahead log and answered straight away, so a slow database never makes an SDK wait or drop data. A processor drains the log into ClickHouse and Postgres in batches and retries without writing anything twice. Queues, caches and quotas are bounded, and anything dropped is counted with a reason instead of disappearing.
Measured on one desktop machine with default Postgres and ClickHouse settings while the benchmark replayed recorded SDK traffic. The method and raw numbers are in docs/benchmarks.md.
- Tracelet: 41 MB of memory idle, 78 MB at peak under load, about a third of one CPU core.
- Postgres: about 130 MB.
- ClickHouse: about 1.3 GB, mostly its default caches.
- Throughput: 7,197 Sentry envelopes, 4,651 PostHog captures or 4,472 OTLP requests a second, all accepted, with p99 latency under 60 ms.
Tip
The load generator ships in the repo. Run tracelet-bench on your own hardware to see what it
does there; the command is in docs/benchmarks.md.
- Self-hosting: Docker Compose, a single binary, Kubernetes and upgrades
- Sending data: every SDK, source maps, replay, surveys and cron monitors
- Configuration: every
TRACELET_*setting - Operations:
tracelet doctor, backups, metrics and the write-ahead log - Security and API
bun install --cwd web
bun run --cwd web services
go run ./cmd/tracelet serve
bun run --cwd web devRead CONTRIBUTING.md before opening a pull request, and SECURITY.md before reporting a vulnerability.
Tracelet is AGPL-3.0. It works with the official Sentry, PostHog and OpenTelemetry SDKs, which keep their own licenses. Tracelet isn't affiliated with Sentry or PostHog.