Managed

[Edit this page](https://github.com/ClickHouse/clickhouse-docs/blob/main/docs/use-cases/observability/clickstack/deployment/managed.md)

Beta feature. [Learn more.](/docs/beta-and-experimental-features#beta-features)

Beta feature

This feature is in ClickHouse Cloud beta.

This **guide is for existing users of ClickHouse Cloud**. If you're new to ClickHouse Cloud, we recommend our [Getting Started](/docs/use-cases/observability/clickstack/getting-started/managed) guide for Managed ClickStack.

In this deployment pattern, both ClickHouse and the ClickStack UI (HyperDX) are hosted in ClickHouse Cloud, minimizing the number of components the user needs to self-host.

As well as reducing infrastructure management, this deployment pattern ensures authentication is integrated with ClickHouse Cloud SSO/SAML. Unlike self-hosted deployments, there is also no need to provision a MongoDB instance to store application state — such as dashboards, saved searches, user settings, and alerts. Users also benefit from:

- Automatic scaling of compute independent of storage
- Low-cost and effectively unlimited retention based on object storage
- The ability to independently isolate read and write workloads with Warehouses.
- Integrated authentication
- Automated backups
- Security and compliance features
- Seamless upgrades

In this mode, data ingestion is entirely left to the user. You can ingest data into Managed ClickStack using your own hosted OpenTelemetry collector, direct ingestion from client libraries, ClickHouse-native table engines (such as Kafka or S3), ETL pipelines, or ClickPipes — ClickHouse Cloud's managed ingestion service. This approach offers the simplest and most performant way to operate ClickStack.

### Suitable for[​](#suitable-for "Direct link to Suitable for")

This deployment pattern is ideal in the following scenarios:

1. You already have observability data in ClickHouse Cloud and wish to visualize it using ClickStack.
2. You operate a large observability deployment and need the dedicated performance and scalability of ClickStack running on ClickHouse Cloud.
3. You're already using ClickHouse Cloud for analytics and want to instrument your application using ClickStack instrumentation libraries — sending data to the same cluster. In this case, we recommend using [warehouses](/docs/cloud/reference/warehouses) to isolate compute for observability workloads.

## Setup steps[​](#setup-steps "Direct link to Setup steps")

The following guide assumes you have already created a ClickHouse Cloud service. If you haven't created a service, follow the [Getting Started](/docs/use-cases/observability/clickstack/getting-started/managed) guide for Managed ClickStack. This will leave you with a service in the same state as this guide i.e. ready for observability data with ClickStack enabled.

- Create a new service- Use an existing service

Create a new service

### Create a new service[​](#create-a-service "Direct link to Create a new service")

From the ClickHouse Cloud landing page, select `New service` to create a new service.

Specify your provider, region and resource

### Specify your provider, region and resource[​](#specify-your-region-and-resources "Direct link to Specify your provider, region and resource")

Scale vs Enterprise

We recommend this [Scale tier](/docs/cloud/manage/cloud-tiers) for most ClickStack workloads. Choose the Enterprise tier if you require advanced security features such as SAML, CMEK, or HIPAA compliance. It also offers custom hardware profiles for very large ClickStack deployments. In these cases, we recommend contacting support.

Select the Cloud provider and region.

When specifying the select CPU and memory, estimate it based on your expected ClickStack ingestion throughput. The table below provides guidance for sizing these resources.

When deploying **Managed ClickStack**, it is important to provision sufficient compute resources to handle both ingestion and query workloads. The estimates below provide a **baseline starting point** based on the volume of observability data you plan to ingest.

|  |  |  |  |  |  |  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Monthly ingest volume Recommended compute|  |  |  |  |  |  |  |  |  |  | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | < 10 TB / month 2 vCPU × 3 replicas|  |  |  |  |  |  |  |  | | --- | --- | --- | --- | --- | --- | --- | --- | | 10–50 TB / month 4 vCPU × 3 replicas|  |  |  |  |  |  | | --- | --- | --- | --- | --- | --- | | 50–100 TB / month 8 vCPU × 3 replicas|  |  |  |  | | --- | --- | --- | --- | | 100–500 TB / month 30 vCPU × 3 replicas|  |  | | --- | --- | | 1 PB+ / month 59 vCPU × 3 replicas | | | | | | | | | | | |

These recommendations are based on the following assumptions:

- Data volume refers to **uncompressed ingest volume** per month and applies to both logs and traces.
- Query patterns are typical for observability use cases, with most queries targeting **recent data**, usually the last 24 hours.
- Ingestion is relatively **uniform across the month**. If you expect bursty traffic or spikes, you should provision additional headroom.
- Storage is handled separately via ClickHouse Cloud object storage and isn't a limiting factor for retention. We assume data retained for longer periods is infrequently accessed.

More compute may be required for access patterns that regularly query longer time ranges, perform heavy aggregations, or support a high number of concurrent users.

Although two replicas can meet the CPU and memory requirements for a given ingestion throughput, we recommend using three replicas where possible to achieve the same total capacity and improve service redundancy.

Note

These values are **estimates only** and should be used as an initial baseline. Actual requirements depend on query complexity, concurrency, retention policies, and variance in ingestion throughput. Always monitor resource usage and scale as needed.

Once you have specified the requirements, your Managed ClickStack service will take several minutes to provision. Feel free to explore the rest of the [ClickHouse Cloud console](/docs/cloud/overview) whilst waiting for provisioning.

Once **provisioning is complete, the 'ClickStack' option on the left menu will be enabled**.

Setup ingestion

### Setup ingestion[​](#setup-ingestion-create-new "Direct link to Setup ingestion")

Once your service has been provisioned, ensure the the service is selected and click "ClickStack" from the left menu.

Select "Start Ingestion" and you'll be prompted to select an ingestion source. Managed ClickStack supports OpenTelemetry and [Vector](https://vector.dev/) as its main ingestion sources. However, users are also free to send data directly to ClickHouse in their own schema using any of the [ClickHouse Cloud support integrations](/docs/integrations).

OpenTelemetry recommended

Use of the OpenTelemetry is strongly recommended as the ingestion format.
It provides the simplest and most optimized experience, with out-of-the-box schemas that are specifically designed to work efficiently with ClickStack.

- OpenTelemetry- Vector

To send OpenTelemetry data to Managed ClickStack, you're recommended to use an OpenTelemetry Collector. The collector acts as a gateway that receives OpenTelemetry data from your applications (and other collectors) and forwards it to ClickHouse Cloud.

If you don't already have one running, start a collector using the steps below. If you have existing collectors, a configuration example is also provided.

### Start a collector[​](#start-a-collector "Direct link to Start a collector")

The following assumes the recommended path of using the **ClickStack distribution of the OpenTelemetry Collector**, which includes additional processing and is optimized specifically for ClickHouse Cloud. If you're looking to use your own OpenTelemetry Collector, see ["Configure existing collectors."](#configure-existing-collectors)

To get started quickly, copy and run the Docker command shown.

This command should include your connection credentials pre-populated.

Deploying to production