HyperDX only

Deploying HyperDX only

This option is designed if you already have a running ClickHouse instance populated with observability or event data.

HyperDX can be used independently of the rest of the stack and is compatible with any data schema - not just OpenTelemetry (OTel). This makes it suitable for custom observability pipelines already built on ClickHouse.

To enable full functionality, you must provide a MongoDB instance for storing application state, including dashboards, saved searches, user settings, and alerts.

In this mode, data ingestion is left entirely to the user. You can ingest data into ClickHouse using your own hosted OpenTelemetry collector, direct ingestion from client libraries, ClickHouse-native table engines (such as Kafka or S3), ETL pipelines, or managed ingestion services like ClickPipes. This approach offers maximum flexibility and is suitable for teams that already operate ClickHouse and want to layer HyperDX on top for visualization, search, and alerting.

Suitable for

• Existing ClickHouse users
• Custom event pipelines

Deployment steps

1. Deploy with Docker

   Run the following command, modifying YOUR_MONGODB_URI as required.

   docker run -e MONGO_URI=mongodb://YOUR_MONGODB_URI -p 8080:8080 docker.hyperdx.io/hyperdx/hyperdx
   
2. Navigate to the HyperDX UI

   Visit http://localhost:8080 to access the HyperDX UI.

   Create a user, providing a username and password which meets the requirements.

   On clicking Create you’ll be prompted for connection details.

3. Complete connection details

   Connect to your own external ClickHouse cluster e.g. ClickHouse Cloud.

   If prompted to create a source, retain all default values and complete the Table field with the value otel_logs. All other settings should be auto-detected, allowing you to click Save New Source.

   Creating a source

   Creating a source requires tables to exist in ClickHouse. If you don’t have data, we recommend deploying the ClickStack OpenTelemetry collector to create tables.

Using Docker Compose

You can modify the Docker Compose configuration to achieve the same effect as this guide, removing the OTel collector and ClickHouse instance from the manifest.

ClickStack OpenTelemetry collector

Even if you’re managing your own OpenTelemetry collector, independent of the other components in the stack, we still recommend using the ClickStack distribution of the collector. This ensures the default schema is used and best practices for ingestion are applied.

For details on deploying and configuring a standalone collector see “Ingesting with OpenTelemetry”.

Schema choice: Map vs JSON

ClickStack stores attributes as Map(LowCardinality(String), String) columns by default. This is the recommended schema for observability workloads. Combined with bucketed map serialization and text indexes on map keys and values, it provides selective lookups without the per-key ingest overhead of dynamic JSON subcolumns.

A JSON-typed schema is available in beta for evaluation on workloads with a small, stable attribute key-set. It is not recommended as the default. See Map vs JSON type for the full comparison and the env vars required to enable JSON support.