Coroot vs SigNoz vs HyperDX: Self-Hosted Observability Platforms 2026

Commercial observability platforms like Datadog, New Relic, and Dynatrace charge per host, per ingested gigabyte, and per custom metric. A mid-size infrastructure with 50 services can easily exceed $5,000 per month in monitoring costs. For teams running Kubernetes clusters or multi-service architectures, self-hosted observability delivers the same full-stack visibility without the recurring bills or data sovereignty concerns.

This guide compares three leading open-source observability platforms available in 2026: Coroot (eBPF-based zero-instrumentation), SigNoz (OpenTelemetry-native APM), and HyperDX (developer-centric debugging with session replay). Each takes a fundamentally different approach to the problem, and understanding those differences is key to picking the right tool for your stack.

Why Self-Host Your Observability Stack?

Moving your monitoring infrastructure in-house solves several operational and financial problems simultaneously:

• Predictable costs. Your observability bill becomes a function of storage and compute — resources you can plan for — rather than opaque per-host or per-ingestion pricing that scales with your success.
• Unlimited data retention. Commercial platforms aggressively prune old data or charge premium rates for long-term storage. Self-hosted, you decide retention policies based on your actual needs.
• Complete data ownership. Every log line, trace span, and metric stays within your infrastructure. No telemetry data leaves your network.
• Zero-instrumentation options. eBPF-based tools like Coroot capture metrics, traces, and logs without requiring any code changes to your applications.
• Custom alerting pipelines. Route alerts through internal notification systems (Gotify, Ntfy, Matrix) without depending on external SaaS connectors.
• Compliance and data sovereignty. Regulated industries (healthcare, finance, government) often require telemetry data to remain on-premises or within specific geographic boundaries.

The trade-off is operational overhead: you need to provision, maintain, and scale the infrastructure yourself. The tools below minimize that burden with Docker Compose and Kubernetes Helm chart deployments.

The Contenders at a Glance

Coroot: Zero-Instrumentation Observability with eBPF

Coroot stands out from other observability platforms by using eBPF (extended Berkeley Packet Filter) to capture metrics, logs, traces, and CPU profiles without requiring any changes to your application code. This is a fundamentally different approach: instead of asking developers to add OpenTelemetry SDKs to every service, Coroot observes the kernel-level system calls and network traffic to build a complete picture of your infrastructure.

Key Features

• Automatic Service Map. Coroot discovers every service, database, cache, and external dependency by analyzing network traffic. No manual configuration or service registration required.
• Predefined Inspections. Over 80 built-in inspections audit each application for common issues: high error rates, slow database queries, certificate expiry, insufficient replicas, memory leaks, and more.
• Deployment Tracking. Automatically detects new deployments and compares performance before and after each rollout. Flags regressions without requiring CI/CD integration.
• Cost Monitoring. Estimates cloud spend per application by analyzing resource usage patterns against AWS, GCP, and Azure pricing.
• SLO-Based Alerting. Define Service Level Objectives and receive alerts when they are at risk of being violated, rather than after they have already been breached.

Architecture

Coroot runs as a single binary that includes the web UI, data collector, and ClickHouse storage. The eBPF-based node agent runs on each Kubernetes node (or Docker host) and ships telemetry data to the central Coroot instance.

Docker Compose Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

version: "3.8"

services:
  coroot:
    image: ghcr.io/coroot/coroot:latest
    container_name: coroot
    ports:
      - "8080:8080"
    volumes:
      - coroot-data:/data
    environment:
      - COROOT_LISTEN_ADDR=0.0.0.0:8080
      - COROOT_DATA_DIR=/data
    restart: unless-stopped
    # For eBPF data collection, run the node-agent on each host:
    # docker run -d --name coroot-node-agent \
    #   --privileged --pid=host --net=host \
    #   -v /sys/kernel/debug:/sys/kernel/debug:rw \
    #   -v /sys/fs/cgroup:/sys/fs/cgroup:ro \
    #   ghcr.io/coroot/coroot-node-agent:latest \
    #   --collector-endpoint=http://<coroot-host>:8080

  clickhouse:
    image: clickhouse/clickhouse-server:latest
    container_name: coroot-clickhouse
    ports:
      - "9000:9000"
      - "8123:8123"
    volumes:
      - clickhouse-data:/var/lib/clickhouse
    environment:
      - CLICKHOUSE_DB=coroot
    restart: unless-stopped

volumes:
  coroot-data:
  clickhouse-data:

For Kubernetes deployments, Coroot provides official Helm charts that deploy the node-agent as a DaemonSet and the central Coroot instance as a StatefulSet.

SigNoz: OpenTelemetry-Native Full-Stack APM

SigNoz is the most popular open-source alternative to Datadog, built from the ground up around OpenTelemetry. If your team is already instrumenting services with OpenTelemetry SDKs (or planning to), SigNoz provides a complete observability backend with a polished UI that rivals commercial platforms.

Key Features

• OpenTelemetry Native. SigNoz uses the OpenTelemetry Collector as its ingestion layer, meaning any data sent via OTLP (OpenTelemetry Protocol) works out of the box. This includes metrics, logs, and traces from any OTel-compatible SDK.
• Application Performance Monitoring (APM). Full distributed tracing with service-level dashboards, endpoint-level latency breakdowns, and database query analysis.
• Metrics Dashboards. Built-in dashboard builder with support for time-series charts, heatmaps, and tables. Pre-configured dashboards for common services (Redis, PostgreSQL, Nginx, JVM, Go runtime).
• Log Management. Full-text log search with pattern detection and log-to-trace correlation. Filter logs by trace ID to jump directly to the relevant request context.
• Alerting. Configurable alert rules based on metrics, logs, or traces. Supports webhooks, email, Slack, PagerDuty, and Opsgenie as notification channels.
• Exception Tracking. Automatically captures and groups application exceptions, showing frequency, affected services, and sample stack traces.

Architecture

SigNoz is a multi-service architecture built on ClickHouse for storage. The OpenTelemetry Collector ingests data, the Query Service processes analytics queries, and the Frontend provides the React-based UI. Additional components handle alerting and schema migration.

Docker Compose Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

version: "3.8"

services:
  otel-collector:
    image: signoz/signoz-otel-collector:latest
    container_name: signoz-otel-collector
    ports:
      - "4317:4317"   # OTLP gRPC
      - "4318:4318"   # OTLP HTTP
      - "8888:8888"   # Prometheus metrics
    command: ["--config=/etc/otel-collector-config.yaml"]
    volumes:
      - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml
    restart: unless-stopped

  clickhouse:
    image: clickhouse/clickhouse-server:24.1.2-alpine
    container_name: signoz-clickhouse
    ports:
      - "9000:9000"
      - "8123:8123"
      - "9181:9181"
    volumes:
      - ./clickhouse-config.xml:/etc/clickhouse-server/config.xml
      - clickhouse-data:/var/lib/clickhouse
    ulimits:
      nofile:
        soft: 262144
        hard: 262144
    restart: unless-stopped

  query-service:
    image: signoz/signoz-query-service:latest
    container_name: signoz-query-service
    ports:
      - "8080:8080"
    environment:
      - ClickHouseUrl=tcp://clickhouse:9000
      - DASHBOARDS_LOCATION=/etc/signoz/dashboard
    volumes:
      - ./dashboards:/etc/signoz/dashboard
    depends_on:
      - clickhouse
    restart: unless-stopped

  frontend:
    image: signoz/signoz-frontend:latest
    container_name: signoz-frontend
    ports:
      - "3301:3301"
    environment:
      - FRONTEND_API_ENDPOINT=http://query-service:8080
    depends_on:
      - query-service
    restart: unless-stopped

  alertmanager:
    image: signoz/signoz-alertmanager:latest
    container_name: signoz-alertmanager
    ports:
      - "9093:9093"
    volumes:
      - alertmanager-data:/data
    depends_on:
      - query-service
    restart: unless-stopped

volumes:
  clickhouse-data:
  alertmanager-data:

The official SigNoz repository includes a complete deploy/docker-compose.yaml with all services pre-configured. Run docker-compose up -d and the full stack starts within a few minutes.

HyperDX: Developer-Centric Debugging with Session Replay

HyperDX takes a different angle from the other two platforms: it is built for developer debugging rather than infrastructure monitoring. The standout feature is session replay — the ability to watch exactly what a user saw and did in their browser at the moment an error occurred, correlated with the full backend trace.

Key Features

• Session Replay. Records user interactions (clicks, scrolls, form inputs) and replays them alongside backend traces and logs. This is invaluable for reproducing and fixing front-end bugs.
• Unified Debugging View. See the full context of any error: the user session replay, the backend trace, relevant log lines, and the error stack trace — all in one view.
• OpenTelemetry Based. Uses the standard OTel SDK for instrumentation, so data from any OTel-compatible service flows into HyperDX without custom adapters.
• ClickHouse Storage. Fast, columnar storage for high-volume log and trace data with efficient compression.
• Search and Filter. Powerful search across logs and traces with attribute-based filtering. Find all requests matching a specific error code, user ID, or endpoint path.
• Lightweight Deployment. Simpler architecture than SigNoz with fewer moving parts, making it easier to run on smaller infrastructure.

Architecture

HyperDX consists of three main services: the web frontend (Next.js), the API server (Node.js), and ClickHouse for storage. The OpenTelemetry Collector can be added for advanced ingestion routing.

Docker Compose Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

version: "3.8"

services:
  hyperdx-api:
    image: hyperdx/hyperdx-api:latest
    container_name: hyperdx-api
    ports:
      - "8080:8080"
    environment:
      - HYPERDX_DB_HOST=postgres
      - HYPERDX_DB_PORT=5432
      - HYPERDX_DB_USER=postgres
      - HYPERDX_DB_PASSWORD=postgres
      - HYPERDX_CLICKHOUSE_HOST=clickhouse
      - HYPERDX_CLICKHOUSE_PORT=9000
      - HYPERDX_REDIS_HOST=redis
      - HYPERDX_REDIS_PORT=6379
    depends_on:
      - postgres
      - clickhouse
      - redis
    restart: unless-stopped

  hyperdx-frontend:
    image: hyperdx/hyperdx-frontend:latest
    container_name: hyperdx-frontend
    ports:
      - "3000:3000"
    environment:
      - NEXT_PUBLIC_API_ENDPOINT=http://localhost:8080
    depends_on:
      - hyperdx-api
    restart: unless-stopped

  clickhouse:
    image: clickhouse/clickhouse-server:latest
    container_name: hyperdx-clickhouse
    ports:
      - "9000:9000"
      - "8123:8123"
    volumes:
      - clickhouse-data:/var/lib/clickhouse
    restart: unless-stopped

  postgres:
    image: postgres:16-alpine
    container_name: hyperdx-postgres
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
    volumes:
      - postgres-data:/var/lib/postgresql/data
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    container_name: hyperdx-redis
    restart: unless-stopped

volumes:
  clickhouse-data:
  postgres-data:

HyperDX requires PostgreSQL and Redis in addition to ClickHouse, making its storage requirements slightly heavier than Coroot’s single-container setup. However, the multi-service architecture is well-suited for Kubernetes deployments with separate scaling for each component.

When to Choose Each Platform

Choose Coroot if:

• You want zero-instrumentation observability — no SDK changes, no OpenTelemetry setup, just deploy the eBPF agent and get full visibility.
• You need automatic service topology discovery — Coroot builds the service map from actual network traffic, not manual configuration.
• You are running Kubernetes and want a native deployment with Helm charts and DaemonSet-based agents.
• You need continuous profiling without integrating a separate profiler like Pyroscope or Parca.
• Your team does not want to manage the complexity of an OpenTelemetry Collector configuration.

Choose SigNoz if:

• You are already using or planning to use OpenTelemetry SDKs across your services.
• You need a full APM replacement for Datadog or New Relic, with distributed tracing, metrics, logs, and alerting in one platform.
• You want exception tracking and automatic error grouping across your application fleet.
• Your team values a polished, feature-rich UI with pre-built dashboards for common services.
• You need advanced alerting with support for multiple notification channels and alert management workflows.

Choose HyperDX if:

• Your primary need is developer debugging — understanding why a specific user experienced an error.
• Session replay is critical for your workflow — seeing what users saw and did at the moment of failure.
• You run web applications with significant front-end complexity (React, Vue, Angular) and need front-end observability.
• You want a simpler architecture than SigNoz with fewer services to manage.
• Your team prioritizes trace-to-session correlation over infrastructure-level metrics and service maps.

Deployment Comparison: Resource Requirements

All three platforms use ClickHouse as their primary storage backend, which benefits from aggressive columnar compression. Retention policies should be configured based on available disk space — a typical production setup with moderate traffic needs 50-100 GB of storage for 30-day retention.

Integration Ecosystem

Coroot integrates with Prometheus (for additional metrics), Alertmanager (for alerting), and any webhook-based notification system. It can also import OpenTelemetry traces for enhanced correlation with eBPF data.

SigNoz has the widest integration ecosystem, supporting all OpenTelemetry instrumentations (auto-instrumentation for Java, Python, Node.js, Go, .NET, Ruby, PHP), Prometheus metrics scraping, Fluent Bit for log forwarding, and 50+ alerting destinations.

HyperDX focuses on OpenTelemetry SDK integration with additional session replay SDKs for the browser (JavaScript/TypeScript). It supports standard OTel auto-instrumentation but has a smaller ecosystem of pre-built integrations compared to SigNoz.

For related reading, see our OpenTelemetry collector pipeline guide and eBPF networking observability comparison.

FAQ

What is the main difference between Coroot and SigNoz?

Coroot uses eBPF to capture observability data at the kernel level without requiring any code changes to your applications. SigNoz relies on OpenTelemetry SDKs that must be added to each service. Coroot provides automatic service discovery and continuous profiling out of the box, while SigNoz offers a broader APM feature set including exception tracking and alert management.

Can I use Coroot and SigNoz together?

Yes. Coroot’s eBPF data and SigNoz’s OpenTelemetry data complement each other. Coroot excels at automatic infrastructure-level visibility (service maps, deployment tracking, cost monitoring), while SigNoz provides deep application-level tracing and exception analysis. Some teams run both: Coroot for infrastructure-wide monitoring and SigNoz for detailed application debugging.

Does HyperDX require OpenTelemetry instrumentation?

Yes, HyperDX uses the OpenTelemetry SDK for backend data collection (traces, logs, metrics). Additionally, it requires a separate browser SDK for session replay functionality. If your applications are already instrumented with OpenTelemetry, the migration to HyperDX is straightforward — you just point your OTLP exporter to the HyperDX endpoint.

Which platform uses the least resources?

Coroot has the lightest deployment footprint. It runs as a single container (plus optional ClickHouse) and requires only 2 GB of RAM. SigNoz runs 5 services (Collector, ClickHouse, Query Service, Frontend, AlertManager) and needs at least 4 GB of RAM. HyperDX also runs 5 services (API, Frontend, ClickHouse, PostgreSQL, Redis) but requires slightly less than SigNoz at 3 GB minimum.

Do these platforms support alerting?

SigNoz has the most comprehensive alerting system with configurable rules, multiple notification channels (Slack, email, PagerDuty, webhooks), and alert management workflows. Coroot provides SLO-based alerting tied to its built-in inspections. HyperDX focuses on debugging rather than alerting and does not include a dedicated alerting engine — you would need to pair it with an external alerting tool like Prometheus Alertmanager or Grafana OnCall.

Can these platforms replace Datadog?

All three platforms provide core Datadog features (APM, log management, metrics dashboards) at zero licensing cost. SigNoz is the closest feature-for-feature replacement with its comprehensive APM, alerting, and exception tracking. Coroot replaces Datadog’s infrastructure monitoring and service mapping capabilities with zero-instrumentation observability. HyperDX replaces Datadog’s Real User Monitoring (RUM) and session replay features with a developer-centric debugging experience. None of them match Datadog’s breadth of integrations out of the box, but they cover the most commonly used features.