Uptrace

Last reviewed Sep 13, 2026 · 761 words

Read the licence before the README. Uptrace is BSL-1.1, which is source-available rather than open source: you can run it for yourself and your company without paying, but you cannot offer it to third parties as a hosted service, and each release only converts to an open-source licence after its change date. For a homelab or an internal engineering team that changes nothing in practice. For a company whose product might one day include observability for customers, it is a hard stop, and the licences for self-hosters piece explains why that clause matters more than it looks. Everything else about Uptrace is good news.

OpenTelemetry-native means no vendor agent

Uptrace does not ship its own SDKs. Your services use the standard OpenTelemetry libraries and export OTLP to it, which means the day you switch backends nothing in the application changes. Traces, metrics and logs all arrive through the same two ports: 14317 for OTLP over gRPC and 14318 for OTLP over HTTP, which also serves the web UI. The UI is the reason people pick it over stitching together Jaeger plus Grafana: spans, service graphs, metric dashboards and log search in one place, with a query language that reads more like SQL than PromQL.

The storage split is telemetry in ClickHouse and metadata (users, projects, dashboards, alert rules) in PostgreSQL. So "easy to deploy" in the catalogue's pros means three containers rather than the ten a Grafana stack of Tempo, Loki and Mimir would need, not one.

Three containers, one YAML

services:
  clickhouse:
    image: clickhouse/clickhouse-server:latest
    volumes:
      - ./ch-data:/var/lib/clickhouse
  postgres:
    image: postgres:16
    environment:
      - POSTGRES_USER=uptrace
      - POSTGRES_PASSWORD=uptrace
      - POSTGRES_DB=uptrace
    volumes:
      - ./pg-data:/var/lib/postgresql/data
  uptrace:
    image: uptrace/uptrace:latest
    volumes:
      - ./uptrace.yml:/etc/uptrace/uptrace.yml
    ports:
      - "14317:14317"
      - "14318:14318"
    depends_on:
      - clickhouse
      - postgres

The uptrace.yml declares the ClickHouse and Postgres DSNs, at least one project with a secret token, and the initial admin user. The project token becomes the DSN your services authenticate with. With the OpenTelemetry SDK that is two environment variables:

OTEL_EXPORTER_OTLP_ENDPOINT=http://uptrace.lan:14318
OTEL_EXPORTER_OTLP_HEADERS=uptrace-dsn=http://[email protected]:14318?grpc=14317

The catalogue's 512 MB is for Uptrace alone; ClickHouse wants at least another 1 to 2 GB to be pleasant, so plan 3 GB for the trio on a box that does other things. Kubernetes users get a Helm chart from the project, and the single binary runs on a plain VM if you would rather point it at managed ClickHouse and Postgres; the compose route is still the one I would start with.

Disk is where the surprise lives

ClickHouse compresses telemetry well, but a chatty microservice emitting spans for every request can add several GB a day, my estimate from a modest deployment. Metrics are cheap by comparison and logs sit in between. Set the retention TTLs in uptrace.yml before pointing production at it, and put ch-data on a disk you have measured. Sampling in the OpenTelemetry collector, in front of Uptrace, is the second lever, and is the same lever you would pull with any backend. If you are tracing LLM calls, which produce large spans, the LLM observability piece covers what to keep.

SigNoz, Grafana or Jaeger

SigNoz is the bigger project and, for most self-hosters, the safer pick: larger community, MIT-licensed core, and the same OTLP-in, ClickHouse-under design. Uptrace's edge is polish and a query model that engineers who think in SQL take to quickly. Both are real Datadog replacements for a team that can run ClickHouse; neither is a Datadog replacement for a team that cannot.

What I'd do

Internal use, team of engineers, ClickHouse experience or willingness to get it: Uptrace, the three-container compose above, retention set to 7 to 14 days, sampling in the collector from day one, on a host with 4 GB to spare. Any doubt about the BSL clause, or a preference for the larger community: SigNoz, same architecture, and you lose little. Either way, instrument with plain OpenTelemetry so the backend stays a swappable part rather than a commitment.