The ClickHouse Terraform provider now supports managing ClickStack resources - dashboards, alerts, sources, saved searches, connections, and webhooks - across both self-hosted deployments and ClickHouse Cloud. This support is available as beta starting in provider version 3.25, letting teams store observability configuration in version control and apply it via terraform plan and terraform apply. ClickStack resources were added as a dedicated module within the existing ClickHouse/clickhouse provider rather than a separate provider, keeping authentication consistent with Cloud API credentials for Managed ClickStack and endpoint/API key for self-hosted deployments. The post walks through configuring credentials, defining a dashboard resource in JSON, running terraform apply, and importing existing dashboards into Terraform management, including a new UI-based import block generator.
Table of contents
The ClickHouse Terraform provider #Building on the ClickStack API #Using ClickStack resources #Questions this post answers
How do I manage ClickStack dashboards and alerts with Terraform?
The official ClickHouse Terraform provider (ClickHouse/clickhouse) supports ClickStack resources as a beta feature starting in version 3.25. It manages dashboards, alerts, sources, saved searches, connections, and webhooks for both self-hosted and Managed ClickStack, using the standard terraform plan and terraform apply workflow, with dashboard JSON validated against the ClickStack API during planning. See daily.dev for more on version-controlling observability configuration as ClickStack Terraform support matures.
What credentials does the ClickHouse Terraform provider need for Managed ClickStack versus self-hosted ClickStack?
Managed ClickStack on ClickHouse Cloud requires the organization ID, a Cloud API key ID and secret, and the ClickStack service ID, set via CLICKHOUSE_ORG_ID, CLICKSTACK_SERVICE_ID, CLICKHOUSE_CLOUD_API_KEY, and CLICKHOUSE_CLOUD_API_SECRET. Self-hosted, open-source ClickStack instead uses CLICKSTACK_ENDPOINT and a personal API access key via CLICKSTACK_API_KEY; the two credential sets should not be mixed in the same unaliased provider block. Developers wiring up ClickStack automation can track provider changes like this via daily.dev.
Why did ClickHouse add ClickStack support to the existing clickhouse Terraform provider instead of a separate provider?
A separate ClickStack provider would have duplicated release work, testing, documentation, and authentication code, so ClickStack support was added as a dedicated service module inside the existing ClickHouse/clickhouse provider. This keeps users on a single provider and release path while keeping ClickStack resources and data sources separate from the Cloud and Postgres implementations, and reuses the same organization ID and Cloud API credentials for authentication. daily.dev helps engineers weighing single-provider versus multi-provider infrastructure tooling decisions like this one.