For the complete documentation index, see llms.txt. Markdown versions are available by appending .md to documentation URLs.

Install SigNoz on Any Kubernetes Cluster - Self-Host Guide

Self-Hosted Enterprise - This page applies to self-hosted SigNoz with an active license.
Self-Hosted Community - This page applies to self-hosted SigNoz without a license.
Choose SigNoz Cloud for ease, or self-host for control—with the freedom to switch as your needs grow.

This guide explains how to install SigNoz on any Kubernetes cluster, on another cloud or on your own servers using the SigNoz Helm chart, with Foundry or with Helm directly.

Prerequisites

  • You must have a Kubernetes cluster
  • kubectl configured to reach the cluster, and Helm 3 installed on the same machine.
  • Enough cluster capacity for SigNoz. For sizing, see resource planning.

Install SigNoz

Step 1: Add the Helm repository

Run this on the machine where you use kubectl:

helm repo add signoz https://charts.signoz.io
helm repo update

Step 2 (optional): Choose a storage class

SigNoz keeps its data on persistent volumes. A storage class decides what kind of disk your cluster creates for them. Without this step, SigNoz uses your cluster's default storage class. To see what your cluster offers:

kubectl get storageclass

Pick a class that allows volume expansion, so you can grow the SigNoz volumes later by changing the claim size.

To use a specific one, create a file named values.yaml:

global:
  storageClass: <storage-class>

Verify these values:

  • <storage-class>: A storage class name from the kubectl get storageclass output.

Any other chart value goes in the same file. See the chart configuration reference.

Step 3: Install the chart

Run this from the directory that contains values.yaml:

helm install signoz signoz/signoz \
   --namespace signoz --create-namespace \
   --wait --timeout 1h \
   -f values.yaml

Leave out -f values.yaml if you skipped Step 2. --wait makes the command return once every pod is ready.

Step 4: Verify the installation

Check that the pods are running:

kubectl get pods -n signoz

The output should look similar to the following. Pod suffixes vary:

NAME                                         READY   STATUS      RESTARTS   AGE
chi-signoz-clickhouse-cluster-0-0-0          1/1     Running     0          3m
signoz-0                                     1/1     Running     0          3m
signoz-clickhouse-operator-7f8c9d6b5-q4w2z   2/2     Running     0          3m
signoz-otel-collector-6d9c7b8f5c-k2x9p       1/1     Running     0          3m
signoz-telemetrystore-migrator-x7h3k         0/1     Completed   0          2m
signoz-zookeeper-0                           1/1     Running     0          3m

Once all pods are running, port-forward the SigNoz UI and open http://localhost:8080/ in your browser:

kubectl port-forward -n signoz svc/signoz 8080:8080

In another terminal, check the health endpoint:

curl -X GET http://localhost:8080/api/v1/health

The response is:

{"status":"ok"}

Send data to SigNoz

Your applications send traces, metrics, and logs to the SigNoz collector. Inside the cluster, the collector listens at:

http://signoz-otel-collector.signoz.svc.cluster.local:4318

Use this address as the OTLP endpoint in your instrumentation, for example as the value of OTEL_EXPORTER_OTLP_ENDPOINT. For gRPC, use port 4317 instead.

The second signoz in the address is the namespace. If you installed SigNoz into a different namespace, use that one.

For applications outside the cluster, see the self-hosted ingestion guide.

Customize the installation

Every change follows the same loop: edit values.yaml, then upgrade the release:

helm upgrade signoz signoz/signoz --namespace signoz -f values.yaml

Verify these values:

Troubleshooting

helm install times out

--wait waits for every pod to become ready. When the command times out, list the pods with kubectl get pods -n signoz and follow the two items below.

Pods stay Pending

Describe the pod to see why it is unscheduled:

kubectl describe pod -n signoz <pod-name>

Replace <pod-name> with a pod name from the kubectl get pods -n signoz output.

A pod that reports insufficient CPU or memory needs more node capacity. See resource planning.

After the fix, kubectl get pods -n signoz shows the pod as Running.

A pod keeps restarting

Check its logs:

kubectl logs -n signoz <pod-name>

To see the logs from before the last restart, add --previous.

Next Steps

Is this page helpful

Last updated—October 06, 2026

Edit on GitHub